October 18, 2003 Behavioral Signatures and E-Service Composition 1 E-Service Composition and Behavioral Signatures > Rick Hull Bell Labs Research October.

1Behavioral Signatures and E-Service CompositionOctober 18, 2003

E-Service Compositionand Behavioral Signatures

<< Presentation to Semantic Web Services Langauge Grouphttp://www.daml.org/services/swsl >>

Rick HullBell Labs Research

October 18, 2003slides will be available at http://db.bell-labs.com/user/hull

Michael Benedikt (Bell Labs)

Vassilis Christophides (FORTH, Greece)

Jianwen Su (UC Santa Barbara)

Based in part on the PODS 2003 talk entitled “E-Services: A Look Behind the Curtain”,

co-authored with

October 18, 2003 Behavioral Signatures and E-Service Composition 2

The E-Services Paradigm•Goal: Simplify and/or automate e-service

– Discovery– Composition – Orchestration (invoke, monitor; “choreography”)– Provenance (e-science, recovery)

•Primary roots of e-services paradigm(a) Process description formalisms(b) Distributed computing middleware (c) Data management

•What makes e-services “new”– Much more de-centralized than workflow– More flexible, less structured than CORBA– Data management has larger role in (a) and (b)– Importance of standards to enable

interoperation and analysis

Our focus: how to build, analyze


Outline

•Events, messaging, and sequential behavior are facts of life– We need a notion of “behavioral signature”

•An automata-based framework– Inspired by CSPs, -calculus, verification theory

•Analysis “tools”– Several approaches available

•Automated composition– Including a bridge to DLs

•Conclusions


Web Services Definition Language (WSDL): Messages and (traditional) I/O signatures•Peer-to-peer: e-service can act as client or server

– Proactive : send request send request, block till response– Reactive : receive request receive request, send response

order

receipt

bill

payment

order

receipt

bill_payment out: bill in: payment

•Port: mechanism to cluster operations– Port as unit of interoperation between services

Supplier Supplier’


E-Commerce: Patterns of Messages

order1

ok

receipt1

bill 1payment 1

authorizegetbuy

•Certain patterns “acceptable”, others not•Enactments with different life-cycles

– E.g., one credit authorize for many orders

store bank

supplier1

order2

receipt2

bill 2

paym

ent 2

•Add new services dynamically – Does supplier2 fit? (what if supplier2 uses “prepay”)

supplier2


Using order toinfer IOPA properties

•Conditions on input/output– if valid client sends order, then bill is created– if payment is received, then receipt is sent

•Conditions on “state of world”– Amount of $$ in line of credit– Supplier ships order when payment is received

•Performing inference (“everything else fixed”)– Assume the Bank satisfies: if bill received and sufficient

funds, then payment is sent– Infer that: “an order from a valid client with sufficient

funds will result in a receipt and shipment of the order”

order

receipt

bill

payment

Supplier


Services use events

•“Full” plane reservation service includes alerts if plane is delayed– To person flying– To car rental service, to hotel service, …

•Services may have to retain context over a period of time– Will be “waiting” for incoming event– Put it into proper context– Take appropriate actions

•BPEL4WS has explicit constructs for asynchronous events – receive, wait, pick


Telecom/Collaborative Services

•Emerging standards will enable flexible, dynamic invocation of services & incorporation of features– Can be viewed as a special case of web services– Bearer traffic vs. signaling/control traffic

•Asynchronous events: call dropped, person becomes present, …

•Feature interactions: call screening, call waiting, …

ProfileData

PresenceServer

MediaServer(voice)

MediaServer(video)

Pre-Pay

SessionCoordinator


Outline

•Sequential behavior and messaging are a fact of life– We need a notion of “behavioral signature”

•An automata-based framework– Uses a “black-box” perspective– Contrast to “white-box” formalisms

•Some “tools” are available– Including a bridge to DLs

•Conclusions


Two perspectives on E-Services•“Black box”: Signature languages

– Web Services Description Language (WSDL)•Focus on input/output signatures only

– Pre-/post conditions á la OWL-S– Behavioral:

•Focus on sequencing of messages transmitted– W3C Choreography group working here

•Focus on sequencing of actions performed

•“White box”: Implementation languages– Essence of WSFL, XLANG, BPEL4WS*, BPML, etc.

