Home
Introduction to the Service Infrastructure Expert Group
| Links of Interest | |
|---|---|
| Pax Composite Bundle | - |
| Karaf Feature | - |
| Javadoc | https://universaal.github.io/service/srvc.pom/apidocs/index.html |
| Maven Site | https://universaal.github.io/service/srvc.pom/ |
| Repository Status | https://github.com/universAAL/platform/wiki/Repository-Status |
| Maven Release Repository | http://depot.universaal.org/maven-repo/releases/org/universAAL/service/ |
| Maven Snapshot Repository | http://depot.universaal.org/maven-repo/snapshots/org/universAAL/service/ |
The Service Infrastructure Expert Group (SIEG) deals with the definition and implementation of universAAL's (uAAL) service infrastructure. In particular, the group identifies platform tasks related to service-based interoperability and examines possible solutions for those tasks. Those tasks include: (1) define SIEG's scope; (2) take major design decisions; (3) indentify basic building blocks that compose uAAL's service infrastructure; (4) select a first set of software artifacts taken from one input project that act as a base implementation.
- all the tasks related to data representation fall in this category; examples of exchangeable data that have to be modeled are: service profiles, service requests, service responses, and the language for the definition of composite services
- the above examples are all domain-independent and related to the basics of the service model; on the plugins layer, however, this basic model can be extended in the direction of domain-specific commonalities
- aspects of service communication, like which protocol to use, could also be part of the service model
- semantic services and their modelling
- brokerage mechanisms help to keep the two sides of a "negotiation" independent from each other. A broker must perform matchmaking between each received request and the available offer to find out the best match for the customer side. To be able to do this, all the communication contracts for registering an offer (here, a service), submitting a request, and providing a response must be specified.
- even with a brokerage mechanism, there are situations where a party might be interested in the info about all the services available or about the availability of offers matching a certain request without doing anything for responding to that request. Examples are: a component in the system that wants to generate a task-based menu of all available user services so that human users can easily find and utilize such services, or a service orchestrator that is responsible for executing scripts that define composite services and wants to know which of those composite services can be offered based on the availability of the "sub-services". A possible task in this regard is the definition of subscription / notification protocols as well as query / reply protocols.
- all tasks related to (1) the management of composite services and reflecting them as available offers, and (2) execution of the workflow definition underlying a composite service after it (the composite service) was selected as the offer matching a concrete request at hand.
- The previous areas cover those dealing with the core of the service infrastructure. The common services area, however, deals with concrete service components (or scripts) realizing (or defining) very commonly needed services. Such service components and scripts can be seen as platform plugins that make the development of a series of AAL services and applications easier.
SIEG will consider developing a workflow language and a composition engine for composing services.
The goal of the Service Infrastructure is to fulfill the requirements in the paragraph 4.6.2.4 Service Orientation, of D1.2-B - "AAL Reference Architecture Requirements".
The Service Infrastructure relates to the following parts of the D1.3-C - "The universAAL Reference Architecture for AAL", Part III,
2.3 The behavioral aspects (service collaboration patterns):
2.3.1.1 Platform-to-Platform services:
- RAS#1.23 Runtime Orchestration of services
The following abstract building blocks from the System Decomposition Model in the universAAL deliverable D1.3 Part IV fall into the scope of the SIEG expert group:
