Coordination as a Service (CaaS) in the Cloud

Nel primo capitolo si è studiata la nuova tecnologia del Cloud Computing, fornendo una semplice analisi di tutte le caratteristiche principali, gli attori coinvolti e i relativi metodi di distribuzione e servizi offerti. Nel secondo capitolo si è introdotta la nozione di coordination as a service, discutendone le relative astrazioni che compongono l'architettura logica. Successivamente si è preso in considerazione il modello di coordinazione TuCSoN definendo cosa si intende per nodo, agente, centro di tuple e agent coordination context ed è stato analizzato il relativo linguaggio di coordinazione attraverso il quale essi interagiscono. Nel terzo capitolo sono state riviste ed estese le nozioni di TuCSoN, precedentemente acquisite, nell'ambito del Cloud Computing ed è stato fornito un modello astratto ed una possibile architettura di TuCSoN in the Cloud. Sono stati analizzati anche gli aspetti di un possibile servizio di tale genere nello scenario di servizio pay-per-use. Infine nel quarto ed ultimo capitolo si è sviluppato un caso di studio in cui si è implementata un'interfaccia per l'attuale CLI di TuCSoN sottoforma di applet, che è stata poi inserita nel Cloud attraverso la piattaforma PaaS Cloudify.

Agents, nodes & resources: Universal naming system for a coordination middleware

La tesi si propone di sviluppare un modello, l'architettura e la tecnologia per il sistema di denominazione del Middleware Coordinato TuCSoN, compresi gli agenti, i nodi e le risorse. Identità universali che rappresentano queste entità, sia per la mobilità fisica sia per quella virtuale, per un Management System (AMS, NMS, RMS) distribuito; tale modulo si occupa anche di ACC e trasduttori, prevedendo questioni come la tolleranza ai guasti, la persistenza, la coerenza, insieme con il coordinamento disincarnata in rete, come accade con le tecnologie Cloud. All’interno dell’elaborato, per prima cosa si è fatta una introduzione andando a descrivere tutto ciò che è contenuto nell’elaborato in modo da dare una visione iniziale globale del lavoro eseguito. Di seguito (1° capitolo) si è descritta tutta la parte relativa alle conoscenze di base che bisogna avere per la comprensione dell’elaborato; tali conoscenze sono relative a TuCSoN (il middleware coordinato con cui il modulo progettato dovrà interfacciarsi) e Cassandra (sistema server distribuito su cui si appoggia la parte di mantenimento e salvataggio dati del modulo). In seguito (2° capitolo) si è descritto JADE, un middleware da cui si è partiti con lo studio per la progettazione del modello e dell’architettura del modulo. Successivamente (3° capitolo) si è andati a spiegare la struttura e il modello del modulo considerato andando ad esaminare tutti i dettagli relativi alle entità interne e di tutti i legami fra esse. In questa parte si è anche dettagliata tutta la parte relativa alla distribuzione sulla rete del modulo e dei suoi componenti. In seguito (4° capitolo) è stata dettagliata e spiegata tutta la parte relativa al sistema di denominazione del modulo, quindi la sintassi e l’insieme di procedure che l’entità consumatrice esterna deve effettuare per ottenere un “nome universale” e quindi anche tutti i passaggi interni del modulo per fornire l’identificatore all’entità consumatrice. Nel capitolo successivo (5° capitolo) si sono descritti tutti i casi di studio relativi alle interazioni con le entità esterne, alle entità interne in caso in cui il modulo sia o meno distribuito sulla rete, e i casi di studio relativi alle politiche, paradigmi e procedure per la tolleranza ai guasti ed agli errori in modo da dettagliare i metodi di riparazione ad essi. Successivamente (6° capitolo) sono stati descritti i possibili sviluppi futuri relativi a nuove forme di interazione fra le entità che utilizzano questo modulo ed alle possibili migliorie e sviluppi tecnologici di questo modulo. Infine sono state descritte le conclusioni relative al modulo progettato con tutti i dettagli in modo da fornire una visione globale di quanto inserito e descritto nell’elaborato.