standards– OWL-S process constructs– Typically, parallel flowcharts with synchronization,

scopes, some event handling, internal variables*BPEL4WS also supports a “black box” view of e-services


Modeling I: Individual E-services

• In the most general case, an e-service can be a Turing machine

•For analysis, optimization, and automation it is useful to study more restricted models

inputmessages

to othere-services

Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice

local storemessage log


Behavioral signatures using messages

•Can model single or sequenced enactments •Advantages for analysis, e.g., verifying temporal

properties, characterizing global behavior

?o

!r

!b

?p

?p

!r

!r

!border

rcpt

bill

pymnt

order

rcpt

bill

pymnt

!b ?p !r ?o

(a) “cautious” supplier (b) “trusting” supplier

•Use Mealy Peers: Finite State Automata with input/output– Follows spirit of process algebras, communicating processes


Modeling II: A composition framework

•A peer: autonomous process executing an e-service•Assume reliable communication

Peer 1

Peer 2

. . .

Peer n


C : finite set of peer-to-peer channels

•An E-C schema is a triple (P, C, M)Specifies the infrastructure of composition

E-Composition Schema

authorize

M : (finite) set of message classes

ok

bill 2

paym

ent 2

order1

receipt1

order2

receipt2

payment 1

bill 1

P : finite set of peers (e-services)

store bank

supplier1 supplier2

•Many variations on this base model possible, e.g., – Different levels of granularities– Assume finite domains can model parameters explicitly


Combining Peer and Composition Models

•Peer fsa’s begin in their start states

. . .. . .

. . .

store

supplier1 supplier2

. . .

bank!o 1

!a ?k

!o2

?b1

?a !k

?o1 !b1?o2

?r 2

!b2


a

Executing a Mealy Composition (cont.)

. . .. . .

. . .

store

supplier1 supplier2

. . .

bank

•STORE produces letter a and sends to BANK

!o 1!a ?k

!o2

?b1

?a !k

?o1 !b1?o2

?r 2

!b2


Executing a Mealy Composition (cont.)

•BANK consumes letter a•Execution successful if all queues are empty

and fsa’s in final state

. . .. . .

. . .

store

supplier1 supplier2

. . .

bank!o 1

!a ?k

!o2

?b1

?a !k

?o1 !b1?o2

?r 2

!b2


“State” and “Conversation”

•The state of the composition is based on– state of each peer– contents of the queues

•Conversation : one enactment of global process– Can have “sub-conversations” of a conversation– Little known about formal properties of conversations

r2

r2

b1b2

o1

. . . . . .!o 1

!a ?k

!o2

?o2 ?r 2

!b2

?o1 !b1 . . .

store

supplier1 supplier2

. . .

bank

o2o2

?b1

?a !k


Important Choices for Message-based Composition Model

•Representation formalism for peer implementations

•Expressive power of peer implementations

•Bounded vs unbounded queues

•Several queues vs one queue vs heap vs …

•Open vs closed •Restricted topologies/control:

peer-to-peer, hub-and-spoke, hierarchical, …

•Show full language or subset

Peer 1

Peer 2

. . .

Peer n


Composition Infrastructure

•Peer-to-peer (distributed control)

•BPEL4WS, BPML, GSFL useful to define mediators•Composition of compositions hierarchy . . .

order1

ok

receipt1

order2

receipt2

bill 2

paym

ent 2

bill 1paym

ent 1

authorize

store bank

supplier1 supplier2

•Hub-and-spoke (centralized control)

ak’

ro

b2

p2

r2

o2

r1

o1

b1p1

ka’

bp

store

supplier1 supplier2

bank

mediator


BPEL4WS: Example white-box language

• Flowcharts “with parallelism”• “Pick” construct to enable waiting for input (or time out)• Synchronization within parallel threads• Comparison of supported constructs: see [van der Aalst ’03]

Initialize

pickend_datereached

flag := true

receive order

case

suppl1order

suppl2order

end case

beginparallel

send Order

receive Receipt1

send Receipt

Receive Bill1

SendBill

ReceivePayment

SendPayment1

endparallel

do until flag


OWL-S Process Model•Process class

