�ݺ�ߣ

DEPENDENCIES BETWEEN
COORDINATION AND
COMPOSITION
Presented By:- Suveeksha Jain
College:- SJEC
Class:- Mtech 2 sem

CONTENTS
 Coordination protocols and composition schemas.
 Conversation Controllers and Composition
Engines

COORDINATION PROTOCOLS AND COMPOSITION
SCHEMAS
 Coordination protocol imposes constraints on
composition schema of web service implementing
logic.
 If a web service plays a role in coordination
protocol and implementation is done through
composition technologies, then composition
schema must include activities of send and receive
messages.

requestQuote
(to supplier)
checkShipAvailable
(to warehouse)
confirmOrder
(to customer)
orderGoods
(to supplier)
cancelOrder
(to customer)
makePayment
(to supplier)
orderShipment
(to warehouse)
getShipmentDetails
(to customer)
confirmShipment
(to warehouse)
confirmShipment
(to supplier)
supplier warehousecustomer
warehouse
confirms
warehouse
cancels
Fig 1: The procurement coordination protocol

 1.Create role specific view of a protocol, which
include all the message exchanges that involve a
certain role. All the supplier should care about to
build composition schemas that generate correct
procurement conversations.
 2.Goin from the role specific view of the protocol
to the definition of a process that exchanges
messages as prescribed by the role-specific view.
 3.Build a skeleton of a process that include all
the activities that send and receive messages as
prescribed by the protocol.

HOW PROCESS SKELETONS CAN BE BUILT
FROM ROLE SPECIFIC VIEW
1. Request/reply operations invoked by a role R on
the supplier are mapped into receive and reply
activity.
2. One way operation invoked by another role on
the supplier are modeled as receive activities.
3. One way operations invoked by the supplier are
modeled as send activities.
4. Request/reply operations initiated by the
supplier are modeled as invoke activities.
5. The other constructs are mapped as is into the
process skeleton.

requestQuote
(to supplier)
checkShipAvailable
(to warehouse)
confirmOrder
(to customer)
orderGoods
(to supplier)
cancelOrder
(to customer)
makePayment
(to supplier)
orderShipment
(to warehouse)
supplier warehousecustomer
warehouse
confirms
warehouse
cancels
confirmShipment
(to supplier)
Fig:2 Supplier specific view of the procurement coordination protocol

invoke
checkShipAvailable
receive requestQuote
reply requestQuote
receive orderGoods
send confirmOrder
receive makePayment
send orderShipment
receive confirmShipment
send cancelOrder
Fig:3 An abstract process defining the behaviour of the supplier role in the
procurement coordination protocol.

 Advantage of abstract process is that they make
it easy to understand how composition is
constrained by the protocol and to define a
composition schema that implements a protocol.
 Developers can take abstract process and extend
it by adding details about internal logic.

invoke
checkShipAvailable
send confirmOrder
send cancelOrder
shippingAvail=trueshippingAvail=false
invoke lookupQuote
reply requestQuote
receive orderGoods
receive makePayment
send orderShipment
invoke collectPayment
supplier
receive confirmShipment
Fig:4 Implementation of the supplier role in the procurement protocol

 A web services can support only one protocol or several
protocols. In this example we take up one protocol for
interacting with warehouse.
 Till here discussed the path that goes from protocol
specification to role specific views, abstract process and
implementation of abstract process .It is common that
external behavior is designed before the internal one.
However inverse route can also be taken.
 BPEL is a language designed with service composition.
It can specify both the external and internal
implementations.
 ebXML also addresses both protocols and compositions.

CONVERSATION CONTROLLERS AND
COMPOSITION ENGINES
 Conversation controllers verifies protocol compliance
and routes messages to the composition engines.
 Composition engine is the internal object that
implements the conversation.
 If the conversation controller and the SOAP router
leave header information in the message when
routing it to the engine , then coordination context
can be used to determine the target instance.
 If conversation controllers strips header information
from the SOAP message and just delivers the
payload, then the engine has to find some other way
to correlate messages with instances.
 The solution is to have the composition schema
explicitly include correlation information.
 For ex orderID parameter where each conversation
carries unique order number.

another Web
service
conversation controller
composition engine
service provider
object
(Web service implementation)
object
(Web service implementation)
Instance of a
composition schema
instance of a
composition schema
checkLocalStock
checkShipAvailable
confirmOrder
inStock=false
cancelOrder
inStock=true
shippingAvail=true
shippingAvail=false
lookupQuote
reply requestQuote
receive orderGoods
messages related to
protocols implemented by
basic Web services (or
anyway services implemented
by means of conventional
programming languages)
messages related to
protocols implemented
through service
composition technologies
the engine has to match
messages with instances,
just like the conversation
controller has to match
messages with objects
Fig:5 The composition engine is faced with a conversation routing problem similar to the one
addressed by the conversation controller

�ݺ�ߣ

web services

Recommended

More Related Content

Similar to web services (20)

Recently uploaded (20)

web services