1 / 36

Semantic description of service behavior and automatic composition of services

Semantic description of service behavior and automatic composition of services. Oussama Kassem Zein Yvon Kermarrec ENST Bretagne France. Agenda. Introduction and Context Our proposed metadata model for service description An implementation of a facilitator based on ontologies

khanh
Download Presentation

Semantic description of service behavior and automatic composition of services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related