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

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 paradigm

for distributed computing

cclientlient Server:Server:servicesservices

request

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

RPC model

remote procedure call

RPC RPC cclientlient

RPC RPC serviceservice

cclient stublient stubXDRXDR

serviceservice stub stub XDRXDR

Transport Protocol ( … )Transport Protocol ( … )

Network Layer (TCP/IP)

requestresponse request

requestrequestresponse

response

response

request (call)

response (return)

Message Exchange Pattern: synchronous request - response

5

Web services

RPC-style: remote operation call

WS WS cclientlient

WSWSserviceservice

service proxyservice proxy(SOAP+WSDL) (SOAP+WSDL)

serviceservice template template (SOAP+WSDL)(SOAP+WSDL)

Transport Protocol ( HTTP )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 WS cclientlient

WSWSserviceservice

service proxyservice proxy(SOAP+WSDL) (SOAP+WSDL)

serviceservice template template (SOAP+WSDL)(SOAP+WSDL)

Transport Protocol ( HTTP )Transport Protocol ( HTTP )

Network Layer (TCP/IP)

Message Exchange Pattern: stateless asynchronous document passing

XML document

???

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?

9

yet another service invocation protocol

cclientlient serviceservice invocation protocol*

request: response:

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.

Message Exchange Pattern: ( … )

*) the conversation parties may have states

10

BookStore

BANK

A new service invocation protocol: Composition of two servicesComposition of two services

payOrderbookOrder

Client:

payOrder payConfirm

bookOrder

bookInvoice Purchase completed!

Client

11

input constrains

The protocol in action: Phase 1 - Phase 1 - workflow formationworkflow formation

BookStore

BANKquery 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

ClientClient sends a sends a queryquery that is propagated back by service that is propagated back by servicess to to the clientthe client

Client chooses one option, then the documents payOrder and bookOrder are created and …

ClientI-01

12

BookStore

BANK

The protocol in action: Phase 2 - wPhase 2 - workflow executionorkflow execution

payOrderbookOrder

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

ClientI-03

payOrder 50+3 euro

payConfirm 50 euro

bookOrder „Hobbit”

bookInvoice for the bookPurchase

completed!

„Hobbit” for 53 euro

ClientI-02

13

a new service invocation protocol

The query phase: Client sends a querya query

specifying the desired outputoutput.

The service specifies the inputinput required to produce the desired output.

The execution phase: Client creates datacreates 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

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

15

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

16

Requirements for the new protocol

generic open languagegeneric 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 machine processable semantics is needed !needed !

17

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

18

Generic description language

EntishEntish 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.0entish 1.0 is a protocol for service composition

enTishenTish = 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 nothing that isn’t worth saying

20

Contents language Entish formula.xsd

Contents language is a simple version of typed FOL without quantifiers: all names in 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.xsdevaluated formula is defined in the

schema info.xsd: formula time&place stamp signature (optional in the current version)

21

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

)

22

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

23

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

24

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

agent’s state, and message schemas state.xsd, message.xsd

25

www.ipipan.waw.pl/mas/

say nothing that isn’t worth saying