RE: Collaboration Services (was: Business Service Interface)

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Jean-Jacques,

	I was able to retrieve through Bob your original message which was posted to the wrong dist list (ebXML-BP@llists.ebxml.org, with double "l"). Could you please post it back?

Anyway, here is my comment on it. 

I did not fully understand the position which is expressed in your message. What Bob was saying (if I interpret correctly) is, in summary, that :
	- sequencing is not a pattern that could be generally used to
	  model the business intelligence
	- that some software (Bob mentions two levels) is required to 
	  manage long collaborations (and their status)

The part of your answer that I retained is that "what is important is to provide a neutral framework such that people may have the choice of architecture to implement behind the collaboration".

What was originating this thread (my little paper on the BSI) was indeed oriented to start a discussion on what you say is important. Some of the reasons why this is important are in Bob's mail. So I do not think that the comments from you and Bob diverge too much.

What may be diverging is the judgement of what is "a neutral framework". I agree with you that the ebXML specs should not design how this software should be developed. But I believe that some specifications of the functionalities provided by this piece of software would be very important to grant runtime interoperability across different implementations. The management of long conversations and the choreographic model of the conversations "may" fall (IMHO) inside these specifications. In some way, if (I say "if") we accept the concept that state-management is something important, I guess that the state should be managed the same way everywhere in terms of functionalities (then, if one uses a Relational DB and Java and somebody else uses some other mechanism, that is not important).

	The real point is the "if"...

Best regards

/Stefano

> -----Original Message-----
> From:	Jean-Jacques Dubray [SMTP:jjdubray@exceloncorp.com]
> Sent:	Tuesday, October 24, 2000 9:10 AM
> Subject:	RE: Collaboration Services (was: Business Service Interface)
> 
> > 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.
> 
> Who ever made such a statement? I must admit that I am troubled to think
> that someone could argue that we are going in the wrong direction when
> specifying a framework that predicts "why an organization should receive a
> particular message at any given time?".  What is the alternative? just
> specify all the messages an organization could receive and let the
> organization deal with it, with its own business logic? What is the
> probabilty for 2 parties to have the same business logic without a formal
> agreement? I'd say close to zero.
> 
> > But I thought the goal of ebXML was
> > to conduct *electronic business*, not just send
> > XML documents.
> 
> Unless I am missing something, I thought that the whole purpose of B2B was
> to wrap business communications into machine processable messages. The
> consequence of this is that any economic event and agreement have to be
> materialized as (MP) messages. I don't see an alternative here unless you
> consider email as B2B.
> 
> > 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.
> 
> I could not disagree more with this statement. What is important is to
> provide a neutral framework such that people may have the choice of
> architecture to implement behind the collaboration. BOCs are certainly one
> very good choice, but there are several other alternatives and it 
> is not the
> role of ebXML to define internal IT architectures. Our 
> responsibility is to
> provide a framework that is useable and yet as simple as possible to
> implement in real products. Otherwise, we would be jut be doing 
> an academic
> exercize.
> 
> Jean-Jacques Dubray,
> eXcelon Corp.
> 
> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Sunday, October 22, 2000 11:27 AM
> To: 'ebxml-tp@lists.ebxml.org'
> Cc: 'ebXML-BP@llists.ebxml.org'
> Subject: RE: Collaboration Services (was: Business Service Interface)
> 
> 
> 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
> 
>