– Atomic, composite (mediator), or simple (virtual)– Inputs, outputs, effects– Pre-conditions, post-conditions

•Constructs for composite processes– Sequence– Concurrency: Split; Split+Join; Unordered– Choice– If-Then-Else– Looping: Repeat-Until; Iterate (non-deterministic)

•Data Flow– No explicit variables, no internal data store, no

wait– Predicate “sameValues” to match input of

composite service and input of subordinate service

•Less refined than, e.g., BPEL4WS


Outline

•Events, messages, and sequential behavior are facts of life

•An automata-based framework•Analysis “tools”

– Petri nets– Tools using temporal logics– Bounded vs. unbounded queues

•Automatic composition•Conclusions


Verifying Properties of DAML-S Processes via Petri nets [Narayanan+McIlraith ’02]

•Specify a DAML-S semantics using a situation calculus– Includes Knows, Kwhether, Kref for condition testing– Captures “completion assumptions”: essentially prevents

world from changing without e-service knowing about it

•Operational semantics via Petri nets– Assume finite domains– Map to “1-safe” Petri nets, which corresponds to

bounded queue case

•Verify properties such as reachability, termination•Complexity depends on constructs and model

– Range from PTIME to EXPSPACE-hard


Verifying Temporal Properties of Mealy Compositions

•Label states with propositions– Level of indirection between states and “observables”

•Express temporal formulas, e.g.,– “shipment just made” only after “line-of-credit avail”

. . .. . .

. . .

store

warehouse1 warehouse2

. . .

bank!o 1

!a ?k

!o2

?b1

?a !k

?o1 !b1?o2

?r 2

!b2

?r 2

!b2

“line-of-credit

available”

“shipment just

made”

“shipment just

made”


Results on Temporal Verification•Long history, e.g., [Clarke et.al. ’00]

•E.g., verification for fsa’s and propositional LTL – Complexity: PSPACE in size of formula + fsa linear time in size of fsa

•Application to Mealy compositions– Results apply to open and closed case– Bounded queues

•Composition can be simulated as Mealy machine•Verification is decidable•Standard techniques to reduce cost

– Unbounded queues• In general, undecidable•Approximation techniques can be applied


Qualitative Analysis of Unbounded Queue Compositions•“Conversation Languages”

[Bultan et.al. WWW’03]

•Assume a “watcher” that observes all messages sent– In contrast to previous approach,

the “observables” here are simply the messages sent

•Language of peer implementation is set of words formed by successful executions of the implementation

Peer 1

Peer 2

. . .

Peer n

a k o1 b1o2 p1. . .

Watcher


Example Conversation Language

•Language: ak SH( (o1 r1 b1 p1)*, (o2 SH(r2,b2p2))* )– First ak, then a shuffle of orders against Supplier1 and

orders against Supplier2– Supplier1 is “cautious” and Supplier2 is “trusting”

•This language is regular•Same language for bounded or unbounded queues

. . .. . .

. . .

store

supplier1 supplier2

. . .

bank!o 1

!a ?k

!o2

?b1

?a !k

?o1 !b1?o2

?r 2

!b2


(a) Store’ (b) Supplier’ (c) Bank’

Unbounded Queues Unexpected Behaviors

•Abstract versions of previous e-services– But, no “handshakes” for messages

•Conversation language L:– L ao*b* = { aonbn | n 0 }, i.e., L is not regular

•Take aways: – “Bottom up” design of compositions may lead to

undesirable global behaviors– Service mediators can have important role in preventing

undesirable behaviors

!b

?o

?b

?a

!o

!a


How bad is it ?• In general, conversation language with Mealy

peers and unbounded queues is context-sensitive– Accepted by a quasi-realtime automaton with 3 queues

•All conversation languages are closed under two key properties– Join: if w is generated, then certain “shuffle products”

of w are also generated– Prepone: interchange order of input and output

messages of a peer p under certain conditions

•For hierarchical ec-schemas:

Each peer is a Mealy

implementation

Conversation language is join-prepone closure of a regular language


Outline

•Events, messaging, and sequential behavior are facts of life

•An automata-based framework•Analysis “tools”•Automatic composition

– Hierarchical composition– Results from DAML-S community– Results using Mealy machines– A bridge to DLs

•Conclusions


