RE: Collaboration Services (was: Business Service Interface)

[Bob Haugen <linkage@interaccess.com>]

Bob Haugen:
>> 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.

Jean-Jacques Dubray:
>Who ever made such a statement? 

Which statement?  That business collaborations could
be managed exclusively by sequence numbers or linked
lists?  Lots of people recently, although sometimes
implicitly rather than explicitly.

>I must admit that I am troubled to think
>that someone could argue that we are going in the wrong direction 

If you mean me, which argument of mine suggests that?
I like the direction of the current BP/ebXML metamodel.
I think convergence with other ebXML work groups is
coming along nicely.

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

I couldn't tell if you were agreeing or disagreeing with me 
in that paragraph.  I agree (mostly) with the last two sentences,
and don't understand the others.

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

Did you think I meant "do not send XML documents"?  
No, I meant just sending XML documents is insufficient
to conduct actual business electronically.  The documents
must be exchanged inside larger protocols that obey
common business transaction and collaboration patterns.
It's not free-form.  (I think this is the same assertion
as your two statements I agreed with above.)

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

I do not understand what you are disagreeing with.
"Something like the dreaded business objects" could be any software
that knows how to manage the states of longer collaborations.
Your choice of architecture, I don't care if it's objects, procedural
code, or human data entry clerks.

As for internal IT architectures, the software to manage ebXML
business collaborations is not really internal.  It must be able to 
interact with its counterpart at the other end of the collaboration.
Therefore, it needs to obey the rules of the business collaboration.
I contend that most internal business app software can't do that,
thus a new kind of software must be developed.
I am conjecturing that "the dreaded business objects" (that several
people want leave out of ebXML) may be useful in developing this
software, but it is up to the software vendors to decide how they
want to obey the rules of the collaborations.  As long as it works,
I don't care.  

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

How is contract formation or order fulfillment academic?
Several B2B software vendors do both now.

Do you disagree with ebXML specifying a model for longer
collaborations at all, and would you restrict it to individual
message transmissions?  Where would you draw the line?

I'm not proposing expanding the current metamodel spec,
but I am saying that the software for conducting longer
collaborations is a different animal than that for sending
individual unrelated documents, and trying to discuss
how it might be different.

-Bob Haugen