[Fwd: Re: Co-ordination protocol and BPEL]

See below.

-------- Original Message --------
Subject: 	Re: Co-ordination protocol and BPEL
Date: 	Mon, 02 Jun 2003 22:46:06 -0700
From: 	Assaf Arkin <arkin@intalio.com>
Organization: 	Intalio
To: 	Monica J. Martin <monica.martin@sun.com>
References: 	<4.3.2.7.2.20030519094701.03532b90@franklin.cisco.com> 
<006801c31e59$8d36b040$6601a8c0@PC1> 
<4.3.2.7.2.20030521155912.035bc640@franklin.cisco.com> 
<4.3.2.7.2.20030522095947.033d1c78@franklin.cisco.com> 
<3ECD2A51.8000204@intalio.com> <3EDC2294.1040408@sun.com>



This is an interesting problem.

The problem from what I understood is that companies track both orders 
and shipment, but their reports only contain pending/fulfilled orders. 
So if some orders made and reported in Q1 get cancelled after the report 
is made, the Q2 report would contain Q2 orders but would not contain 
negative orders. For whatever reason the cancellations are never 
reported and so the data is skewed. The government on the other hand 
prefers to report orders because orders are a good indication of the 
future and helps identify trends in the economy.

I expect that there's no serious process problem. Whether it's a good 
process design or just a hack, if they can't properly cancel the orders 
they would end up with stocks of unused components. The cancellation may 
just remove those records hence nothing to report, or leave them 
untouched but never issue a shipment, or maybe change their status to 
cancel but never report negative orders.

As far as the choreography is concerned, there's an interesting 
requirement here. If the definition is strictly serial then the process 
can only check for cancellation shortly before it starts delivery (e.g. 
using a pick in BPEL). That may happen weeks after the order was 
effectively cancelled, a waste of resources. Instead you want the 
cancellation message to arrive and get processed at any point before 
sending an advance shipping notice. In WSCI/BPML you would use a nested 
process to get the cancellation message and then terminate everything 
with a fault. In BPEL you would use an event handler (same model, 
different name). So both languages are well suited to deal with that.

A different issue is what does a cancel message mean. Some people 
believe that it should be a protocol message that stops the process dead 
on its tracks. But then you can't record the fact that the order got 
cancelled, allocate products to some other order, send a nasty e-mail to 
the buyer, etc. It needs to be just another message that incidentally 
causes some activities to be terminated but with no magical semantics.


Where it becomes even more interesting is the touch point between 
execution and choreography. Our customers don't really care about the 
choreography itself, what they are looking for is a way to optimize 
their business processes. If one of their partners doesn't abide to 
their WSDL, or cancels pending orders, they're not going to sue them. In 
fact, the cancellation is written into the contract so there's no legal 
merit. But now they've wasted a lot of precious time and resources 
working on an order that never gets paid for.

For some people the choreography is purely prose and non-executable, and 
some kind of way to enforce order of messages sent and received. For our 
customers it's a way to look at their side of the choreography and make 
interesting predictions about it, for example the number of orders that 
get cancelled. That allows them to define their side of the choreography 
and do things better. They may decide to speed up delivery so the 
choreography moves faster past the point of cancellation and delay 
invoicing to after they know the order would be paid for. (Amazon for 
example invoices before starting delivery since their invoicing is 
relatively cheap, they deal with credit cards so there's less hassle 
involved)

That's generally why we like the choreography specification to have more 
touch points with execution rather than live in its own space. The sense 
we are getting is that being able to specify industry standard 
choreographies a la RosettaNet is very helpful in reducing costs by 
conducting business over the write. That's like having a robot that can 
paint a car in half the time it takes a human person to do it. But if 
you can actually correlate the choreography to the execution you can 
streamline your e-commerce by doing things differently (either in the 
choreography or the execution). That's akin to going from a workshop to 
an assembly line, and that's where you can get the most ROI.

Which probably explains some of the disagreement we have in the group. 
Reducing the number of choreographies is helpful and a goal in itself. 
But if everything is automated and the deployment cycle is a one-click 
process, then you get more power by using choreographies that are 
tailored for specific cases. People in the semiconductor industry would 
use a choreography that is different from the one used in the car 
industry where the cancellation rate is lower. And they can do that if 
we provide a solution that makes choreography definition, deployment and 
change management as easy as one-click shopping.

We're not quite there yet, but I expect that a lot more people will get 
it when they become exposed to the next generation BPM systems.


**Anyway, we can take this back to the mailing list. I think the point 
about being able to receive cancel message while doing other activities 
is an important one. The point about optimizing processes and 
choreographies together or using streamlined choreographies would 
probably be lost in the ensuing discussion ;-)**

arkin


Monica J. Martin wrote:

> Assaf,
> In the myriad of discussions that are unfolding, I know we spoke about 
> completing processes, and whether or not you apply the decision 
> points/context before, during or before completion.
>
> I have a real-world example in the manufacturing industry published in 
> the _Wall Street Journal_, 30 May 2003: The Commerce Department tracks 
> durable goods order for the manufacturing sector.  In addition, 
> previously, the department published data on semiconductor industry 
> durable-goods report.
>
> [This is the interesting part] It is common practice for buyers of 
> semiconductors to order from multiple companies at onece, then cancel 
> all but the first order to make deliery.  As a result, data on orders 
> is skewed.  Therefore, the government will not report on shipments not 
> orders.
>
> I think we can learn some lessons here about choreography and 
> real-world practice, and see what we can accommodate. If you want me 
> to forward to list, let me know.  Pretty simple.
>
> Monica

Received on Tuesday, 3 June 2003 02:09:02 UTC