Hierarchical Composition•A pragmatic approach to automating e-

service composition

TravelServiceTemplat

es

Air Travel

TemplatesAirport

Transfer

HotelReservatio

n

Customized

TravelService


Hierarchical Composition (cont.)

•Approach:– Assume a library of e-service “templates” and

ground specs– Based on input criteria select a root template,

then fill in “gaps” with other templates and/or ground specs

– [Christophides et.al. ’01b] does this for “structured workflows”

•Take-away: Hierarchical structuring is important for e-service formalisms– Need to incorporate this into OWL-S, Mealy model


Automatic Composition for DAML-S[Narayanan+McIlraith ’02]: Search over all combinations•Recall simulation of DAML-S via 1-safe Petri nets

1.For set of atomic e-services, create Petri Net that represents all possible combinations of them

2.Specify desired goal as a state of this Petri Net3.Determine if this goal state is reachable

•In this framework reachability is PSPACE- complete in size of Petri net

– Petri net itself may be exponential in size of atomic e-services

– Heuristics can be used to avoid full construction[McIlraith+Son ’02] Generic compositions +

customization– develops mapping of DAML-S into ConGolog, and uses

to create compositions– Approach based on 2-level hierarchy…


Composition for Mealy Peers

• Traditional synthesis problem statement:– Given: ec-schema and LTL formula – Create: an fsa for each peer so that is satisfied

• Synthesis results for Mealy implementations with bounded queues– Closed compositions: folklore results imply that

synthesis is decidable• Propositional LTL description PSPACE -regular set represented as automaton

PTIME– Open compositions: Undecidable for LTL for

arbitrary ec-schemas [Pnueli+Rosner ’90]

• Decidable for hierarchical topology, but non-elementary even for linear case [Kupferman+Vardi ’01]


Reformulation of the Synthesis Problem to use extended “UDDI Repository” • UDDI Repository: globally accessible store for

web service descriptions and locations– Imagine that it supports Mealy descriptions

• Possible approach– Given: ec-schema, LTL formula , “UDDI

repository”– Find: peers in repository so that is satisfied

• Variation: allow creation of a mediator to choreograph the selected peers

• Database aspect of this problem– How to search across large space of Mealy

descriptions?– What is appropriate query language?


Synthesis for Unbounded, Closed Case[Bultan et. al. ’03]•Use conversation language to express global

behavior•Problem statement:

– Given: ec-schema and regular language L over messages

– Create: an fsa for each peer so that composition generates L’ = join-prepone closure of L

•Result: Mealy peers can be constructed whose composition gives global behavior L’– Do a “projection” on fsa accepting L

•Can again ask UDDI version of synthesis question


Recent work from Lenzerini’s group (DL ’03)•Based on a different model for peers

– Focus on sequences of actions, not messages– Includes a “user” who repeatedly makes choice

(from limited set) about next action she wants– All actions “visible” at top level

•Abstract behavior of the Service: Do until Client selects “End”

1. Give Client a choice of actions to be performed 2. Wait for Client choice3. Perform action chosen by Client

Client

Serviceon-linemusicstore

Actions that client can ask for:• initiate, end• search• listen• cart• buy

[Berardi et al ’03]


•Using standard automata techniques: NEXPTIME•Using reduction to ALU DL: EXPTIME

Solve composition by synthesizing mediator•Assuming peers and spec are regular, can

– Determine if a composition exists– If one does, then select peers and construct

mediatorDesired behavior(as FSA)

Extended UDDI

Mediator

(constructed)

Services(selected from “UDDI”)


Conclusions•Sequential behavior and messaging are a fact

of life– We need a notion of “behavioral signature”

•Automata-based perspective – Provides formal framework that incorporates

events and sequencing– Can draw on broad theory of analysis “tools”– Offers a framework for automated composition– Can represent (at least some) in DLs – link to OWL?

•Automata-based perspective should be exploited in semantic web services

•Results suggest key challenges in composition– Select peers: queries over sets of peers– Mediator crucial: find/build the mediator


We are just getting started …• Enhanced Mealy – can we incorporate

– Messages + actions– Pre-/post-conditions á la OWL-S– Hierarchical structure for messages (state charts?)– Temporal constraints– (your favorite) PSL constructs

