W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

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

From: Ed Peters <ed.peters@webmethods.com>
Date: Wed, 5 Feb 2003 17:51:19 -0500
Message-ID: <A60F0CBF368CF740A613EB1F262B860261AE14@maileast>
To: public-ws-chor@w3.org

> 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.

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 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.

Received on Wednesday, 5 February 2003 17:51:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC