1. Semantic description of service behavior and automatic composition of services Oussama Kassem Zein Yvon Kermarrec ENST Bretagne France

2. 2 Agenda Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for service composition Conclusions and perspectives

3. 3 Introduction and Context Service discovery is a necessity in distributed systems An example is the service location in the mobility context A service can be considered as a product Yellow pages, Trader for CORBA and UDDI for Web services To discover a service, we must describe it by properties. If the service is well described so its discovery is more sophisticated

4. 4 ODP Trader and OMG CORBA Trader The need for objects to locate each other is a necessity : Naming service and Trading service It is an advanced directory that allows the service discovery via description called properties Clients use SQL or a Boolean language to query services

5. 5 A few definitions Service type = Service offer =

6. 6 Functionalities

7. 7 Limits The implementation of the trader is based on databases and the schema is static The language used for querying, SQL or Boolean research for ORBACUS, is limited

8. 8 Agenda Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for service composition Conclusions and perspectives

9. 9 A Metadata Model of Service Description (1/2) How to describe a service: we must to response to the questions : Who is the service provider ? How the service can be delivered? Physically or electronically ? What the service can do ? How a client can interact with the service ?

10. 10 A Metadata Model of Service Description (2/2) We propose to describe a service by three levels: Static properties or metadata: the properties that we use to query services via the standard Trader. They define the characteristics of services Interface: it defines the means and the methods to call and interact with the service Behavior: it indicates the functionality of the service (the sequences of the service operations) and allows the composition of services

11. 11 Static properties Introduction : a clear understanding and consensus about what constitutes a service has not been reached and we have defined one Characteristics : static properties Provider (Name, Address, and so on) Request and Delivery Channels (Mobile phones, Pagers, and so on)

12. 12 Interface Description (1/2) The interface description means the description of its operations and their parameters, its attributes, etc. It allows clients to discover, at run-time, the service operations and to invoke them dynamically by using for example, the DII (Dynamic Invocation Interface) of CORBA or of Web services

13. 13 Interface Description (2/2) The interface can be described by: a name, a list of operations, a list of exceptions, a list of attributes and so on An operation can be described by: a name, the return type, the number of parameters, a list of parameters and so on This description is similar to this of Interface Repository of CORBA

14. 14 Behavior Description (1/4) It indicates what the service can do It allows client to understand how the service can be invoked. We have proposed to describe the service behavior via an automaton States (Operations) are connected by their inputs/outputs. The concept “output” must be included in the concept “input”. Each service is described by inputs/outputs which are concepts in the ontology

15. 15 Behavior Description (2/4) PRICE [price =>> INTEGER]. PRICE_CUSTOMERID [price =>> INTEGER; Customer_id =>> INTEGER].

16. 16 Behavior Description (3/4) As black box As white box : the sequence of the interactions between operations to get an output from a given input

17. 17 Behavior Description (4/4) Post and pre conditions: They are conditions on inputs/outputs and service parameters A closer look at what the services offers to a client (post) when some conditions are valid (pre) Pre: holds the pre-requisite so that the service call can be made (ISBN>0) Post: describes the service effects (credit card is TRUE)

18. 18 A Metadata Model of Service Description We have proposed a complete description of the services : static, dynamic properties and interfaces The aims are to provide the same interfaces to index/retrieve any of the metadata This model opens new potentials for service call and composition

19. 19 Agenda Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for service composition Conclusions and perspectives

20. 20 Structure of Our Approach Ontology: is a formal, explicit specification of a shared conceptualization of a domain of interest A use of OntoBroker to develop tools to index / store / browse the repositories A logic language (Frame-logic) Configuring the repository of the facilitator Creation of an ontology Definition of the concepts of the ontology describing the metadata model

21. 21 Interfaces managing ontologies Importing function : it takes a query as input. It allows to search services from an ontology, invokes a selected service and returns the results to the client. Exporting function : it allows a fact to be added to an ontology Withdrawing function : it allows to delete a fact from an ontology

22. 22 The facilitator in action

23. 23 Examples FORALL x,y,z <- x:Service and x[Location->>y] and y[city->>" Paris "]. FORALL x,y,z,k <- (x:y or x:Location) and Location::y and x[z->>k].

24. 24 Agenda Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for service composition Conclusions and perspectives

25. 25 Composition of services (1/2) The goal is to create new services by combining existing services based on their behaviors to satisfy the client requests The functionality of a composed service is the composition of the functionalities of the component services The composition allows to enrich the existing service model by creating new services

26. 26 Composition of services (2/2) A client queries a service that takes as input an “Isbn” of a book and as output “OrderSuccess”

27. 27 Composition types Three types of composition: Static composition: allows to create new service offers from those existing at compile time Semi-dynamic: allows to create new service types from those existing at compile time Dynamic composition: allows to create new services from those existing at run-time

28. 28 Static composition A composed service is considered as a service offer which is constituted from other service offers This model is limited to service offers defined at compile-time If a service offer is updated at run-time, then the composed service must be updated manually

29. 29 Semi-dynamic composition (1/2) The composition of service types Each service offer having a composed service type is considered as a composed service The clients are not limited to service offers precise but they use the service types The model is more elaborate from the static model since the clients can precise the desired properties of the services to be composed

30. 30 Semi-dynamic composition (2/2) Example: in the mobility context, if a client compose a service having “weather” as a type and a service having “cinema” as a type and if the location of the client changes, the composition adapts to this change This model is limited to the service types defined at compile-time

31. 31 Dynamic composition (1/2) This model is the most elaborate one The services to be composed are defined at run- time based on the client request The facilitator returns to the client all the possible combinations of services that can satisfy the client request by connecting the inputs/outputs The client can query the component services by indicating the desired properties

32. 32 Dynamic composition (2/2) A client has the possibility to compose services defined at run-time The client can invoke the services by querying their interface and by using for example the DII interface of CORBA If an interface is updated at run-time, the client code does not need to be updated and recompiled

33. 33 Agenda Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for service composition Conclusions and perspectives

34. 34 Conclusions (1/2) Proposal of metadata model for service Description Design and implementation of an extended facilitator based on ontologies Our facilitator provides a more flexible and more powerful service request language than SQL or a Boolean type language

35. 35 Conclusions (2/2) Our facilitator provides the same interfaces to query/advertise a service by using the three levels of the service description Powerful for service composition and discovery Proposition of an approach for service composition Integrated our facilitator in existing platform (ORBACUS, JACORB, J2EE Web services)

36. 36 Current investigations : Definition of user profile to adapt the service composition the needs of users Taking into account the QoS when composing services Perspectives and work in progress