Cloud Stratus: uma plataforma de middleware para desenvolvimento de aplicações em nuvem

Cloud Computing is a paradigm that enables the access, in a simple and pervasive way, through the network, to shared and configurable computing resources. Such resources can be offered on demand to users in a pay-per-use model. With the advance of this paradigm, a single service offered by a cloud platform might not be enough to meet all the requirements of clients. Ergo, it is needed to compose services provided by different cloud platforms. However, current cloud platforms are not implemented using common standards, each one has its own APIs and development tools, which is a barrier for composing different services. In this context, the Cloud Integrator, a service-oriented middleware platform, provides an environment to facilitate the development and execution of multi-cloud applications. The applications are compositions of services, from different cloud platforms and, represented by abstract workflows. However, Cloud Integrator has some limitations, such as: (i) applications are locally executed; (ii) users cannot specify the application in terms of its inputs and outputs, and; (iii) experienced users cannot directly determine the concrete Web services that will perform the workflow. In order to deal with such limitations, this work proposes Cloud Stratus, a middleware platform that extends Cloud Integrator and offers different ways to specify an application: as an abstract workflow or a complete/partial execution flow. The platform enables the application deployment in cloud virtual machines, so that several users can access it through the Internet. It also supports the access and management of virtual machines in different cloud platforms and provides services monitoring mechanisms and assessment of QoS parameters. Cloud Stratus was validated through a case study that consists of an application that uses different services provided by different cloud platforms. Cloud Stratus was also evaluated through computing experiments that analyze the performance of its processes.

Mobile cloud contextual awareness with the cloud personal assistant

This paper presents our efforts to bridge the gap between mobile context awareness, and mobile cloud services, using the Cloud Personal Assistant (CPA). The CPA is a part of the Context Aware Mobile Cloud Services (CAMCS) middleware, which we continue to develop. Specifically, we discuss the development and evaluation of the Context Processor component of this middleware. This component collects context data from the mobile devices of users, which is then provided to the CPA of each user, for use with mobile cloud services. We discuss the architecture and implementation of the Context Processor, followed by the evaluation. We introduce context profiles for the CPA, which influence its operation by using different context types. As part of the evaluation, we present two experimental context-aware mobile cloud services to illustrate how the CPA works with user context, and related context profiles, to complete tasks for the user.

Sensor grid middleware metamodeling and analysis

Sensor grid is a platform that combines wireless sensor networks and grid computing with the aim of exploiting the complementary advantages of the two systems. Proper integration of these distinct systems into effective, logically single platform is challenging. This paper presents an approach for practical sensor grid implementation and management. The proposed approach uses a metamodeling technique and performance analysis and tuning as well as a middleware infrastructure that enable practical sensor grid implementation and management. The paper presents our implementation and analysis of the sensor grid. © 2014 Srimathi Chandrasekaran et al.

Cloud Integrator: uma plataforma para composição de serviços em ambientes de computação em nuvem

With the advance of the Cloud Computing paradigm, a single service offered by a cloud platform may not be enough to meet all the application requirements. To fulfill such requirements, it may be necessary, instead of a single service, a composition of services that aggregates services provided by different cloud platforms. In order to generate aggregated value for the user, this composition of services provided by several Cloud Computing platforms requires a solution in terms of platforms integration, which encompasses the manipulation of a wide number of noninteroperable APIs and protocols from different platform vendors. In this scenario, this work presents Cloud Integrator, a middleware platform for composing services provided by different Cloud Computing platforms. Besides providing an environment that facilitates the development and execution of applications that use such services, Cloud Integrator works as a mediator by providing mechanisms for building applications through composition and selection of semantic Web services that take into account metadata about the services, such as QoS (Quality of Service), prices, etc. Moreover, the proposed middleware platform provides an adaptation mechanism that can be triggered in case of failure or quality degradation of one or more services used by the running application in order to ensure its quality and availability. In this work, through a case study that consists of an application that use services provided by different cloud platforms, Cloud Integrator is evaluated in terms of the efficiency of the performed service composition, selection and adaptation processes, as well as the potential of using this middleware in heterogeneous computational clouds scenarios

