In puedo-CDL it would be something akin to:
RoleTypes: Customer, Seller
InformationTypes: OrderType
CancelType
OrderDetailsType
PaymentType
ChannelTypess: Customer2SellerType
Variables:
Customer2SellerType channel2Seller
OrderType order
OrderDetailsType orderDetails
PaymentType payment
CancelType cancelOrder
sequence
{
interaction (request) on channel2Seller to placeOrder
send order
receive order
choice
{
if (goodOrder)
{
sequence
{
interaction (response) on channel2Seller to
placeOrder
send order
receive order
}
parallel
{
sequence
{
interaction (request) on channel2Seller
to confirmOrder
send orderDetails
receive orderDetails
choice
{
if (orderDetailsOk)
{
sequence
{
interaction
(response) on channel2Seller to confirmOrder
send
orderDetails
receive
orderDetails
interaction
(request) on channel2Seller to pay
send
payment
receive
payment
choice
{
if
(payOk)
{
sequence
{
interaction (response) on channel2Seller to pay
send payment
receive payment
}
}
if
(payNotOk)
{
sequence
{
interaction (fault) on channel2Seller to pay
send payment
receive payment
cause exception at send and receive
}
}
}
}
}
if (orderDetailsNotOk)
{
sequence
{
interaction
(fault) on channel2Seller to confirmOrder
send
orderDetails
receive
orderDetails
cause
exception at send and receive
}
}
}
}
sequence
{
interaction (request) on channel2Seller
to cancelOrder
send cancel
receive cancel
cause exception at send
and receive }
}
}
if (orderBad)
{
interaction (fault) on channel2Seller to placeOrder
send order
receive order
cause exception at send and receive
}
}
}
I have catered for faults too. But essentially after the initial
request to place and order there are two parallel
sequences. One for the normal behavior of confirming and paying and one
for the cancellation. The cause
exception causes at exception at both ends and they can handle the
exception as a business exception
in what ever way they choose. In CDL you can have exception handlers to
show what happens from a
message exchange perspective between the two.
You can project out what sends and receives occur at the Customer and
the Seller and create WSDL or indeed
BPEL processes to implement the correct behavior. What CDL does is take
a global view across the two participants
or roles and deals with them interaction (or exchanging messages). I
have used the term "to <someOpName>" on an
interaction to show how the different interactions are related by
operation name. This helps to understand and police
causality.
Hope this helps.
Cheers
Steve T
On 20 Jul 2006, at 12:42, Steve Jones wrote:
> First off I wouldn't try and model it as a single process, but as a
> set of processes. I probably wouldn't try to build the overall
> process in BPEL but have that as the behaviour of the "Buy" service to
> the customer. This would mean storing the state after invocation and
> then validating state as the new process kicks off. In this model you
> have to conceptually model "wait" but not do it programmatically.
>
> If you did want to have an over-arching process I'd put that outside
> the service as an orchestrator of the various capabilities in the
> service, then expose that wrapper out to the world (which because of
> the various callbacks will have several end-points), but I'm not sure
> what that would gain you, in this model you'd have to model wait with
> several potential new entrances.
>
> The over-arching element here is that business processes are fairly
> loose elements and modelling them in BPEL might not always be the best
> way.
>
> Steve
>
> On 19/07/06, Ashley at Metamaxim <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dear All
> >
> > I think that the "wait" issue raised by Todd in his post on
> definitions is an interesting one.
> >
> > Here is a little example which seems quite nasty when you try to
> model the "waits":
> >
> > The XYZ company offers a service for its customers to buy products.
> To use this service, a customer has to invoke three operations in
> turn:
> >
> > - PlaceOrder
> > - ConfirmOrder
> > - Pay
> >
> > An arbitrary time can elapse (e.g., several days) between the
> invocation of each.
> >
> > At any time during this, the customer can invoke:
> >
> > - Cancel
> >
> > to cancel the order.
> >
> > Within XYZ, handling PlaceOrder is a manual process that requires
> the following to be done:
> >
> > - ConfirmCustomerCredit
> > - ConfirmStockAvailability
> > - CalculateOrderPricing
> >
> > These three are handled as manual internal processes by XYZ, in
> parallel. Because they are complex processes requiring specialist
> skills, each can also sometimes take several days to complete. While
> they are in progress (i.e., until all three have been completed), the
> customer is blocked from invoking the ConfirmOrder operation, but can
> Cancel.
> >
> > What does the process for this service look like (say in BPEL)?
> When I try it (using PICK for all the events, including the completion
> of the internal processes), it gets complicated -- more complicated
> than I think it should be.
> >
> > Anyone up for trying it?
> >
> > Rgds
> > Ashley
> >
> >
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
