Client

clappingknaveΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 7 χρόνια και 8 μήνες)

290 εμφανίσεις

1


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


enTish: an Approach to
Service Composition

2

Client
-

Server paradigm


for distributed computing


c
lient

Server:

services

request


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


… ???

3

RPC model


remote procedure call


RPC

c
lient

RPC

service

c
lient stub

XDR

service

stub


XDR

Transport Protocol ( … )

Network Layer (TCP/IP)

request

response

request

request

request

response

response

response

request (call)

response (return)

Message Exchange Pattern:
stateless synchronous request
-

response

4

Web services model


RPC
-
style: remote operation call


WS

c
lient

WS

service

service proxy

(SOAP+WSDL)

service

template


(SOAP+WSDL)

Transport Protocol ( HTTP )

Network Layer (TCP/IP)

request (call)

response (return)

Message Exchange Pattern:
stateless synchronous request
-

response

5

Web services model


document passing style


WS

c
lient

WS

service

service proxy

(SOAP+WSDL)

service

template


(SOAP+WSDL)

Transport Protocol ( HTTP )

Network Layer (TCP/IP)

Message Exchange Pattern:
stateless asynchronous document passing

XML document

???

6

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

yet another service
invocation protocol


c
lient

service


invocation

protocol*

request:

response:


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.


Message Exchange Pattern:
( … )

*)
the conversation parties may have states

9

BookStore

BANK

A new service invocation protocol
:


Composition of two services


payOrder

bookOrder

Client:




payOrder



payConfirm

bookOrder

bookInvoice

Purchase
completed
!

Client

10

input
constrains

The protocol

in action:

Phase 1
-

workflow formation

BookStore

BANK

query for a book
of a fixed author

author(book
I
nvoice)=„J.R.R. Tolkien”

title(book
O
rder)=„Hobbit”

...=„The Lord of the Rings”

...=„Silmarillion”

value(pay
C
onfirm)=„50”

...=„70”

...=„60”

value(pay
O
rder)=„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 service
s

to
the client

Client

chooses one option, then
the documents


payOrder and bookOrder are created and …

Client
I
-
01

11

BookStore

BANK

The protocol

in action:

Phase 2
-

w
orkflow execution


payOrder

bookOrder

data (e
-
documents) are processed and effect the real world


ClientI
-
03




payOrder

5
0+3 euro


payConfirm
5
0 euro

bookOrder
„Hobbit”

bookInvoice
for the book

Purchase
completed
!

„Hobbit” for
5
3
euro

Client
I
-
02

12

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

13

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.


service


service

query:
output

query:
input1

query:
input2

output


input1


input2


14

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



N
ot in a generic way, i.e., these specific data
and operation types MUST be hard
-
coded in
these implementations


15

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

16

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?

17


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/

say nothing

that isn’t worth saying

18


www.ipipan.waw.pl/mas/

say nothing

that isn’t worth saying