Coordinazione embodied vs. Disembodied: TuCSon on cloud

Lo scopo della tesi è esplorare il nuovo dualismo tra calcolo situato e calcolo come mero servizio immateriale che si osserva nel rafforzarsi di due paradigmi apparentemente antitetici come Cloud Computing e Pervasive Computing. Si vuole quindi dimostrare che i due paradigmi sono complementari, e possibilmente sviluppare un modello e un approccio metodologico per sistemi distribuiti che sfrutti opportunamente le caratteristiche dei due paradigmi. A tale scopo si utilizzerà come caso di studio il modello TuCSoN con linguaggio ReSpecT, combinando opportunamente Situated ReSpecT con il modello Coordination as a Service (CaaS) espresso da TuCSoN on Cloud.

Middleware for Large-scale Distributed Systems

Nos últimos anos o aumento exponencial da utilização de dispositivos móveis e serviços disponibilizados na “Cloud” levou a que a forma como os sistemas são desenhados e implementados mudasse, numa perspectiva de tentar alcançar requisitos que até então não eram essenciais. Analisando esta evolução, com o enorme aumento dos dispositivos móveis, como os “smartphones” e “tablets” fez com que o desenho e implementação de sistemas distribuidos fossem ainda mais importantes nesta área, na tentativa de promover sistemas e aplicações que fossem mais flexíveis, robutos, escaláveis e acima de tudo interoperáveis. A menor capacidade de processamento ou armazenamento destes dispositivos tornou essencial o aparecimento e crescimento de tecnologias que prometem solucionar muitos dos problemas identificados. O aparecimento do conceito de Middleware visa solucionar estas lacunas nos sistemas distribuidos mais evoluídos, promovendo uma solução a nível de organização e desenho da arquitetura dos sistemas, ao memo tempo que fornece comunicações extremamente rápidas, seguras e de confiança. Uma arquitetura baseada em Middleware visa dotar os sistemas de um canal de comunicação que fornece uma forte interoperabilidade, escalabilidade, e segurança na troca de mensagens, entre outras vantagens. Nesta tese vários tipos e exemplos de sistemas distribuídos e são descritos e analisados, assim como uma descrição em detalhe de três protocolos (XMPP, AMQP e DDS) de comunicação, sendo dois deles (XMPP e AMQP) utilzados em projecto reais que serão descritos ao longo desta tese. O principal objetivo da escrita desta tese é demonstrar o estudo e o levantamento do estado da arte relativamente ao conceito de Middleware aplicado a sistemas distribuídos de larga escala, provando que a utilização de um Middleware pode facilitar e agilizar o desenho e desenvolvimento de um sistema distribuído e traz enormes vantagens num futuro próximo.

BioTuCSoN: biochemical extension of TuCSoN to support self-organising coordination

Starting from pervasive computing paradigm, we want to face the new system's requirements, concerning, mainly, self-organisation, situatedness and adaptivity, through the definition and execution of nature-inspired patterns. They are extracted by the study of dynamics in biological systems and we consider for their implementation the biochemical tuple spaces model. In particular, the aim of the thesis is to design and realize a first biochemical extension of TuCSoN (technology based on tuple spaces model) and, then, to verify its capabilities by means of a proper case study, that deals with local self-organisation and competition of services in an open and highly-dynamic environment.

Profiling, re-factoring e ottimizzazione del middleware di coordinazione TuCSoN

In questo lavoro di tesi vengono esaminate quelle caratteristiche architetturali del middleware di coordinazione TuCSoN che maggiormente impattano sulle prestazioni dei sistemi coordinati. Laddove è stato possibile si è intervenuto sia a livello architetturale sia a livello tecnologico per migliorare le prestazioni del middleware. Come risultato finale si è ottenuto un importante incremento delle prestazioni del sistema. Non tutte le migliorie apportabili sono state realizzate, tuttavia vengono forniti alcuni spunti per possibili sviluppi futuri.

