FW: BPSS Strategic issue: separate service levels

[Bob Haugen <linkage@interaccess.com>]

This is the discussion of one of the three strategic issues
with the ebXML Business Process Specification Schema V0.99
that I believe are highest priority for ebXML BP right now.

3. Separate service levels for transactions and collaborations.

    Support for ebXML business transactions will be a great
    leap forward for the state of electronic business practice,
    and will handle many business scenarios.  Support for
    collaborations, especially the BPSS multi-party design,
    splits, joins, etc. will be not only more difficult for software
    developers but also for business analysts.  
    I recommend designating separate service or compliance
    levels for each degree of difficulty, so that simple transaction
    processors can be developed quickly and inexpensively. It's not
    that far beyond what people do now with RosettaNet PIPs.

Here are some line numbers from the BPPS document that
relate to this issue:

Line 828: 6.4.3.1 Key Semantics of a Multiparty Collaboration 
Line 876: 6.4.4.1 Key Semantics of a Choreography 
Line 1825: 7.4.7 Fork 
Line 1836: 7.4.8 Join 

Rationale:
The state of practice of B2B ecommerce is transmitting
and receiving single documents with technical acks.
The ebXML Business Transaction protocol will be a major
advance for most people.  
Multi-transaction collaborations and choreography will be
important to the leading-edge users (and will be very
important to them), but for many (probably most) people
they will be lucky to get transactions working in the next
year or so.
Therefore, collaboration and choreography support should
not be mandatory for ebXML BP compliance, but business
transaction support should be.  The BPSS should make
a clear distinction between these two service levels and
differentiate the elements are required for basic transaction
support.

Respectfully,
Bob Haugen