From Agentgroup
Jump to: navigation, search

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

Interesting stuff

Simulation environments

Java to RDF mapping tools

Codes and prototyping
  • 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


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