Re: Multi-Party Binding Scenario

Burdett, David wrote:

> Jon
>
> What you think is unusual is actually very common and here's the use 
> case ...
>
> The content of an order document, say, will vary depending on such 
> things as: the industry in which the choreography is being used and 
> country in which the order is being placed. For example in the shoe 
> industry you might want sex, shoe size and color as elements in a line 
> item. On the other hand, in the travel industry you would not and 
> might want flight segment information instead. In Europe you need to 
> include VAT tax information (e.g. registered VAT number) but in the US 
> you would not.
>
I have two questions:

1. I understand that the VAT info will be missing in a US PO which has 
different regulations. In an XML Schema I would express that using an 
element with minOccurs="0". In abstract terms this clearly says: 
information may not be there. When you build the choreography you can 
easily determine what information will always be there (I assume billing 
address is available in both US and Europe) and what information is not 
there. So you can build the choreography accordingly.

Remember, this is not an attempt to form all US POs to include VAT 
information. It's an attempt to describe a choreography that can be 
affected by information that is available in all messages.

2.Sending a purchase order is different from ordering a ticket. So does 
the choreography. I don't see much value in trying to create templates 
that are so generic that could be used in any possible industry.

Let's say you can define a template once and use it in every possible 
B2B scenario. Question? Do you need a language for that if the number of 
scenarios you intend to define is very constrained to begin with?

Let's say you decide to define a templace once and use it in every 
possible B2B scenario. But the interaction for ordering some product is 
different from the interaction for purchasing an airline ticket. So will 
we force the airline industry and shoe selling industry to reach a least 
common denominator so we can have one definition for both?

In my opinion the complexity and variety already exists. I don't want to 
ask companies to start doing business in different ways because it makes 
it easier to express these as XML. I am looking for a solution that 
makes it easier to do business the way you already do business.

My motto: Not to avoid the complexity that already exists, but to 
support the complexity that already exists without adding any additional 
level of complexity.

So everytime we discuss this issue I ask myself the following question:

1. Does this level of complexity already exist and is justified by 
business requirements? If so, I don't mean to change it, it's the 
business needs that drives the requirement.

2. Does the model introduces more complexity? That's a problem we should 
work to eliminate.

3. Does the model capture that complexity? That's a solution in my opinion.

arkin

> If you then work out the number of *necessary* permutations, there 
> will eventually be 1000s of *different* order definitions each with 
> their own namespace. Note however that the UBL initiative [1] has got 
> this problem taped and is developing a practical solution to solving it.
>
> Now, if each Choreography definition is tied, through an XPATH to a 
> specific element in a document with a specific document definition 
> (i.e. namespace), you will end up defining 1000s of choreographies 
> which, from the perspective of message sequence, are identical. This 
> approach simply will not scale.
>
> This is why separating the abstract choreography from its binding to a 
> specific implmentation is *very* important.
>
> David
>
>
> [1] See 
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl, or for 
> an article on UBL that covers this problem see 
> http://www.eaijournal.com/Article.asp?ArticleID=633
>
>
> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com]
> Sent: Tuesday, March 25, 2003 12:19 PM
> To: Assaf Arkin
> Cc: Burdett David; 'Ricky Ho'; public-ws-chor@w3.org
> Subject: Re: Multi-Party Binding Scenario
>
>
>
> I can't really see splitting out all the Xpath expressions into a
> separate binding - if I define a flow that's intended for order
> processing, then I probably care what the format of an order is, and IMO
> it is ok for me to rely on that format even in the "external" view of
> the choreography.
>
> I guess one case where you'd want to do something like this would be a
> system that wanted to be able to say something like "I take purchase
> orders, and you can use ebXML format or SOAP format". So you could use
> the same flow with multiple data formats. I think this is a possible use
> case but IMO it is a bit unusual.
>
> OTOH, Assaf's point is interesting - if you do have expressions based on
> message contents, they shouldn't really operate on "raw" message data,
> but data that has been normalized -- otherwise you tie your choreography
> definition too closely a particular protocol. This might make sense, but
> there are limits to this approach. E.g. what about EDI? Or even SOAP
> with Attachments? If you want to able to handle truly arbitrary message
> content, then you can't rely on XML, or XPath.
>
> (I don't have an answer to this. I think assuming XML data is fine in a
> lot of cases. If it's not fine then you might have to define a "black
> box" for content-based routing, so that the external process knows you
> might take one or another path, but the logic isn't specified publicly.
> I think there was some discussion of this kind of model at the F2F).
>
> -Jon
>
>
> Assaf Arkin wrote:
> >
> >>
> >>
> >>
> >> If you include a specific XPATH expression in a choreography, then the
> >> choreography definition is no longer abstract and therefore cannot be
> >> reused
> >> which means it does not scale. I think the binding implied by the 
> XPATH
> >> expression should be recorded in a Choreography Binding document that
> >> binds
> >> an abstract Choreography Definition to the specific, services, 
> messages,
> >> documents, used by a specific implementation.
> >>
> >
> > I disagree. The choreography should talk about an abstract message.
> > Content without specific headers. No protocol binings. Not a "SOAP
> > message" but an abstract message without enveloping.
> >
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 25 March 2003 15:45:51 UTC