1. 1 Scooby: Middleware for Service Composition in Pervasive Computing Jon Robinson, Ian Wakeman & Tim Owen University of Sussex, UK

2. 2 Overview Challenges of Service Composition Approaches we have taken Implementation of language Examples of compositions Contributions

3. 3 Natural Habitats Use of natural language to allow users to define policies that control appliances in a pervasive home environment or smart space. Scooby (Service composition objects ordered by you) provides the architecture and service composition component of this research project.

4. 4 Compositional Middleware Challenges Due to dominance of large software companies, there is unlikely to be a monoculture in future pervasive computing. Use of different software technologies. (CORBA, DCOM,RMI) Different naming/service discovery. paradigms (UPnP, JINI, SLP)

5. 5 Compositional Middleware Challenges Scooby requirements: –Independent of any particular software environments. –Provide implementations across multiple platforms. –Scooby is language independent of the underlying framework. –Able to refer to service instances. –Invoke methods upon the services.

6. 6 Compositional Middleware Challenges –Therefore need to be able to define interfaces. Interfaces define the methods in a service. Interfaces allow services to be imported and defined within the language. Support the use of opaque types facilitating type checking of external objects. Support a type system that will help in the design of service descriptions. Services and policies implemented using simple conditionals using current state of sensors and software entities. More than an interface definition language and must be able to allow the execution of simple blocks of code.

7. 7 Compositional Middleware Challenges Mapping user descriptions of state to the attributes of the services and objects within the context. –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.

8. 8 Compositional Middleware Challenges –Problem: What happens when terms used by users to describe attributes and service do not match terms used by new services? Overall – Use of dynamic ontologies. Service descriptions compiled into the existing ontology providing ways of recognising synonyms, hyponyms and hypernyms. Scooby provides a method of fuzzy matching attribute names and values on services and objects. + Allow attributes to be externally imposed upon services.

9. 9 Compositional Middleware Challenges Availability of services will vary greatly. –People are inclined to turn devices off, and replace them with other gadgets. –Scooby should not require fixed bindings between references and their targets. –Bindings should be made as late as possible.

10. 10 Compositional Middleware Challenges Things we are not looking at: –The heterogeneity of description method Eg. WSDL, DAML-OIL –Scaling As each context in which services will interact on behalf of the user will in general be small, with limited numbers of services.

11. 11 Scooby Architecture and Language Provides a composition language for the management and organisation of services. Ideally, services are to be generated automatically but is designed to be easily programmed directly. Adopted a standard object oriented approach to typing the interfaces describing services using single inheritance. Interfaces are defined through the method and attribute signatures.

12. 12 Scooby Architecture and Language Scooby service structure: Service GenericService extends MoreGenericService { bind var1 to Type1 match { attributeName: arbitraryValue } bind eventVar to Event match {attributeName2: someValue } { # Characteristics definitions Local Characteristics/Attributes; } { # start of method declarations public void method( blob file ) { blah; blah; ) } # end of method declarations } when bindexception{ reporterror( "error occurred" ) terminate }

13. 13 Scooby Architecture and Language Binding variables are used to provide a link to a remote service based on its type and description attributes to provide fine-grained matching. Bindings can alternate between the states of: –Discovery –Suspend –Connected

14. 14 Scooby Architecture and Language Bindings periodically check for newer and more satisfy able services to which to bind to. Variables can be used to allow dynamic comparisons in binding resolution. Event bindings extend a binding by allowing them to be activated by a single or pattern of events.

15. 15 Scooby Architecture and Language Binding syntax: –Bind X to ServiceType match { attributes* } –Attributes:: Key : Data [ operator ] –Data :: String | Variable Eg 1. Bind ptr to Printer match { location: “5a22”} – string based Eg 2. Bind ptr to Printer match { location: x } – variable based –Coupled with service attributes, service can change its characteristics during its life time depending on environmental changes.

16. 16 Scooby Architecture and Language Dynamic Binding Example: Bind ptr to Printer match { location: “5a22” & status: printer_status } In the corresponding printer service the characteristics/attribute section would be defined as: { status: printer_status; } Where printer_status is defined as a service attribute within the service, and can be altered during the services’ lifetime. i.e. the service description will alter dynamically depending on the status of the printer.

17. 17 Scooby Architecture and Language Event Binding Syntax: –Bind X to Event match { attributes* } –Binding is triggered once an event, or set of events have been received. –Triggers the corresponding notification handler.

18. 18 Scooby Example 1 PDF to PS Printer Composition service PDFPrinter { bind ptr as printer match { location : “5a22” & printertype: “ps” } bind converter as pdf2ps match { } { location : "5a22" } { public void print( blob file ) { if( file is "PDF" ) { file = converter.convert(file) } ptr.print(file) } } when bindexception { reporterror( "error occurred" ) terminate }

19. 19 Scooby Example 2 Telephone Composition service myTelephoneLightComposition { bind cd as cdplayer match { location: "frontroom" } bind lighting as lightingcontroller match { location: "frontroom" } bind noPhone as event match { implements: "telephone" & status: "hungup" } bind phoneInUse as event match { implements: "telephone" & status: "ringing" } { location:“frontroom" } { int lightingLevel int volumeLevel } { on notification( phoneInUse ) { volumeLevel = cd.getVolume() lightingLevel = lighting.getBrightness() cd.setVolume( 0 ) lighting.turnLightsOn() } on notification( noPhone ) { lighting.setBrightness( lightingLevel ) cd.setVolume( volumeLevel ) } } when bindexception { reporterror( "Binding exception occurred..." ) }

20. 20 Contributions Multiple facets to solution: –Late dynamic binding variables. –Service attributes and variables to alter service capability over lifetime. –Fuzzy matching of service attributes. –Specialised composition language dedicated to this task, independent on the underlying system. –Decentralised version based on Elvin message notification system.