2. 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 Composition

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

4. 3 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: stateless synchronous request - response

5. 4 Web services model 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. 5 Web services model 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. 6 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. 7 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. 8 yet another service invocation protocol client clientservice invocation protocol* request: response: ?grid service invocation protocol? yGrid services: service is augmented with state and specific portTypes; ?grid service invocation protocol? yIs it possible (reasonable) to construct a service invocation protocol 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. 9 BookStore BANK A new service invocation protocol: Composition of two services payOrder bookOrder Client: payOrder payConfirm bookOrder bookInvoice Purchase completed! Client

11. 10 input constrains Phase 1 - workflow formation The protocol in action: Phase 1 - workflow formation BookStore BANK query for a book of 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. 11 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. 12 a new service invocation protocol zIt is not the stateless synchronous request-response MEP nor stateless asynchronous document passing! zService must be „intelligent”, i.e., it must be able to answer the queries

14. 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

15. 14 a new service invocation protocol zCan this protocol be implemented in the style of RPC and/or document passing? zOf course, it can be, e.g., by using BPEL4WS, WSCI, BPML, etc.. zNot in a generic way, i.e., these specific data and operation types MUST be hard-coded in these implementations

16. 15 SOAP+WSDL versus the new protocol zSOAP+WSDL service invocation protocols: yRPC-style, or document passing ystateless ydata flow and control flow integrated into one message ysimple request-response MEP ysynchronous, or asynchronous zOur proposal of service invocation protocol: ynew style of service invocation ystate full ydata flow is separated from the control flow ytwo phases: one for control flow and one for data flow yasynchronous control flow, and asynchronous data flow

17. 16 a new service invocation protocol zRequirements: yclients and services MUST keep the state of the current protocol session ygeneric open language ygeneric open language for describing: 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 ymessage format, and state format ymessage transport protocol, and data transport protocol yetc., zCan these requirements be realized?

18. 17 yYES, they can! yenTish is our proposal to realize the requirements for new service invocation (composition) protocol yenTish is a specification; prototype was already realized  more details on www.ipipan.waw.pl/mas/ say nothingthat isn’t worth saying

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