A facilitator to discover and compose services Oussama Kassem Zein Yvon Kermarrec ENST Bretagne

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

3 Agenda Introduction Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for composition of services Conclusions

4 Introduction 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

5 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

6 A few definitions Service type = Service offer =

7 Functionalities

8 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

9 Agenda Introduction Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for composition of services Conclusions

10 Introduction 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 ?

11 The proposed model We propose to describe a service by three levels: Static properties : 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 for interactions with the service Behavior: it indicates the functionality of the service (the sequences of the service operations) and allows the composition of services

12 The static properties Static properties: Service location: it determines the location of the service like an URL address, a company physical address (city name, street name, postal code and so on) Service provider: his name, his location, his phone number, his , the URL address of his Web site and so on

13 The interface description The interface description means the description of its operations and their parameters, its attributes, etc. 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 The behavior description (1/4) The service behavior indicates what the service can do It indicates the orders by which the operations of the service can be invoked The description of the behavior includes the description of the functionalities of each operation and the possibility to connect it to other operations

15 The behavior description (2/4) Based on SDL and Interface Automata, we can describe the service behavior with an automaton (extended finite state machine) Each operation can be described by inputs and outputs The state of the automaton represent the service operations. Two states are connected if an input of one is equal to the output of the other one A transition from a state S to another state T is made by running the operation represented by S

16 The behavior description (3/4) An automaton example:

17 The behavior description (4/4) Description: the question is how a client can discover a service by querying its behavior? Black box that indicates what the service can take in input and can provide in output White box that indicates the sequences of the service operations to provide an output from a given input

18 Agenda Introduction Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for composition of services Conclusions

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

20 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

21 The facilitator in action

22 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].

23 Agenda Introduction Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for composition of services Conclusions

24 Composition of services (1/3) 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

25 Composition of services (2/3) Example: a client queries a service that transforms a “tex” file into “pdf” file

26 Composition of services (3/3) The composed service appears as a new service

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 Our proposed metadata model for service description An implementation of a facilitator based on ontologies Our approach for composition of services Conclusions

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 Integrated our facilitator in existing platform (ORBACUS, JACORB)