• Composition of Mealy++ machines– Can we adapt the Roman approach ?– Augment traditional planning with approach for cyclic

behaviors

• Mealy++ vis-à-vis BPEL4WS, OWL-S process model, PSL, FIPA A-UML, …– Jianwen Su et. al. developing tool for translating between

Mealy and BPEL4WS

• Searching a large set of Mealy++ signatures– What is appropriate query language?

• Finding relevant results from various communities: verification, -calculus, planning, DL, DB, agent, …


Backup Slides


E-Services

• The Web: Flexible human-machine interaction• E-services: Flexible machine-machine

interaction• Working Definition: Network-resident software

services accessible via standardized protocols– Simple Object Access Protocol (SOAP): very flexible

remote procedure call

• Lots of interest in trade press, academic community, standards bodies, . . .

• Applications in e-commerce, telecom, science, GRID, government, education, . . .


E-Science

•E.g., find best location for waste treatment plant•Possibly 100s of nodes, and running for weeks•Data size difference:

– Control and calibrations (small) – Experimental data (large)

•Provenance: need to access derivation history

notifications and/orexperimental data

control and calibrations

Atmo-sphericSimu-lation

SeaCircu-lation

WasteTransport

Controller


Web Services Protocol Stack*

*Based on [van der Aalst ’03]

Transport layer: HTTP, SMTP, FTP, etc.

XML messaging layer: SOAP

Service Description Layer: WSDL, WSCL, WSCI

Web service composition:

WSFL, XLANG, BPEL4WS, BPML, W3C Choreography

Publishing anddiscovery:

UDDI


Pre-/post-conditions•DAML-S provides for

pre- and post-conditions•Examples

– if valid client sends Order, then Bill is created– if Payment is received, then Receipt is sent

•Performing inference (“everything else fixed”)– Assume a Bank service such that: if bill received and

sufficient funds, then payment is sent– Then we can infer that: “an order from a valid client

with a sufficient account balance will result in a receipt”

•Reasoning with pre- and post-conditions– Different models will lead to different complexity– [Narayanan+McIlraith ’02] axiomatization in situation

calculus for a Petri-net based model•Complexity from PTIME to EXPSPACE-hard

order

receipt

bill

payment

Supplier


Web Services Conversation Language (WSCL)• Alternative automata-based approach for

describing behavior of e-services– States are the WSDL operations (input and/or output)– Transitions are pairs of operations, with associated

condition• Condition refers to type of documents passed as input

or output

• Relationship of Mealy machine vs. WSCL machine remains open– Mealy machine formalism given above could be extended

to include conditions based on types of documents passed– Number of states in WSCL machine bounded by number of

WSDL operations– So Mealy machines (with conditions) appear more

expressive than WSCL machines


Technical Definition

A Mealy peer is an FSA M T, s, Fin, out, – T : a set of states– s : the initial state– F : a set of final states in : input message classes out : output message classes : transition relation that either

consume an input, (s, ?m, s), orproduce output, (s, !m, s), ormake an empty (internal ) move, (s, , s)


Abstract model fore-services with data• Variation of relational transducer [Abiteboul et al ’00]

• Extend Mealy machine to (Q,q0, F, I, H, O, )– Input schema I (can hold data associated with incoming

messges)– Internal/hidden schema H– Output schema O has tuples (q, q’, G, T)

• G is “guard” -- boolean query on I and H• T is “transform” - queries that create new H and output O

• Can use different data models (relational, XML, …)• General decision problems are undecidable

– E.g., if use relational calculus as data manipulation language

• Restricted cases are decidable, tractable– E.g., reachability of a state, if using conjunctive queries– E.g., “Spocus” transducers of [Abiteboul et al ’00] have PTIME

decidability results


Data Transducers as White-Box Peers•Add database to fsa

(XML, relational)•Store e-service with

–Customer_care– Inventory_replenishment –Store_database used as

shared data store

•Cf., XL [Florescu et.al.’03]–Process + XQuery

•Cf., Relational Transducer [Abiteboul et. al. ’00]

–Analysis undecidable; NEXPTIME for restrictions

!o 1

!o2

?r2?r 1

!o2

!o 1

?r 1?r2

!a ?k

ok

authorize

take

buy

receipt1

order1

receipt2

