Transcript Agentspace-Entish

enTish: an Approach to
Service Composition
Stanisław Ambroszkiewicz
the leader of the enTish team
IPI PAN, Polish Academy of Sciences
and Institute of Informatics, University of Podlasie,
Poland
1
Client - Server paradigm
for distributed computing
client
request
Server:
services
 Server provides some services for clients.
 Client sends a request to the server.
 The request is realized by invoking a service.
 Service invocation protocols:
RPC-style
message passing style
… ???
2
RPC model
remote procedure call
Message Exchange Pattern: stateless synchronous request - response
request (call)
RPC
client
request
RPC
service
response (return)
response
response
client stub
XDR
request
request
service stub
XDR
response
response
request
Transport Protocol ( … )
Network Layer (TCP/IP)
3
Web services model
RPC-style: remote operation call
Message Exchange Pattern: stateless synchronous request - response
WS
client
request (call)
response (return)
service proxy
(SOAP+WSDL)
WS
service
service template
(SOAP+WSDL)
Transport Protocol ( HTTP )
Network Layer (TCP/IP)
4
Web services model
document passing style
Message Exchange Pattern: stateless asynchronous document passing
WS
client
XML document
???
service proxy
(SOAP+WSDL)
WS
service
service template
(SOAP+WSDL)
Transport Protocol ( HTTP )
Network Layer (TCP/IP)
5
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?
6
yet another service
invocation protocol
Message Exchange Pattern: ( … )
response:
request:
client
invocation
protocol*
service
 Grid services: service is augmented with state and specific
portTypes; ?grid service invocation protocol?
 Is it possible (reasonable) to construct a service invocation
protocol different than RPC and document passing?
 It seems that it is!
 Let’s present a sketch of such protocol.
*) the conversation parties may have states
8
A new service invocation protocol:
Composition of two services
Client
payOrder
BANK
payConfirm
payOrder
bookOrder
BookStore
bookOrder
Client:
bookInvoice
Purchase
completed!
9
The protocol in action: Phase 1 - workflow formation
Client sends a query that is propagated back by services to the client
ClientI-01
query for a book
of a fixed author
value(payConfirm)=„50”
author(bookInvoice)=„J.R.R. Tolkien”
BookStore
BANK
...=„70”
value(payOrder)=„53”
...=„60”
...=„73”
input
constrains
...=„63”
title(bookOrder)=„Hobbit”
ClientI-02
title
price
Hobbit
53
The Lord of the Rings 73
Silmarillion
63
...=„The Lord of the Rings”
...=„Silmarillion”
Client chooses one option, then the documents
payOrder and bookOrder are created and …
10
The protocol in action: Phase 2 - workflow execution
data (e-documents) are processed and effect the real world
ClientI-02
payOrder
50+3 euro
BANK
payConfirm
50 euro
payOrder
bookOrder
bookOrder
„Hobbit”
ClientI-03
Purchase
completed!
BookStore
bookInvoice
for the book
„Hobbit” for 53
euro
11
a new service
invocation protocol
 It is not the stateless synchronous
request-response MEP nor stateless
asynchronous document passing!
 Service must be „intelligent”, i.e., it must
be able to answer the queries
12
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.
query:
input1
query:
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.
input1
output
service
service
query:
input2
input2
13
a new service
invocation protocol
 Can this protocol be implemented in the style
of RPC and/or document passing?
 Of course, it can be, e.g., by using BPEL4WS,
WSCI, BPML, etc..
 Not in a generic way, i.e., these specific data
and operation types MUST be hard-coded in
these implementations
14
SOAP+WSDL versus the
new protocol
 SOAP+WSDL service
invocation protocols:
RPC-style, or document passing
stateless
data flow and control flow
integrated into one message
simple request-response MEP
synchronous, or asynchronous
 Our proposal of service
invocation protocol:
new style of service invocation
state full
data flow is separated from the
control flow
two phases: one for control
flow and one for data flow
asynchronous control flow, and
asynchronous data flow
15
a new service
invocation protocol
Requirements:
clients and services MUST keep the state of the current
protocol session
generic open language for describing:
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
message format, and state format
message transport protocol, and data transport protocol
etc.,
Can these requirements be realized?
16
say nothing
that isn’t worth saying
YES, they can!
enTish is our proposal to realize the requirements
for new service invocation (composition) protocol
enTish is a specification; prototype was already
realized
more details on www.ipipan.waw.pl/mas/
17
say nothing
that isn’t worth saying
www.ipipan.waw.pl/mas/
18