TuCSoN on Cloud: Revisione dell'architettura

In questa tesi si revisiona l'architettura di TuCSoN on Cloud. Sono trattati i problemi riguardanti la gestione dei nodi TuCSoN su un cloud simulato su Cloudify; ovvero come sono memorizzati i vari tuple centre per ogni utente. É inoltre trattato il problema della concorrenza e della sicurezza, ovvero di come é gestita la password dell'utente.

Coordination nel Cloud: Elasticità in Respect

L'elasticità è un concetto fondamentale nell'ambito del cloud computing, ma propone problemi di coordinazione che, se non compresi nella loro natura, rischiano di renderla inefficiente. Tramite il concetto di “elasticità consapevole della coordinazione” (coordination-aware elasticity), in questa tesi si discute come si possa espandere il linguaggio per l’elasticità cloud SYBL in modo che possa eseguire alcune funzioni elastiche tramite il linguaggio di coordinazione ReSpecT.

A Novel Approach to Context-Aware Content-Based Middleware

La computación ubicua está extendiendo su aplicación desde entornos específicos hacia el uso cotidiano; el Internet de las cosas (IoT, en inglés) es el ejemplo más brillante de su aplicación y de la complejidad intrínseca que tiene, en comparación con el clásico desarrollo de aplicaciones. La principal característica que diferencia la computación ubicua de los otros tipos está en como se emplea la información de contexto. Las aplicaciones clásicas no usan en absoluto la información de contexto o usan sólo una pequeña parte de ella, integrándola de una forma ad hoc con una implementación específica para la aplicación. La motivación de este tratamiento particular se tiene que buscar en la dificultad de compartir el contexto con otras aplicaciones. En realidad lo que es información de contexto depende del tipo de aplicación: por poner un ejemplo, para un editor de imágenes, la imagen es la información y sus metadatos, tales como la hora de grabación o los ajustes de la cámara, son el contexto, mientras que para el sistema de ficheros la imagen junto con los ajustes de cámara son la información, y el contexto es representado por los metadatos externos al fichero como la fecha de modificación o la de último acceso. Esto significa que es difícil compartir la información de contexto, y la presencia de un middleware de comunicación que soporte el contexto de forma explícita simplifica el desarrollo de aplicaciones para computación ubicua. Al mismo tiempo el uso del contexto no tiene que ser obligatorio, porque si no se perdería la compatibilidad con las aplicaciones que no lo usan, convirtiendo así dicho middleware en un middleware de contexto. SilboPS, que es nuestra implementación de un sistema publicador/subscriptor basado en contenido e inspirado en SIENA [11, 9], resuelve dicho problema extendiendo el paradigma con dos elementos: el Contexto y la Función de Contexto. El contexto representa la información contextual propiamente dicha del mensaje por enviar o aquella requerida por el subscriptor para recibir notificaciones, mientras la función de contexto se evalúa usando el contexto del publicador y del subscriptor. Esto permite desacoplar la lógica de gestión del contexto de aquella de la función de contexto, incrementando de esta forma la flexibilidad de la comunicación entre varias aplicaciones. De hecho, al utilizar por defecto un contexto vacío, las aplicaciones clásicas y las que manejan el contexto pueden usar el mismo SilboPS, resolviendo de esta forma la incompatibilidad entre las dos categorías. En cualquier caso la posible incompatibilidad semántica sigue existiendo ya que depende de la interpretación que cada aplicación hace de los datos y no puede ser solucionada por una tercera parte agnóstica. El entorno IoT conlleva retos no sólo de contexto, sino también de escalabilidad. La cantidad de sensores, el volumen de datos que producen y la cantidad de aplicaciones que podrían estar interesadas en manipular esos datos está en continuo aumento. Hoy en día la respuesta a esa necesidad es la computación en la nube, pero requiere que las aplicaciones sean no sólo capaces de escalar, sino de hacerlo de forma elástica [22]. Desgraciadamente no hay ninguna primitiva de sistema distribuido de slicing que soporte un particionamiento del estado interno [33] junto con un cambio en caliente, además de que los sistemas cloud actuales como OpenStack u OpenNebula no ofrecen directamente una monitorización elástica. Esto implica que hay un problema bilateral: cómo puede una aplicación escalar de forma elástica y cómo monitorizar esa aplicación para saber cuándo escalarla horizontalmente. E-SilboPS es la versión elástica de SilboPS y se adapta perfectamente como solución para el problema de monitorización, gracias al paradigma publicador/subscriptor basado en contenido y, a diferencia de otras soluciones [5], permite escalar eficientemente, para cumplir con la carga de trabajo sin sobre-provisionar o sub-provisionar recursos. Además está basado en un algoritmo recientemente diseñado que muestra como añadir elasticidad a una aplicación con distintas restricciones sobre el estado: sin estado, estado aislado con coordinación externa y estado compartido con coordinación general. Su evaluación enseña como se pueden conseguir notables speedups, siendo el nivel de red el principal factor limitante: de hecho la eficiencia calculada (ver Figura 5.8) demuestra cómo se comporta cada configuración en comparación con las adyacentes. Esto permite conocer la tendencia actual de todo el sistema, para saber si la siguiente configuración compensará el coste que tiene con la ganancia que lleva en el throughput de notificaciones. Se tiene que prestar especial atención en la evaluación de los despliegues con igual coste, para ver cuál es la mejor solución en relación a una carga de trabajo dada. Como último análisis se ha estimado el overhead introducido por las distintas configuraciones a fin de identificar el principal factor limitante del throughput. Esto ayuda a determinar la parte secuencial y el overhead de base [26] en un despliegue óptimo en comparación con uno subóptimo. Efectivamente, según el tipo de carga de trabajo, la estimación puede ser tan baja como el 10 % para un óptimo local o tan alta como el 60 %: esto ocurre cuando se despliega una configuración sobredimensionada para la carga de trabajo. Esta estimación de la métrica de Karp-Flatt es importante para el sistema de gestión porque le permite conocer en que dirección (ampliar o reducir) es necesario cambiar el despliegue para mejorar sus prestaciones, en lugar que usar simplemente una política de ampliación. ABSTRACT The application of pervasive computing is extending from field-specific to everyday use. The Internet of Things (IoT) is the shiniest example of its application and of its intrinsic complexity compared with classical application development. The main characteristic that differentiates pervasive from other forms of computing lies in the use of contextual information. Some classical applications do not use any contextual information whatsoever. Others, on the other hand, use only part of the contextual information, which is integrated in an ad hoc fashion using an application-specific implementation. This information is handled in a one-off manner because of the difficulty of sharing context across applications. As a matter of fact, the application type determines what the contextual information is. For instance, for an imaging editor, the image is the information and its meta-data, like the time of the shot or camera settings, are the context, whereas, for a file-system application, the image, including its camera settings, is the information and the meta-data external to the file, like the modification date or the last accessed timestamps, constitute the context. This means that contextual information is hard to share. A communication middleware that supports context decidedly eases application development in pervasive computing. However, the use of context should not be mandatory; otherwise, the communication middleware would be reduced to a context middleware and no longer be compatible with non-context-aware applications. SilboPS, our implementation of content-based publish/subscribe inspired by SIENA [11, 9], solves this problem by adding two new elements to the paradigm: the context and the context function. Context represents the actual contextual information specific to the message to be sent or that needs to be notified to the subscriber, whereas the context function is evaluated using the publisher’s context and the subscriber’s context to decide whether the current message and context are useful for the subscriber. In this manner, context logic management is decoupled from context management, increasing the flexibility of communication and usage across different applications. Since the default context is empty, context-aware and classical applications can use the same SilboPS, resolving the syntactic mismatch that there is between the two categories. In any case, the possible semantic mismatch is still present because it depends on how each application interprets the data, and it cannot be resolved by an agnostic third party. The IoT environment introduces not only context but scaling challenges too. The number of sensors, the volume of the data that they produce and the number of applications that could be interested in harvesting such data are growing all the time. Today’s response to the above need is cloud computing. However, cloud computing applications need to be able to scale elastically [22]. Unfortunately there is no slicing, as distributed system primitives that support internal state partitioning [33] and hot swapping and current cloud systems like OpenStack or OpenNebula do not provide elastic monitoring out of the box. This means there is a two-sided problem: 1) how to scale an application elastically and 2) how to monitor the application and know when it should scale in or out. E-SilboPS is the elastic version of SilboPS. I t is the solution for the monitoring problem thanks to its content-based publish/subscribe nature and, unlike other solutions [5], it scales efficiently so as to meet workload demand without overprovisioning or underprovisioning. Additionally, it is based on a newly designed algorithm that shows how to add elasticity in an application with different state constraints: stateless, isolated stateful with external coordination and shared stateful with general coordination. Its evaluation shows that it is able to achieve remarkable speedups where the network layer is the main limiting factor: the calculated efficiency (see Figure 5.8) shows how each configuration performs with respect to adjacent configurations. This provides insight into the actual trending of the whole system in order to predict if the next configuration would offset its cost against the resulting gain in notification throughput. Particular attention has been paid to the evaluation of same-cost deployments in order to find out which one is the best for the given workload demand. Finally, the overhead introduced by the different configurations has been estimated to identify the primary limiting factor for throughput. This helps to determine the intrinsic sequential part and base overhead [26] of an optimal versus a suboptimal deployment. Depending on the type of workload, this can be as low as 10% in a local optimum or as high as 60% when an overprovisioned configuration is deployed for a given workload demand. This Karp-Flatt metric estimation is important for system management because it indicates the direction (scale in or out) in which the deployment has to be changed in order to improve its performance instead of simply using a scale-out policy.

