RE: Multi-Party Binding Scenario

Assaf

I think you have two main questions:
1. You can express things like VAT info as an optional element using
minOccurs="0", and
2. You don't see much value in creating templates that can be used by any
industry.

I disagree on both counts ...

USING OPTIONAL ELEMENTS
If you want to *totally* rely on optional elements then you would need to
define an order document that contained all the information required no
matter what country, what industry, what business process, etc it was being
used in.

This approach is clearly impractical as the time required to do all the
analysis would be excessive. Even if you did, then it would only require
some legislator to require some additional element in an order document to
mean that your generic order definition was inadequate.

Therefore you *have* to allow new documents to be formed by extending
existing ones. This means you will get multiple different document
definitions with multiple different namespaces. Following this approach also
means that you don't have to get order definition perfect first time. The
article I mention below explains why this is, IMO, the only way that works.

CREATING TEMPLATES THAT CAN BE USED BY ANY INDUSTRY
Let's not forget the SMEs (small and medium enterprises). They have the
problem that they have few resources and a small budget for their IT. This
means that they cannot afford to implement the multiple different
choreographies that would result if everyone developed their own way of
doing business. The *only* way, IMO, to get SMEs involved in eCommerce, is
if there are some generally accpeted choreographies that can be used for
doing business as then the SMEs will be able to buy off-the-shelf software
that allows them to pariticpate.

This is also important to big business. EDI often only worked its way down
the top two tiers (levels) of the supply chain because the lower levels of
the supply chain could not afford to participate in the myriad different
protocols that the "big guys" wanted them to use. As a result, the speed of
the whole supply chain was (and is) slowed down pushing up costs due to
additional inventory that must be held to compensate.

There will however still be a need for industry specific profiles and I
anticipate that the vertical industry groups will want to create them (e.g.
RosettaNet, AIAG, etc). I think that one of our objectives should be to
provide these types of groups with the technology and specifications that
make it easy for them to do.

Thoughts?

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, March 25, 2003 12:45 PM
To: Burdett, David
Cc: 'jdart@tibco.com'; 'Ricky Ho'; public-ws-chor@w3.org
Subject: 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.