Upload
shanna-parks
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
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)