1 / 24

enTish: an Approach to Service Integration in Open and Heterogenous Environment

enTish: an Approach to Service Integration in Open and Heterogenous Environment. Stanis ł aw Ambroszkiewicz the leader of the en T ish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie , Poland. Technology vs theory for distributed computing.

abel-charles
Download Presentation

enTish: an Approach to Service Integration in Open and Heterogenous Environment

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. enTish: an Approach to Service Integration in Open and Heterogenous Environment Stanisław Ambroszkiewicz the leader ofthe enTishteam IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie, Poland

  2. Technology vs theoryfor distributed computing • We start with a great technology challenge: • How to integrate automatically heterogenous applications in open and distriubuted environment • We will end up with one of the most important problems in theory: • How to construct a generic open language describing data processing, with clear and precise semantics (machine understandable)

  3. Client - Server paradigmfor distributed computing request client Server: services • Server provides services for clients. • Client sends a request to a server. • The request is realized by invoking a service. • Service invocation protocols: • RPC-style • message passing style • … ???

  4. request (call) response (return) request response response request client stub XDR service stub XDR request response request response Transport Protocol ( … ) Network Layer (TCP/IP) RPC modelremote procedure call Message Exchange Pattern: synchronous request - response RPC client RPC service

  5. request (call) response (return) service proxy (SOAP+WSDL) service template (SOAP+WSDL) Transport Protocol ( HTTP ) Network Layer (TCP/IP) Web servicesRPC-style: remote operation call Message Exchange Pattern: stateless synchronous request - response WS client WS service

  6. XML document ??? Web servicesdocument passing style Message Exchange Pattern: stateless asynchronous document passing WS client WS service service proxy (SOAP+WSDL) service template (SOAP+WSDL) Transport Protocol ( HTTP ) Network Layer (TCP/IP)

  7. RPC-style of service invocation • After >12 years of RPC • there is no killer apps for integrating heterogenous applications • After >8 years of CORBA (object oriented RPC-style) • there is no killer apps for integrating heterogenous objects • After >3 years of Web services (service oriented RPC-style and document-style) • there is no killer apps for integrating heterogenous services • A conclusion: • Perhaps they are too primitive, i.e., more sophisticated service invocation protocol is needed?

  8. *) the conversation parties may have states yet another service invocation protocol Message Exchange Pattern: ( … ) response: request: client service invocation protocol* • Is it possible (reasonable) to construct a high level protocol for service invocation different than RPC and document passing? • It seems that it is! • Let’s present a sketch of such protocol.

  9. BANK payOrder bookOrder BookStore Client: A new service invocation protocol: Composition of two services Client payOrder payConfirm bookOrder bookInvoice Purchase completed!

  10. BANK BookStore ClientI-02 The protocol in action:Phase 1 - workflow formation Client sends a query that is propagated back by services to the client query for a book by a fixed author ClientI-01 value(payConfirm)=„50” ...=„70” ...=„60” value(payOrder)=„53” ...=„73” ...=„63” author(bookInvoice)=„J.R.R. Tolkien” input constrains title(bookOrder)=„Hobbit” ...=„The Lord of the Rings” ...=„Silmarillion” title price Hobbit 53 The Lord of the Rings 73 Silmarillion 63 Client chooses one option, then the documents payOrder and bookOrder are created and …

  11. BANK payOrder bookOrder BookStore ClientI-03 The protocol in action:Phase 2 - workflow execution data (e-documents) are processed and effect the real world ClientI-02 payOrder50+3 euro payConfirm 50 euro bookOrder „Hobbit” bookInvoice for the book Purchase completed! „Hobbit” for 53 euro

  12. service service query: input1 query: output input1 output query: input2 input2 a new service invocation protocol • The query phase: • Client sends a query specifying the desired output. • The service specifies the input required to produce the desired output. • The execution phase: • Client creates data according to the input specs and sends it to the service. • Service processes the data and sends the result to the client.

  13. a new service invocation protocol • It is not the stateless synchronous request-response MEP nor stateless asynchronous document passing! • The Key Point: queries and answers are processed by applications, not by humans • Service must be „intelligent”, i.e., it must be able to process the queries

  14. a new service invocation protocol • Can this protocol be implemented using Web services, i.e., SOAP+WSDL+UDDI ? • YES and NO! • YES, (by BPEL4WS, WSCI, BPML, etc.) but only as dedicated to this specific example; specific data and operation types of this example MUST be hard-coded • NOT, in a generic way, i.e., as a universal protocol for any data types and any operation types

  15. Requirements for the new protocol • generic open language for expressing queries • the language must describe: • data and their attributes • how the data are processed, i.e., types of operation performed by services • states of clients and services, i.e., clients’ intentions, and services’ commitments • applications must understand the language, i.e., machine processable semantics is needed !

  16. Generic description language • Machine processable semantics of the description language -- Is it possible? • YES IT IS! • Old Entish – the ancient language of Ents; in „The Lord of the Rings” by J.R.R. Tolkien • „ In the Old Entish Real, names tell you the story of the things they belong to.” • Our version of Entish: proper name contains reference to its meaning • This can be done using URIs introduced by T. Berners-Lee

  17. Generic description language • Entish is a simple version of first order logic with types and without quantifiers and without explicit negation • Formulas are evaluated in spatio-temporal manner • entish 1.0 is a protocol for service composition • enTish = Entish + entish 1.0 is our proposal of a technology for service description and composition

  18. say nothing that isn’t worth saying Treebeard's own description of the Old Entish: "It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a long time to say, and to listen to.” Thank you for the attention!

  19. Contents language Entish formula.xsd • Contents language is a simple version of typed FOL without quantifiers: • all namesin the language are URIs that point to concrete data • names for types, functions, relations, variables • terms and formulas are defined in the standard way in the schema formula.xsd • evaluated formula is defined in the schema info.xsd: • formula • time&place stamp • signature (optional in the current version)

  20. Introducing ontologies definitions.xsd • contents language is open and eXtensible: • you can introduce your own ontology as an instance of definitions.xsd, i.e., introduce new types, new functions, and new relations to the language • upper ontology for sdc: • properEntish.xml is an instance of definitions.xsd • basic primitive concepts: agent, service, resource, intentions, commitments, timeout, ... • formula examples: • task formula: ?z=f(?x, g(?y)) and timeout(t0) • intention formula: φ implies intentions( agent0 )

  21. Conversation protocol entish 1.0 • agents and services exchange messages with specific contents in order to realize: • service publication • service discovery • arranging services into a workflow • worklow execution and control • distributed transaction

  22. Conversation protocol entish 1.0 • workflow composition phase – the idea: • agent sends message to service0: „my intention is φ” • service replies: „I commit to realize φ if you realize ψ” • „ψ”becomes the next intention of the agent • agent is looking for a service that can realize „ψ” • suppose service1 could realize „ψ” • agent sends message to the service1: „my intention is ψ” • and so on ... more in enTish-Docs.pdf

  23. agent’s state, and message schemasstate.xsd, message.xsd common State schema for task-agent and service-agent: • Goal, Intentions, Commitments, Knowledge Message: • Header: • From, To, Protocol, Order • Body: • a list of evaluated formulas of the description language

  24. say nothing that isn’t worth saying • www.ipipan.waw.pl/mas/

More Related