Contents
Description of the project
The continuous growth in ubiquitous computing and network connectivity in our everyday environments calls for a deep rethinking of traditional communication service architectures. In pervasive scenarios, manually configuring communication service/protocols is becoming mostly unthinkable, due to the high heterogeneity of devices and services, and to the decentralized and embedded nature of the involved entities. The next step is towards the “componentization” of communication services, i.e. services implemented and exposed by software components, rather than static protocol/service layers. Stack layering is likewise expected to be replaced by the dynamic and flexible aggregation of such components. Canonical software engineering models for component composition and syntactic service interfaces can hardly tackle the openness and dynamicity of such envisioned pervasive communication services. The Service Ecosystem project aims at finding an innovative ecology-inspired composition model for pervasive services. The key idea is to exploit semantics as an overlay for service aggregation rather than a mere additional description of a static service.
Project staff
- Prof. Franco Zambonelli
- Prof. Giacomo Cabri
- Raffaele Quitadamo, PhD
- MSc. Maciej Gawinecki
- Ing. Mariachiara Puviani
- Cynthia Villalba
Interesting stuff
- The Service Ecosystem: Dynamic Self-Aggregation of Pervasive Communication Services -- vision of the Ecosystem
- Dynamic Service Composition project described in the Semantics-based Dynamic Web Service Composition article, which is the inspiration for the project
- Report about outcome of Dynamic Service Composition project, by Maciej Gawinecki
- Semantic Composition of Services (in Polish), ongoing PhD work of Robert Szymacha
- The Obje interoperability platform based on internal project SpeakEasy from Xerox (thanks to Minor for suggestion)
- REconfigurable Dispatching System (REDS) framework of Java classes to build publish-subscribe applications for large, dynamic network; used in CASCADAS project.
- Service Clouds: Overlay-Based Infrastructure for Autonomic Communication Services
Simulation environments
Java to RDF mapping tools
- The JenaBean project, An introductory article about JenaBean
- Java2RDF tool -- this is no longer called "Modifications to JenaBean", because we created a new tool
- The Sommer (Semantic Object (Metadata) MappeR) project
Codes and prototyping
- Ecosystem prototyping
- CVS repository. The URL to use is the following:
:pserver:user-name@mars.ing.unimo.it:/cvsrepo
- Structure of the repository:
| Description | Remote directory |
|---|---|
| Prototypes sub-project | /ecosystem-prototypes
|
| Common libraries used in the projects | /ecosystem-libs
|
| Binaries of libraries (JARs) | /ecosystem-libs/lib
|
| Source code of libraries (each as a seperate Eclipse projecT) | /ecosystem-libs/source
|
Deploying and testing applications for Handheld devices
Service composition
State-of-the-art
BPEL is used as an industry standard to orchestrate Web Services and define the workflow between them. This approach disadvantages from the static definition of a composition of services provided by a system administrator in advance. This is not resilient to both service change (new service arrive and disappear, their interface changes) and scenario changes (new type of request...). BPEL engine executes services from a centralized point, which makes this approach only valuable when handling with changes of small number of services. There exist two alternative solution to this problem. One of them is to keep the user "in the loop", by leaving to the user selecting a set of discovered device to carry out an operation for which no application has yet been developed [PARC's Obje, Speakeasy platforms for recombinant computing]. On the contrary, it may be possible to offload some aspect of composition to the system, by featuring a system with "intelligent" infrastructures which can propose a composition of a services to the user with best-effort (with some heuristic). Further works in this direction provide algorithms based on the assumption, that two services are composable if the output (?) of the first one syntactically matches to the input of the other [?cite??? don't know anything]. Syntactic dependency is a limitation (because ???), which has can been figthed by defining semantic relationships between input and output parameters of services, such sub-class relationships (defined by ontologies) [Fuji et Suda]. What do we take from this idea ??????????????????????/ . The latter inspired our model. Nonetheless, one important step forward is the choice of a distributed and adaptive service aggregation strategy (through enzymes) instead of a centralized and static (in a sense the composition of services cannot be refined during realizing user request) workflow composer.
Code Generator Tool- Command Line and Ant Task
http://ws.apache.org/axis2/tools/1_0/CodegenToolReference.html