RE: Same model for both Public and Private process ??

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Ed Peters
> Sent: Wednesday, February 05, 2003 2:51 PM
> To: public-ws-chor@w3.org
> Subject: RE: Same model for both Public and Private process ??
>
>
>
> > In other words, if the buyer and supplier agree that an order
> > is > $500 as
> > can be calculated from the message (if the schema was known)
> > the buyer can
> > reject the message and the supplier will accept a reject
> > message. But if the
> > supplier has determined that the buyer does not have
> > sufficient credit to
> > purchase the product, the supplier proceed to accept the
> > order since the
> > buyer may have a different opinion on the matter ("what do you mean
> > rejected? you know I'm good for it! I might not have money
> > right now, but I
> > promise to pay you back!").
>
> I think Jean-Jaques' point actually makes more sense than this:
>
> On one hand, there may be pre-negociated conditions to any business
> transaction that you'd like to be able to model (such as your ceiling for
> purchase orders).  I believe this is the stuff that Jean-Jacques was
> describing with respect to ebBPSS.  This doesn't make sense in the
> perspective of a language like BPML, because BPML is focused on the
> description of process implementation, and doesn't include any kind of
> formal notion of collaborating trading partners.

Indeed. This discussion is actually in the scope of WSCI.


> On the other hand, any party in a business transaction could unilaterally
> reject a message for reasons it may or may not chose to make public.  As
> someone else already mentioned, forcing me to expose my credit rating
> criteria just so our mutual choreography feels more "complete" (for some
> value of that word) doesn't make a ton of sense.  I'd rather just say "I
> might reject you with the following reason", and leave my implementation
> logic opaque.  In the case of ebBPSS, I would agree to always return an
> "order response document", but sometimes the response might be "no".

I definitely agree. But I think there are two use cases here.

In one use case you would return a response, always the same message type
but with different values (yes/no). The decision is definitely opaque, since
the choreography doesn not ask you to describe how the value has been
determined. You arrive at a value, put it in a message, send that message
back. In other words: sufficient that you can put some value in the message
without describing how you arrived at that value.

In the other use case you would decide to either return message 'no' or
message 'yes', which I believe is the use case JJ is talking about. In this
case you would want to say two things:

1. I either send you message 'no' or message 'yes', but don't expect both
2. I inform you that I will decide whether to send 'no' or send 'yes' but
not inform you how I reach that decision

What you need is a construct to do 1, which we already have. The question
for 2 is, do you name the decision?

One can argue that there is no obvious need to name a decision. Another
could argue that by naming the decision it could be interpreted as actually
telling you what the decision is, which makes the choreography expose too
much implementation details.

The point I am making is that naming the decision does not necessarily
expose any implementation value. If I call my decision X, can you say how I
reach it?

On the other hand, naming the decision allows me to say things about it that
are specific to my implementation. For example, there could be 10,000
suppliers out there that reach a decision whether or not to approve a
purchase order. All participate in the same choreography and any
implementation works.

Some of these suppliers inform you that in their decision X they will take
credit information (and any other information they deem suitable) to reach a
decision. Some suppliers inform you that in their decision X they do not
take credit information into consideration. None of that information is
contained in the choregraphy. There is one choreography used by all 10,000
suppliers.

In other words, you can talk to any of these suppliers using the same
choreography. But you can favor those that do not look at credit
information.

When you apply for a credit all credit cards have the same sequence of
operations (receive application, review application, make decision, if
positive open account, send credit card). One choreography. But some credit
card companies would like you to know that their decision differs from the
other. If you have very little credit you probably would not send an
application to a credit company that informs you their decision is based on
very rigid rules, but instead send the application to the credit company
that advertises "no credit, no problem". The APR will be nasty and the
balance low, but at least you'll get a credit card!

So there's some value in both having an opaque decision there (which we all
agree about) and being able to reference it from outside the choreography
(which I'm not sure we all agree on that). Simply being able to name a
condition gives you both.


> I look at it as a question of where we want to "spend" the
> formalism of our
> definition.  Maybe it makes sense to pack error detection logic for all
> parties into the definition of a choreography (i.e. "after receiving
> PurchaseOrder, Seller will map out Buyer's DUNS number and invoke web
> service ValidateCredit, which will in turn contact CreditAgency
> ...").  But
> then we're talking about a language for specifying both (a) how Buyer and
> Seller communicate and (b) what Seller does with Buyers' communcation.  It
> seems to me that a little more parsimony is in order.

I definitely agree!

I would not propose that the choreography language go that far, and besides
it would not allow a range of implementation to exist since it will force
them all to do the exact same thing.

But I think there's some misunderstanding there. My proposal is not to
describe in the choreography how you arrive at a value, only to give it a
name.

If you then decide to reference that name and provide additional information
to some interested parties in a manner that does not change the choreography
but gives them more visibility into it, that could only be helpful. But in
no way would that change the choreography, or force you to have different
choreography because different implementations arrive at the named values in
different ways!

Is naming values something reasonable that we believe fits in the scope of a
choreography language?

arkin

>
> Regards
> Ed

Received on Wednesday, 5 February 2003 18:58:58 UTC