Middleware Realisation
6.5 Programmatic Complexity
The evaluation results reported in Chapter 3 and Chapter 5 have demonstrated that the algorithms and data structures are light and effective. In this section, we move our attention to show how application engineers would use MoSCA in practice, to gather a sense of the programmatic complexity of our framework. To do so, we consider the lines of code required to:
• request the execution of a specific composite service (i.e., target service request);
• request the execution of a service appealing to an active user (i.e., discovery service request);
• advertise a service to the MoSCA framework.
6.5.1 Target Service Request
Requesting a specific service in MoSCA requires three steps: (1) the creation of a Com-posite Service object, specifying the taxonomy and service identifiers; (2) the creation of a Token object, containing input parameters in the form of attribute-value pairs, and (3) the invocation of the service itself, via the Service Manager. For example, in order to request a service s, with unique type serviceID within the taxonomy taxonomyID, and to pass as input a string variable of name postcode set to W C1E6BT , simply requires:
CompositeService s = new CompositeService(taxonomyID, serviceID);
Token t = new Token("postcode","WC1E 6BT");
ServiceManager sm = new ServiceManager();
sm.requestService(s,t);
Let us consider the case now of a composite service that is not associated to any taxon-omy (hence its type is unknown); this service can however be described as the sequential composition of a service of type serviceID1 and another service of type serviceID2, both according to the taxonomy identified by taxonomyID.
In this case, the composition has to be programmatically defined prior to invocation, as the composite service has not been pre-encoded in the taxonomy in use:
CompositeService s1 = new CompositeService(taxonomyID, serviceID1);
CompositeService s2 = new CompositeService(taxonomyID, serviceID2);
Chapter 6 6.5 Programmatic Complexity
CompositeService s= new CompositeService(Service.SEQUENCE);
s.add(s1);
s.add(s2);
Token t = new Token("postcode","W1B 2EL");
ServiceManager sm = new ServiceManager();
sm.requestService(s,t);
Note that it is transparent to the application programmer whether component services (e.g., s1 and s2) are themselves composite or basic, as all services are requested as Com-posite Service objects.
Rather than using MoSCA programmatic interface, specific services can be requested by passing a Uniform Resource Identifier (URI) to the Service Manager instead.
Given the URI definition: <scheme name>:<hierarchical part>[?<query>][#<fragment>], MoSCA ex-pects to find both the taxonomy identifier and the service identifier within the hierarchical part of a URI, following the patterns: /tid-<taxonomy ID>/ for the taxonomy, and
/sid-<taxonomy ID>/ for the service. Service parameters are passed as part of the URI itself, or separately using a POST method if the input data is too large to fit the <query> part of an URI. For example, the following fragment of code illustrates how to request a service of type 0034 according to the taxonomy identified by 01 using a Bluetooth schema:
String uri=
"btspp://0012F3008606:1;name=service/tid-01/sid-0034"
ServiceManager sm= new ServiceManager();
sm.requestService(uri);
The following fragment of code requests a service of type 0034 according to the taxonomy identified by 01 using an HTTP schema instead:
String uri=
"http://84.9.114.203/service/tid-01/sid-0034/"
ServiceManager sm= new ServiceManager();
sm.requestService(uri);
In case parameters have to be passed as well, we can use the URI query part as follow:
Chapter 6 6.5 Programmatic Complexity
String uri=
"http://84.9.114.203/service/tid-01/sid-0034/?postcode=W1B\%202EL";
ServiceManager sm= new ServiceManager();
sm.requestService(uri);
In case the service has not been associated to any taxonomy, but can be defined as the sequential composition of a service of type 0001 and of a service of type 0002 according to the taxonomy identified by 01, then the URI is enriched with the pattern /c-<composition type>/ as follow:
String uri=
"http://84.9.114.203/service/tid-01/c-SEQ+01*0001+01*0002/";
ServiceManager sm= new ServiceManager();
sm.requestService(uri);
Note that, in all examples above, the identifiers for both service types and taxonomies have been trivialized to simplify presentation and indeed may not be numerical and that short (also, for clarity of presentation, we have not encoded all symbols in the URI as they should have been). However, the programmatic complexity involved in a MoSCA composite service request is minimal. In fact, for any new request, application engineers need only to create a Composite Service object and request its execution. They do not see its mobility and service composition; they do not know, neither they need to know, whether the service is simple or composite, and/or delivered by static or mobile providers.
Overall, hence, MoSCA achieves an high level of transparency.
6.5.2 Discovery Service Request
Requesting a personalised service may be more or less complicated depending on the kind of constraint we want to impose on MoSCA discovery intelligence.
The simplest constraint would only dictate the type of service to look for. To do so, the developer/application must create a taxonomy filter by passing one (or more) tax-onomy ID -services IDs pair(s) (or, for more flexible filters, an XPath expression [Clark and DeRose, 1999] [Berglund et al., 2010]). In either case, the developer needs to know the Taxonomy in use. For example, in order to request a service, within the taxonomy taxonomyID of unique type sID1, and to pass as input a string variable of name postcode set to W C1E6BT , requires:
Token t = new Token("postcode","WC1E 6BT");
TaxonomyFilter tf= new TaxonomyFilter(
Chapter 6 6.5 Programmatic Complexity
taxonomyID, sID1
);
/*
* or we could pass instead the XPath expression
* taxonomy[@id=taxonomyID]//service[@id=sID1]
*/
PersonalProfile pp= new PersonalProfile(userID);
ServiceManager sm = new ServiceManager();
sm.requestService(tf,pp,t);
Note that the service request gets, as parameter, the user’s profile, so to elect a service appealing to the user whose user identifier is userID
As in the case of target service request, the programmatic complexity is very low, as application engineers are only required to instantiate a Taxonomy Filter and a Personal Profile before invoking the service request.
6.5.3 Advertising a service
Service advertising follows a very similar mechanism to URI-based targeted service re-quests, with the exception that the first part of the <hierarchical part> must uniquely identify the device in the surroundings providing that service. For example, a device providing a service accessible via its Bluetooth interface could advertise:
btspp://0012F3008606:1;name=service/tid-01/sid-000034
while a device providing a service via its WiFi interface could advertise:
http://84.9.114.203/service/tid-01/sid-000034/
For what concerns the service registry, we use a lightweight distributed approach that builds on the Web robots.txt [rob, 2001] and Sitemap specifications [sit, 2006]. For instance the services exposed by a device via its Bluetooth interface would be enlisted at:
btspp://0012F3008606:1;name=service.txt
Similarly the services exposed by a device via its WiFi interface would be enlisted at:
Chapter 6 6.6 Summary
http://84.9.114.203/service.txt
Indeed, though, any mobile service advertising protocol could be used for this purpose, even a simple broadcast.
6.6 Summary
In this Chapter we have presented a realisation of the discovery methods presented in Chapter 2 and Chapter 4.
First, we have contextualised the discovery methods proposed within the broader problem of service composition. We did so by means of a new architecture framework – MoSCA – that provides developers with abstractions to invoke and run the services discovered.
We have then looked at the Service Discovery component in particular, and proposed to realise a new discovery paradigm as a chain of discovery filters.
We have presented how the framework can be deployed on devices with different resources.
Finally, we have discussed the programmatic complexity that MoSCA offers application developers, both to formulate service requests and advertisements. We believe that the high level of transparency achieved sets MoSCA as a viable middleware for the development of pervasive services in mobile environments.