1 Stanisław Ambroszkiewicz the leader of the enTish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie, Poland enTish: an Approach to Service Integration in Open and Heterogenous Environment

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

3 Client - Server paradigm for distributed computing client Server:services request zServer provides services for clients. zClient sends a request to a server. zThe request is realized by invoking a service. zService invocation protocols: yRPC-style ymessage passing style y… ???

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

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

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

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

8 a generalization of RPC coming back to client/server model client clientservice invocation protocol* Message Exchange Pattern: ( … ) client stub ( … ) service stub ( … ) ( … ) Transport Protocol (... ) Network Layer (TCP/IP) request: response: *) the conversation parties may have states

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

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

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

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

13 a new service invocation protocol zThe query phase: a query output yClient sends a query specifying the desired output. input yThe service specifies the input required to produce the desired output. zThe execution phase: creates data yClient creates data according to the input specs and sends it to the service. yService processes the data and sends the result to the client. service query: output query: input1 query: input2 outputinput1 input2

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

15 a new service invocation protocol zCan this protocol be implemented using Web services, i.e., SOAP+WSDL+UDDI ? zYES and NO! zYES, (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 zNOT, in a generic way, i.e., as a universal protocol for any data types and any operation types

16 Requirements for the new protocol zgeneric open language zgeneric open language for expressing queries ythe language must describe: xdata and their attributes xhow the data are processed, i.e., types of operation performed by services xstates of clients and services, i.e., clients’ intentions, and services’ commitments machine processable semantics is needed ! yapplications must understand the language, i.e., machine processable semantics is needed !

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

18 Generic description language zEntish zEntish is a simple version of first order logic with types and without quantifiers and without explicit negation zFormulas are evaluated in spatio-temporal manner zentish 1.0 zentish 1.0 is a protocol for service composition zenTish zenTish = Entish + entish 1.0 is our proposal of a technology for service description and composition

19 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! say nothingthat isn’t worth saying

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

21 Introducing ontologies definitions.xsd z contents language is open and eXtensible: y 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 z upper ontology for sdc: y properEntish.xml is an instance of definitions.xsd y basic primitive concepts: agent, service, resource, intentions, commitments, timeout,... zformula examples: y task formula: ?z=f(?x, g(?y)) and timeout(t0) y intention formula: φ implies intentions( agent0 )

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

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

24 common State schema for task-agent and service-agent: y Goal, Intentions, Commitments, Knowledge Message: zHeader: y From, To, Protocol, Order zBody: y a list of evaluated formulas of the description language agent’s state, and message schemas state.xsd, message.xsd

25 ywww.ipipan.waw.pl/mas/ say nothingthat isn’t worth saying