RE: Collaboration Services (was: Business Service Interface)

[Bob Haugen <linkage@interaccess.com>]

It is clear that new kinds of software will be required for ebXML
(or any of the competing Internet business protocols). 
Business Service Interface described by Stefano Pogliani
and BPF described by Marty Sachs are examples of the 
new breed.

Most internal business application software was not designed
for, and is incapable of, conducting external conversations.
Moreover, the new kind of collaboration software must be able
to talk both to the internal business apps as well as the partner's 
collaboration software. Both Pogliani and Sachs appear to
agree on these points.

But the point of this message is that two levels of ebXML 
service software may be required, to manage two levels 
of the ebXML metamodel:
* Commercial Transaction Services (CTS), responsible
for managing the commercial transaction patterns, and 
* Business Collaboration Services (BCS), which would do
the same for the business collaboration level.
(I'm not hung up on the names here, just echoing
those in the current metamodel.)

There might even be a "zero" level that just transmitted
business document payloads using the ebXML Messaging
Services.

But the CTS would be needed to manage the cases 
where a formal response document is required to complete 
the commercial transaction, and the commercial transaction
fails if the response is negative or times out.  The 
commercial transaction protocols allow the response
document to arrive hours later - unlike a message-service
ACK. This behavior may be required for commercial contract
formation - and remember, a simple purchase order
is a kind of contract.

The BCS would handle cases where multiple commercial
transactions were related, and the state of the whole
collaboration needed to be managed.  

I think BCS covers most of the cases where sequencing
(beyond request-response) is important.  I also think that
in many (if not most) of those cases, the sequence is
not managable by sequence numbers or any other 
document-local rules, but requires interaction with 
something like actual business objects at one or 
both ends of the collaboration.

For example, negotiations are usually about forming
commitments (EconomicCommitment is a metamodel
class for this purpose).  The collaboration protocol of
negotiation needs to manage the state of the commitments,
including (for example) Offered, Accepted or Rejected.
The state transitions often require human judgment 
and/or semi-intelligent software analyzing the states 
of internal systems.  (E.g. automated available-to-promise
queries with fallback to human judgment on failure.)

Even ordering protocols may involve negotiation:
in an offer-acceptance scenario, unthinking acceptance
(as used in current ebXML POC scenarios) may expose
the seller to legal and other problems if fulfillment is
impossible (as happened to Toys-R-Us last Christmas).  
So something like an available-to-promise query is required, 
and the result might be rejection rather than acceptance.  
Or the result might be negotiation: the seller can deliver 
some of the order now, and some later.  
Is that acceptable to the buyer?  Etc.
In the meantime, the order is not committed.

In both cases, it should be clear than one ebXML document
is usually enmeshed in a larger network of economic events.
If the order is rejected, it has consequences for the buyer.
Non-fulfillment has consequences for each partner.
Order-fulfillment relationships are included in the
ebXML metamodel.  Sometimes they may be adequately
handled by internal business apps, but in many cases
I think the collaboration service software will need to
manage them.

To repeat, I think that in many (if not most) cases,
longer collaborations will require something like the dreaded
business objects at one or both ends.

In other words, sequencing of business collaborations 
may require collaboration software with some business
intelligence, it may not be manageable exclusively by 
sequence numbers or linked lists.

I think it would be possible to offer these alternatives 
as service levels, where the CTS would be the simpler 
and cheaper service, and the BCS would be more
complex and possibly more expensive.  
Moreover, CTS (or is it the zero level) would be 
the service level for Tokyo POC, while BCS could be 
the service level for Vancouver.  (Should be,
I think.)

I understand the desire of technicians to minimize
scope.  But I thought the goal of ebXML was 
to conduct *electronic business*, not just send
XML documents.  There are certainly scope questions
in how deep ebXML Phase 1 gets into the BCS level.  
The current metamodel provides a basic structure with 
hooks for software vendor elaboration, which seems 
about right to me.  Maybe the CTS level should be
required for ebXML-compliant software.

I would be very interested in responses to these ideas.
Respectfully,
Bob Haugen