Scooby: Middleware for Service Composition in Pervasive Computing Jon Robinson, Ian Wakeman and Tim Owen University of Sussex
[email protected]
ABSTRACT In this paper we argue for middleware languages that aid in service composition. We outline where such languages could be useful through the description of our current architecture, and describe what we believe are the key requirements of such a language. We outline the current state of our implementation, and conclude by describing what requirements are placed on service providers by such composition middleware.
Categories and Subject Descriptors D.2.12 [Software Engineering]: Interoperability
Keywords Pervasive Computing, Middleware, Language Design
1.
INTRODUCTION: PUTTING USERS IN CONTROL OF THEIR SERVICES
Pervasive computing technology can greatly assist users by automating many chores and allowing the user to tailor their environment according to personal preferences. However, there remains the key problem of how a user actually ties all these services together in ways that are useful to their personal requirements. Since many of these computing devices will control and affect personal and domestic aspects of life, they will typically be used by non-technical people. Clearly, these users cannot be expected to provide a formal specification on how to configure the devices and services in their environment, in order to carry out their wishes. In current work on the Nathab project [1], we are tackling this problem by bringing together and applying research in the fields of Natural Language Processing (NLP), HumanComputer Interaction (HCI) and Networked Services [2]. Our goal is to explore the issues involved in building a system that enables users to employ natural language descriptions of how they want their environment to be tailored (i.e.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing Toronto, Canada Copyright 2004 ACM 1-58113-951-9 ...$5.00.
their policies) with reference to the services that are available to them. Figure 1 shows the high-level architecture of the system we are building. At one extreme we have users, and at the other we have a collection of services that can affect (and be affected by) the user’s environment. The set of available services and their functionality is described in terms of an ontology. Ultimately, the goal is that users will be able to describe, browse and edit their policies by interaction through a multi-modal interface in which policies can be expressed using a combination of text, speech and diagrammatic representations. Underlying these modes of input is a common representation of that policy, expressed in Description Logic [3]. Each policy is expressed in terms of the concepts known in the ontology. The next stage is to implement the policy by translation into a set of composed services for a policy manager. A policy compiler turns policy specifications into composed services in the Scooby middleware language, and the policy manager routes events and requests to the composed services according to a policy precedence ordering. In this paper we will be describing the Scooby middleware language, enumerating the challenges of service composition, the approaches we have taken to these challenges, and showing how the language can implement various example sets of policies. We conclude by describing the current state of implementation.
2.
COMPOSITION MIDDLEWARE: THE CHALLENGES
Within the Nathab project [1], we have collected a corpus of natural language description of policies that people wish to implement. Many policies can be described in typical policy management style as allow/deny based on identity, but a significant number of policies can best be described as a service composition, such as send me an email if anybody else uses my printer or convert print jobs in pdf for printing on my postscript printer. In the rest of this paper, we assume that such policies are captured through an interface and policy manager that has disambiguated and resolved any feature interactions between the policies, and is in a format that is ready to be compiled into a service composition. Having described and resolved any problems in their service policies and compositions, users will just expect the system to obey their demands. Whenever the user is in some context in which a policy or composed service is valid, they will expect the system to respect their demands. The major challenge of the composition middleware is to ensure that the policies can be obeyed whatever the context.
Users Multi−modal Interface Define Policies
Core Lexicon GUI
Speech
NL Text
.... Maps To
Generates
Standard Upper Ontology
Produces Formal Policy Representation
Refers To
Compiled Into
Ontology Of Services
Domain Instance Knowledge
Policy Instructions
Interpreted By Policy Manager Implemented By Scooby Service Composition Layer Events
Service Descriptions
Events
Requests Heating Service
Calendar Service
Location Service
Printing Service
....
Figure 1: The overall architecture
Despite the dominance of large software companies, it seems unlikely that there will be a software monoculture in the future pervasive computing substrate. Different software technologies will flourish in different contexts. Some will use CORBA, some will use DCOM, and some will use RMI. Different naming and service discovery paradigms will be in place, such as UPnP [4], JINI [5] and SLP [6]. The initial requirement of Scooby is to be independent of any particular software environments, and provide implementations across multiple platforms. This leads us to build Scooby as a language independent of the underlying framework. Scooby must still be able to refer to service instances, and invoke methods upon the services. We therefore need to be able to define interfaces. Interfaces define the set of methods that can be called upon the service. We are allowing interfaces to services to both be imported, and to be defined within the language. There is therefore a need to support the use of opaque types facilitating the type checking of external objects, and to support a type system that will help in the design of service descriptions. The services and policies described by the user can be implemented using simple conditionals using the current state of environmental sensors and software entities. The Scooby language must therefore be more than a simple interface definition language, and must allow the execution of simple blocks of code. A major challenge is in mapping from user descriptions of state to the attributes of the services and objects within the context. Our aim is that users should only have to describe their policies and composed services once. After this, the overall system will integrate new services into the existing customised framework. However, the terms employed by users to describe attributes and services may not match the terms used by any new services. This problem is solved in the overall system through the use of dynamic ontologies, in which service descriptions are compiled into the existing ontology, providing ways of recognising synonyms, hyponyms and hypernyms [7]. Scooby should therefore provide a method of fuzzy matching attribute names and values on services and objects. Further, it should allow attributes to be externally imposed upon services. An associated issue which we are not discussing in this paper is how to cope with the heterogeneity of description method, eg by WSDL [8], DAML-OIL [9] or derived directly from the service source code. In any context, the availability of services will vary greatly. People are inclined to turn devices off, and replace them with other gadgets. The Scooby middleware should therefore not require fixed bindings between references and their targets. Instead, the bindings should come as late as possible, allowing the policies and services to work with whatever is in the environment, as put forward in the Intentional Naming System[10]. One traditional distributed system problem that does not need to be addressed is the issue of scaling. Each context in which services will interact on behalf of the user will in general be small, with limited numbers of services. We can therefore assume that the system does not need to scale to large numbers of services. Indeed, we expect the Scooby services for a given context to exist on a single machine, communicating with the services within the context by whatever network systems are available.
Since we do not need to scale to large numbers of devices, the problem of determining the current state of any object within the system becomes much easier, either by caching centrally, or by interrogating the entity directly.
3.
THE SCOOBY ARCHITECTURE AND LANGUAGE
The Scooby middleware provides a composition language for the management and organisation of services. Although the ultimate aim is for Scooby services to be generated automatically, it is designed to be easily programmed directly. We have adopted a standard object oriented approach to typing the interfaces describing services, using single inheritance. Interfaces are defined through the method and attribute signatures. The detailed semantics are still fluid and amorphous, although they are likely to be close to Java. Service GenericService extends MoreGenericService { bind var1 to Type1 match { attributeName: arbitraryValue } bind eventVar to EVENT {attributeName2: someValue } { # Code that is executed when bindings work Statement1; Statement2; } { # start of method declarations public void method( blob file ) { blah; blah; ) } # end of method declarations } when bindexception{ reporterror( "error occurred" ) terminate }
Figure 2: Example Scooby code Services are described by service descriptions that detail their functionality and resolution. For the purposes of our investigation into service composition, we have adopted the notion of a binding variable that provides a link to a remote service based on its type and description attributes to provide a fine-grained matching. Services have bindings from service instances in the environment to variables. When all bindings have been made, the associated code block is executed. When an instance is created, methods defined for the service can be invoked. Instances of services or new objects of any sort cannot be created directly through the language. They either have to be created through imported factory methods, or by the surrounding runtime context, as in the policy manager above. The notion of late binding has been adopted when applied to binding variables such as var1 above. In this case, a binding variable is not initially associated with a service until as far into its lifetime as possible. Service descriptions are used to identify a matching service that satisfies the requirements laid out in the binding specification. Once a service has been identified, a link between the two will be maintained. However, during the lifetime of a service, the attributes that it advertises in its service description can evolve, and hence, any bindings to that service may become obsolete.
When bindings fail before code blocks complete, the system will raise an exception, clearing out any other bindings in the associated code block. If the conditions for execution of the composed service are still valid, then the system will attempt to bind other services matching the required context to the variables and will attempt to re-execute the code block. When a binding fails in the identification of a compatible service, it will change state until such time that it reattempts to identify any available services within the middleware that matches the binding requirements. The Scooby language adopts similar object-oriented semantics as found in other languages such as C++ or C# due to the nature of the environment and that each service can be considered to be an object. Services under Scooby have a distinct structure, as there are several sections that are used to describe specific areas of functionality. The first section of a service is to define the binding variables that are to be used globally throughout the service. Binding variables provide the link between a service and a remote service whereby the remote service is identified based on a set of attributes that are provided in its service description. As services can extend another service, they therefore have an associated type. This type is used as the basis for the binding variable to be bound to a remote service offering that particular service type. For example, a binding variable could be used to bind to a service of type Printer. To help in the process of service resolution a set of attributes are used to aid in the fine-tuning of the binding variable to the relevant service. These attributes can either be defined in the service description of the service or attached to the service by some other entity, such a location manager in the system runtime environment, but as late binding can take place, these can dynamically change over the lifetime of a service. Succeeding the binding variable declaration block is the attribute definition section. This lists attributes that are to be associated with the service when it sends out its service description and is used in the process of service discovery. Attributes that are defined within this section can be altered during the lifetime of the service, which is to allow for the late binding process to evolve over time. Attribute values can be altered by the service to dynamically change the services signature and therefore its potential to satisfy some binding reference. The main code section is used to define any methods, notification handlers or binding handlers that are to be used within the service. Methods can be defined as public or private, which is used to determine their visibility within the service and externally through the service description. The language itself is Java like but is more constrained to provide a specific set of language primitives that are relevant to the language and middleware. Although Events are just another type within the language, we have added some syntax sugar to facilitate event handling within the language. Notification handlers can be defined within this section to enable event processing when event bindings become satisfied. The final section to a Scooby service is the exceptionhandling block. This is used to provide instructions on what must be done if a binding reference becomes unsatisfied during the lifetime of the service.
4.
EXAMPLES
To help in understanding the Scooby language we will introduce a couple of examples that will be used to explain services in more depth. The first example provides the scenario that a printer is available to print postscript documents through. However, if a pdf file is sent instead, the service provides the ability to convert the document into the required format via the use of an external conversion service. Service PDFPrinter extends PrinterService { bind ptr to Printer match { location : 5a22 } bind converter to Pdf2ps match { } { location:5a22 } { # start of method declarations public void print( blob file ) { if( file is PDF ) file = converter.convert(file) ptr.print(file) } } # end of method declarations } when bindexception{ reporterror( "error occurred" ) terminate }
Figure 3: PDFPrinter Service In this example, the PDFPrinter service is used to convert a document from one type to another. Two bindings are used, one to be associated to a printer, while the other is used to identify a converter service that can convert document types between ps to pdf. The print method accepts a document to be passed in and performs a check to see what type of document it is. Depending on the document type, the service composition will occur by calling the converter binding reference with the document to be converted and then by calling the printer binding to print the document. This example itself provides a very simple composition. Importantly, the service is unavailable until both a Printer and a Pdf2Ps service have been found with attributes named location and value 5a22. A more advanced example is the telephone service that has been included below. In this scenario, there are multiple devices relied upon to provide the overall functionality of the composition. Let us imagine that a person is listening to music with the lights dimmed. When the telephone rings, the service will restore the lighting levels, turn down the volume of the cd player through the duration of the telephone conversation. Once the telephone has been replaced, the lighting levels and music volume will be returned to their respective settings. In this example, there are several bindings of differing types. For instance, two of the bindings employed within this example are service bindings while two are event bindings. The cd and lighting bindings associate themselves with the corresponding services based on their types (in this case Cdplayer and Lightingcontroller) along with the context matching attributes specified. The noPhone and phoneInUse binding variables are defined as an event binding. These act as a means to associate a binding to a composite of events that can occur over an unspecified time period. The event matching searches for any
events that have attributes of type telephonedevice and an associated status. When any events that match the requisites are found then the notification handlers that are bound to these variables will become activated. Service telephone { BIND cd TO Cdplayer MATCH { location: frontroom } BIND lighting TO Lightingcontroller MATCH {location: frontroom } # Bindings for detecting phone on/off BIND noPhone TO EVENT MATCH { implements: telephonedevice & status: recieverReplaced) } BIND phoneInUse TO EVENT MATCH { implements: telephonedevice & status: ringing) } { # this service is event driven, with 2 # possibilites, phone ringing, or handset # placed back on phone INT lightingLevel = 0 INT volumeLevel = 0 # do the notification for handling when # phone rings initially ON NOTIFICATION( phoneInUse ) { volumeLevel = cd.getVolume() lightingLevel = lighting.getBrightness() cd.setVolume( 0 ) lighting.turnLightsOn() } # do the notification handler to control # when handset replaced ON NOTIFICATION( noPhone ) { lighting.setBrightness( lightingLevel ) cd.setVolume( volumeLevel ) } } } WHEN BINDEXCEPTION { REPORTERROR( "Binding exception occurred..." ) }
Figure 4: Telephone Service Within the code section of the service are two notification handlers that are bound to their corresponding event handlers. These become satisfied once the event has been matched, and bindings are created for the cd and lighting services. Inside of each are the references to the other two bindings that provide the service composition aspects to the service. Two external services are relied upon, namely the Cdplayer and Lightingcontroller. Depending on the situation, the lighting is reverted back to normal brightness and the volume of the cd player is turned down when an event indicating the telephone is ringing becomes true. Conversely, once an event has been received that indicates that the telephone conversation has been terminated, the cd and lighting services alter the luminosity and volume back to their previous levels.
5.
IMPLEMENTATION
Our current implementation of the compiler and runtime is in Java, and we have tested within the environment below. Although the overall architecture is independent of whether it is centralised or distributed, our current implementation is centralised, both for ease of implementation and because we
believe that the pervasive environment will have centralised controllers for each local context. The environment comprises a collection of devices that are scattered throughout the environment, inter-connected by an event bus provided by the Elvin [11] content-based router software. This is used as the primary form of communication between all entities within the middleware. Tuples are used to convey the information from entity to entity that can vary in complexity depending on the information that is being exchanged. As these tuples of information are comprised out of key and data sections they lend themselves ideally to both the way in which Elvin propagates events and with the process of content matching required to fulfil discovery and binding processes. XML is used as the means in which to encode data within an event so that processing can take place on the consumer of the event. Binding variables are maintained by a central binding manager that controls information flow between different services. This is to facilitate the pre- processing of information before it is delivered to the recipients so that events and other communication can be intercepted and redirected or blocked depending on the authentication of the service. Binding variables also provide the mechanism to allow RPC calls between services to occur. These are directed through the same communication mechanisms that are provided by the binding manager. Each entity within the middleware acts as both a client and server to itself with regard to service discovery advertisements and lookups. This allows for each service to be independent of any external centralised discovery service, which could introduce a point of failure. Instead, service information is stored locally so that lookup requests can be performed quickly without the need to consult an external source. This provides a more robust form of lookup, especially in such an ad-hoc fluid medium where services could become unavailable without prior notice.
6.
CONCLUSION
We believe that a significant challenge in creating usable pervasive computing will be to provide environments that can self-configure to meet users desires and policies. A major part of that challenge will be in providing middleware that can glue disparate services together to provide userdesired features. We have described our initial design and implementation of a middleware language aimed at composing services to support user policies in a variety of contexts. We believe features such as late binding of service variables, opaque typing and the use of externally defined context attributes are very useful in producing a working system. In addition, we believe that fuzzy matching of services will become increasingly prevalent, and service designers will need to provide not just working code, but comprehensive descriptions of services, to enable new services to be seamlessly integrated into the ontology of the local environment.
7.
REFERENCES
[1] The natural habitat project, 2004. http://www.informatics.sussex.ac.uk/projects/nathab/. [2] Julie Weeds, Bill Keller, David Weir, Ian Wakeman, Jon Rimmer, and Tim Owen. Natural language expression of user policies in pervasive computing
[3]
[4] [5]
[6]
[7]
[8]
[9]
[10]
[11]
environments. In Proceedings of OntoLex 2004 (LREC Workshop on Ontologies and Lexical Resources in Distributed Environments), Lisbon, Portugal, May 2004. F. Baader, D. Calvanese, D.L. McGuinness, D. Nardi, and P.F. Patel-Schneider, editors. The Description Logic Handbook. Cambridge University Press, 2003. UPnP Forum. The universal plug and play forum. http://www.upnp.org/. Sun Microsystems. Jini architecture specification, 2004. http://www.sun.com/software/jini/specs/jini1.2html/jinispec.html. E. Guttman, C. Perkins, J. Veizades, and M. Day. Service location protocol, version 2. RFC 2608, IETF, June 1999. Sam Type, Ian Wakeman, and Steven Watt. Smarter service location. In Fifth IEEE Workshop on Networked Appliance, Liverpool, UK, October 2002. Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web services description language (wsdl) 1.1. Technical report, W3C, 2001. http://www.w3.org/TR/wsdl. Ian Horrocks, Frank van Harmelen, and Peter Patel-Schneider. Daml+oil language specifications. Technical report, W3C, 2001. http://www.daml.org/. Hari Balakrishnan Jeremy Lilley William Adjie-Winoto, Elliot Schwartz. The design and implementation of an intentional naming system. In Proc. 17th ACM SOSP, Kiawah Island, SC, December 1999. http://nms.lcs.mit.edu/projects/ins/. The elvin content based router, 2004. http://elvin.dstc.edu.au/.
