Repository navigation
Service Management
Extends the middleware by providing for service-based semantic interoperability. It mediates between independently developed provider and requester agents that might be arbitrarily distributed on different nodes within an uSpace. It hides the distribution and the possible heterogeneity of the execution environment of the provider and requester agents. It defines protocols for provider agents how to advertise their service utilities by semantically describing them in service profiles and how to cooperate in the processing of service requests. It also defines protocols for requester agents how to formulate their requests semantically in terms of goals that they want to reach. Finally, it resolves the mediation task by matchmaking between the received service requests and the advertised service profiles and by taking over all the necessary conversions for realizing the targeted end-to-end communication without the need that the two ends know each other. It should be sufficient that they share the same or at least a compatible understanding of the related domain.
This building block consists of a single component: the service bus.
| Artefact: Service Bus | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.bus.service {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.bus.service.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.bus.service.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.bus.service.osgi/index.html |
- Distribution and heterogeneity of Service Providers and Service Requesters is hidden from the involved parties
- No a priori agreement is required between Service Providers and Service Requesters
- Available services can be queried and listened to
- The service consumption is semantics based - Service Requesters specify the semantics of the requested service, rather than specifying its syntax
The Service Profiles and Service Requests will be formulated in two ways:
- using Java classes mapped to OWL classes. The idea is to save the programmers working directly with RDF, OWL and SPARQL. Currently, Semantic Web technologies are not widespread enough and they are not part of standard Computer Science curriculum. Many programmers are unfamiliar with the Semantic Web technologies and can be intimidated by them.
- using RDF and OWL directly - more terse way than the Java classes
Match Making is finding appropriate Service Operations according to their Service Profiles, that match Service Request.
The current match making in universAAL: The service request is broadcasted to all service providers with matching service profiles. However, if one service provider has several matching service profiles - the best service profile of that service provider is chosen. The "best" here means more specialized. For example, if we have the hierarchy of classes: Lamp subClassOf (isA as in OO) LightSource and two service profiles - one that talks about a Lamp and another that talks about LightSource. If a service request for an operation on a Lamp will be sent, the best profile is the one that talks about a Lamp, since it is more specialized. The profile that talks about LightSource matches the request for an operation on a Lamp, since Lamp isA LightSource, however it is less specialized than the profile that talks about Lamp, so it is not chosen. A profile that talks about specific values will be preferred over a profile that talks about generic values. For example, a profile that handles some specific lamp or a lamp at some specific location will be preferred over the profile that talks about all the lamps. This way less parameters will be sent providing better performance.
The matchmaking is based on sub class relationships (rdfs:subClassOf) for Service classes, and makes heavy use of the basic matchmaking capabilities of Data Representation building block of the middleware for matching input, output, and effects.
The current protocol is as follows:
- ServiceProvider (that implements ServiceCallee) registers ServiceProfile
- ServiceRequester sends ServiceRequest to the ServiceBus, by passing the ServiceRequest to ServiceCaller.call() method
- Matchmaking is performed by the ServiceBus
- ServiceCall object is created by the ServiceBus from ServiceRequest
- input parameters are deduced from the service request according to "filtering inputs"
- ServiceCall object is passed to ServiceProvider.handleCall() method
- ServiceProvider.handleCall() processes the call and returns a ServiceResponse
- the ServiceResponse is returned to the ServiceRequester.
- Service provider can unregister the service
There should be a possibility to query existing services without calling them. There should be also a possibility to register as a listener to some services and receive notifications when some service becomes available/unavailable.
This way the Service Requesters will be able to
- dynamically react to changes in Service Providers (register/unregister)
- query for existing services and implement their own custom match making, not using the standard match-making mechanism
Service Profiles and Service Requests
The current implementation is based on org.universAAL.middleware.service.owls.profile.ServiceProfile and org.universAAL.middleware.service.ServiceRequest in mw.bus.service.core.
Match-Making
The current implementation is based on org.universAAL.middleware.service.impl in mw.bus.service.core.
The Protocol
The current implementation of the protocol is in org.universAAL.middleware.service.ServiceBus, other interfaces/classes in org.universAAL.middleware.service, and in org.universAAL.middleware.service.impl.ServiceBusImpl, in mw.bus.service.core.
Querying services, listening to services
The listening is implemented by org.universAAL.middleware.service.AvailabilitySubscriber, org.universAAL.middleware.service.ServiceBus.addAvailabilitySubscription(), in the mw.bus.service.core.
The querying is done via the following methods:
- public ServiceProfile[] getAllServices(String callerID);
- public ServiceProfile[] getMatchingService(String callerID, Service s);
- public ServiceProfile[] getMatchingService(String callerID, String[] keywords);