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 = < name, interface type,

service property type>

Service offer =< service type name, an object reference, properties>

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 email, 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)