order2

?y !t

inventory_replenishment

customer_care

store_inventorypart qty

. . .

store_database


Parting Challenge: Process + Data

•Develop a theory for e-service composition that incorporates process + data

store bank

warehouse1

•E.g., “Relational Mealy Machines” (or XML, . . . )– Cf. Relational Transducers of [Abiteboul et. al. ’00]– Focus on restricted query/update languages

•Extend results previously obtained to include variables, context, large data

warehouse2


•“Computerised facilitation or automation of a business process, in whole or part” [WfMC]

•Centralized control– State of conversation

maintained by WF manager

E-service “Glue” Languages and Workflow Management

•Delegation of “almost everything” to the app.s– E.g., application data is not accessible to WF manager

•Workflow standardization has mixed success– Web services must interoperate standard likely– Should focus on interfaces, not internals


ActiveXML: A data-centric white-box language [Abiteboul et.al. ’03]

•A novel combination of data and web services

•Three ways to treat remote data:– Remote data is virtual, and

materialized when queried– Pass data pointer as part of

query response– Materialize remote data periodically

•Alternative to control-flow based languages:– “Outer process flow” dictated by XML query

language (and structure of data) – “Remote procedure calls” embedded into XML

structure


White-box Analysis via XML•Many different kinds of constraints arise in

BPEL4WS speca)Referential: service links refer to peers in compositionb)Cardinality: for synchronization links, 1 source and 1

targetc) Structural: internal synchronization links don’t cross

while scopesd)Value-based: requests matched by responsese)XPath: query on variable is subtype of a target variable

•For (a): XML Schema suffices•For (b) - (d): see [Deutsch+Tannen ’01, Benedikt et.al.

’02]

•For (e): Involves a combination of XPath and control flow analysis– If XL used, then “everything” is XQuery, and so XQuery

type-checker can assist with type correctness


AZTEC: A white-box language for sessions and asynchronous events [Christophides et. al. ’01a]•Control is hub-and-spoke•Maintains state of sessions

– Richer than web-service notion of conversation

•Queue for incoming asynchronous events

•Launches instance of event-handling flowchart for each external event

•Synchronization between flowcharts– Priority– Via shared data– Can interrupt other flowcharts (e.g., if prepay

account runs out of money)

ProfileData

PresenceServer

MediaServer(voice)

MediaServer(video)

Pre-Pay

SessionCoordinator


Agent UML• E.g., [Odell ’00]

• An exploration of different ways that UML can be used to capture agent interactions

• Message types based on KQML – request, assert, refuse, …– Subset of messages relevant to e-commerce, alerting services,

long-running activities, supply chain life-cycle, manufacturing life-cycle, collaborative technologies, pervasive computing, …

Winograd-Flores perspective (classical)


A-UML: focus on modeling• Diff. levels: Global, interaction, internal• Focus not on analysis or automated composition

Collaboration Diagram

Activity Diagram(with Swim Lanes and

Object Flow)

Sequence Chart Nesting (mix & match)

Packages (with nesting)[for global aspects]


A “Roman” approach to composition that bridges to DLs [Berardi et al ’03]

fulfill_

order1

authorize_line_of_credit

•Higher level of abstraction than messages•Enactments still have different life-cycles

store bank

supplier1 supplier2

pay_ supplier1

•Based on an action-based model•E-commerce example, with focus on actions

sell_goods


Focus on one Client, one Server

OnlineMusic Store

Front-end

•Drill down on customer buying CDs•Examine sub-actions inside sell_goods

Back-end

•Abstract behavior of the Service: Do until Client selects “End”

1. Give Client a choice of actions to be performed

2. Wait for Client choice3. Perform action chosen by Client

on-linemusicstore

Client

Service

initiatesearchlistencartbuyend


“Execution Tree” in Roman model•(External) execution tree: all possible

sequences of actions supported by service

on-linemusicstore

. . .

. . .

. . .

initiate

search

cartlisten

search cart buy search

Client

Service

Action supported by service

State at whichclient can stop

State at whichclient can not stop

•Children labeled by distinct actions•Tree is equivalent to a language over actions

– Typically, focus on regular languages


Composition in Roman Model (sketch)• Internal execution tree holds actions by

server and delegates of that server