Design and Implementation of a Cloud-based Middleware for Persuasive Android Applications

Negli ultimi decenni, le tecnologie e i prodotti informatici sono diventati pervasivi e sono ora una parte essenziale delle nostre vite. Ogni giorno ci influenzano in maniera più o meno esplicita, cambiando il nostro modo di vivere e i nostri comportamenti più o meno intenzionalmente. Tuttavia, i computer non nacquero inizialmente per persuadere: essi furono costruiti per gestire, calcolare, immagazzinare e recuperare dati. Non appena i computer si sono spostati dai laboratori di ricerca alla vita di tutti i giorni, sono però diventati sempre più persuasivi. Questa area di ricerca è chiamata pesuasive technology o captology, anche definita come lo studio dei sistemi informatici interattivi progettati per cambiare le attitudini e le abitudini delle persone. Nonostante il successo crescente delle tecnologie persuasive, sembra esserci una mancanza di framework sia teorici che pratici, che possano aiutare gli sviluppatori di applicazioni mobili a costruire applicazioni in grado di persuadere effettivamente gli utenti finali. Tuttavia, il lavoro condotto dal Professor Helal e dal Professor Lee al Persuasive Laboratory all’interno dell’University of Florida tenta di colmare questa lacuna. Infatti, hanno proposto un modello di persuasione semplice ma efficace, il quale può essere usato in maniera intuitiva da ingegneri o specialisti informatici. Inoltre, il Professor Helal e il Professor Lee hanno anche sviluppato Cicero, un middleware per dispositivi Android basato sul loro precedente modello, il quale può essere usato in modo molto semplice e veloce dagli sviluppatori per creare applicazioni persuasive. Il mio lavoro al centro di questa tesi progettuale si concentra sull’analisi del middleware appena descritto e, successivamente, sui miglioramenti e ampliamenti portati ad esso. I più importanti sono una nuova architettura di sensing, una nuova struttura basata sul cloud e un nuovo protocollo che permette di creare applicazioni specifiche per smartwatch.