RE: Multi-Party Binding Scenario

Assaf

I think we are both agreeind and disagreeing ;)

I agree with you about the idea of having optional information in a business
document. The only reason I was pointing out the futility of relying on this
is that tying ANY *widely usable* choreography *definition* to a specific
document format will result in multiple choreography definitions that are
*identical* apart from the fact that they use different documents. I don't
think that defining the same thing multiple times is ever a good idea.

The only way around this, as far as I know, is to make choreographies
reference an *abstract* message definitions which, in an implementation can
be bound to a specific message format or formats. For example you could have
the abstract idea of an order "message family" that can represent any order,
in any format. You could then express the choreography using message
families instead of specific message formats.

I also recognize that you need, as part of a choreography, to interrogate
information in a message in order to control the flow of the choreography.
However, if the message definition in the choreography is abstract, this is
hard to do.

One way around this is make decision in a choreography dependent on the
state of the role, where the state is affected by: the sending of a message,
the receiving of a message or the processing of a message. For example you
could have a state value of "USInvoice" in the choreography. This could then
be mapped to an XPath expression, for example, when the abstract message was
bound to the specific message format.

Thoughts?

Additional comments inline ...

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, March 25, 2003 10:07 PM
To: Burdett, David
Cc: 'jdart@tibco.com'; 'Ricky Ho'; public-ws-chor@w3.org
Subject: Re: Multi-Party Binding Scenario


Burdett, David wrote:

> 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.
>
Not necessary. I just wanted to indicate that it's possible for a 
document to contain information that will not necessarily be available 
in all messages and to express that fact. There are many possible ways 
to do that in XML, see below.

> 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.
>
Absolutely right. I agree with you on the principles, I just don't see 
where the problem is, see below.

> 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.
>
This is where I disagree. I can define a template document that contains 
all the information I know will always be there, and define a 
choreography that references that information. That's important if I 
want to express that an advance shipping notice will go to the shipping 
address, but an invoice will go to the billing address. And obviously, I 
know both bits of information will be contained in every PO.
<DB>I think that if you do it this way, you are restricing the use of the
template document to a specific choreography. If you use the idea of mapping
states to conditions expressed as XPaths (for XML documents) I don't think
you need to do this. </DB>

But you raise a good point: do I need to know all information that will 
ever possibly be contained in a message in order to make that work? If 
that's the case, this approach is flawed. Or can I define some of that 
information but allow other information to be included for a given 
business context. For example, in Europe the PO will contain VAT 
information, in the US the billing address would contain the state name, 
and if the PO is based on a quote it will also have to reference that 
quote. All that information is either optional, or additional.

XML Schema gives me two ways to deal with optional information (#1 and 
#2 below) and three ways to deal with additional information (#3-#5 
below) while still being able to express that part of the information 
that is mandatory without having to switch namespaces:

1. Elements with minOccurs=0 (may or may not occur)
2. <choice> (one or the other)
3. <any> and <anyAttibute> (put anything you like)
4. derivation by extension (add anything you like)
4. substitution elements (similar but for elements instead of types)

So I can define a purchase order that will always have a billing 
address, and I can include the VAT information as an element where <any> 
appears and add the state code by having a USAddress that 
extends/substitutes Address.
<DB>Using Any to add in arbitrary attributes means that you are not
exploiting the validity checking features of XML Schema. I think that really
what you want is an automatically generated schema that: i) takes a base
level schema, then ii) extends the schema according to rules that depend on
the context in which the schema is being used. The result is a new schema
which can be used to autmatically check the validity of the document. This
is where UBL is headed. </DB>

I want to say that I've only looked at a few UBL examples out of the 
many, but I can't see anything that cannot be expressed in that 
extensible manner using XML Schema.

> 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.
>
I agree. But the question is: do you define one choreography for all PO 
in the automative industry, or do you define a template that all 
possible B2B scenarios would use?

In the first case you benefit from uniformity, that's very important. 
But you build a choreography that is rooted in some known information 
that is communicated (see above how to express it regardless of country, 
or even to extend it whether you're dealing with passenger cars, trucks 
or motorcycles). In the second case you have templates that ignore the 
information, are even more reusable, but are constrained to the least 
common denominator between the auto industry, airline industry, retail 
industry, etc.
<DB>I think you need both: i) a choreography that can be used by anybody -
this is what most SMEs would use; and ii) choreographies that are specific
to an industry. In this case, the "big guys" have a choice when working with
a SME, do the automatic way using the standard choreographies, or wait for
the SME to implement the industry protocol. Ultimately it's a business
decision.</DB>

> 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.
>
Let's look at EDI for example. EDI defines a number of business 
transactions with flows = choreography. And for each business 
transaction you know what the messages look like. So you can express 
that transaction in terms of the messages exchanged, you can say that 
advance shipping notice goes to the shipping address but invoce goes to 
the billing address. The same for RosettaNet (I'm actually more faimilar 
with PIPs than EDI).

I'm trying hard to think of a case where in B2B you would describe a 
transaction on the one hand, but not be able to capture the basic 
information that is contained in its messages. I'm not saying you know 
everything that is part of the message, but in all the cases I've seen 
you know enough to write some basic rules based on message contents.
<DB>See earlier comments on the idea of "state".</DB>
What would be a counter example?

arkin

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


-- 
"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 Wednesday, 26 March 2003 14:48:15 UTC