Semantic description of service behavior and automatic composition of services

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

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. 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. 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. A few definitions • Service type = < name, interface type, service property type> • Service offer =< service type name, an object reference, properties>

6. Functionalities

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. 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. 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. 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. 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. 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. 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. 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. Behavior Description (2/4) • PRICE[price =>> INTEGER]. • PRICE_CUSTOMERID [price =>> INTEGER; Customer_id =>> INTEGER].

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. 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. 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. 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. 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. 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. The facilitator in action

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. 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. 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. Composition of services (2/2) • A client queries a service that takes as input an “Isbn” of a book and as output “OrderSuccess”

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. 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. 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. 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. 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. 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. 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. 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. 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. Perspectives and work in progress • Current investigations : • Definition of user profile to adapt the service composition the needs of users • Taking into account the QoS when composing services