on-linemusicstore

Client

Service

Servicedelegates

cust.care bank

•All actions are “visible” to client; none “internal”

. . .

. . .

. . .

initiate, care

search, care

cart, carelisten, juke

search,care

cart,care

buy,bank

search,care

jukebox


Composition in Roman Proposal [Berardi et.al.’03]

•If trees “regular”, can build composition (if exists) – Includes selecting delegates and constructing mediator

•Using standard automata techniques: NEXPTIME•Using reduction to ALU DL: EXPTIME

on-linemusicstore

cust-care bankjukebox

Externaltree forstore

. . .

. . .

. . .

initiate

search

cartlisten

search cart buy search

. . .

. . .

. . .

initiate, care

search, care

cart, carelisten, juke

search,care

cart,care

buy,bank

search,care

listen buy

Externaltrees forcust-care,jukebox,bank

. .

.

initiate

search

cart

search

Internaltree forstore


Citations• [Abiteboul et. al. ’00] S. Abiteboul, V. Vianu, B. Fordham, and Y. Yesha.

Relational Transducers for electronic commerce. JCSS, 61(2):236-269, 2000

• [Abiteboul et.al. ’03] S. Abitegoul, A. Bonifati, G. Cobena, I. Manolescu, and T. Milo. Dynamic XML documents with distribution and replication. SIGMOD, 2003

• [Benedikt et.al. ’02] M. Benedikt, G. Bruns, J. Gibson, R. Kuss, and A. Ng. Automated update management for XML integrity constraints. Proc. Workshop on Programming Languages for XML (PLAN-X), 2002

• [Berardi et al ’03] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. E-Service Composition by Description Logics Based Reasoning. Proc. 2003 Description Logics workshop (DL 2003).

• [Bultan et.al. WWW’03] T. Bultan, Z. Fu, R. Hull, and J. Su. Conversation Specification: A new approach to design and analysis of e-service composition. WWW, 2003

• [Christophides et. al. ’01a] V. Christophides, R. Hull, G. Karnounarakis, A. Kumar, G. Tong, and M. Xiong. Beyond discrete e-services: Composing session-oriented services in telecommunications. Proc. Workshop on Technologies for E-Services (TES), Springer LNCS 2193, Sept, 2001


Citations (cont)• [Christophides et. al. ’01b] V. Christophides, R. Hull, and A. Kumar.

Querying and splicing of XML workflows. CoopIS, 2001

• [Clarke et.al. ’00] E. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 2000.

• [Deutsch+Tannen ’01] A. Deutsch and V. Tannen. Containment for classes of XPath expressions under integrity constraints. Proc. Workshop on Knowledge Representation meets Databases (KRDB), 2001

• [Florescu et.al.’03] D. Florescu, A. Gruhagen, and D. Kossmann. XL: An XML programming language for web service specification and composition. WWW, 2002

• [Kupferman+Vardi ’01] O. Kupferman and M. Y. Vardi. Synthesizing distributed systems. Proc. IEEE Symp. Logic in Computer Science (LICS), 2001

• [McIlraith+Son ’02] S. A. McIlraith and T. C. Son. Adapting Golog for Composition of Semantic Web Services. KR 2002

• [Narayanan+McIlraith ’02] S. Narayanan and S. A. McIlraith. Simulation, verification and automated composition of web services. WWW 2002


Citations (cont)• [Odell ’00] J. Odell, Specifying Agent Interactions using UML.

Presentation to July, 2000, meeting of FIPA. http://www.jamesodell.com/FIPA_UML-Aug_2000.pdf

• [Pnueli+Rosner ’90] A. Pnueli and R. Rosner. Distributed reactive systems are hard to synthesize. FOCS, 1990

• [van der Aalst ’03] W. M. P. van der Aalst. Don’t go with the flow: Web services composition standards exposed. IEEE Intelligent Systems, Jan/Feb, 2003

• [WfMC] Workflow Management Coalition. http://www.wfmc.org/

October 18, 2003 Behavioral Signatures and E-Service Composition 1 E-Service Composition and Behavioral Signatures > Rick Hull Bell Labs Research October.

Documents

eservice composition

eservices new

individual eservices

eservices black box

eservices paradigm goal

services supplier slide

hotel service

new services