RE: Collaboration Services (was: Business Service Interface)

[Jean-Jacques Dubray <jjdubray@exceloncorp.com>]

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Thursday, October 26, 2000 10:04 AM
To: Bob Haugen; jj; 'Moberg, Dale'; 'Antoine Lonjon'
Cc: ebXML-BP@lists.ebxml.org; ebXML-tP@lists.ebxml.org
Subject: RE: Collaboration Services (was: Business Service Interface)

Well, sorry for having pulled off yesterday evening but I was in phone
calls.

I read carefully the thread so far, and here are my comments. Please, note
that these are my personal ideas.

I admit I am not as familiar as many of you in the "meta-*" stuffs. I fully
recognize their importance but this is not the domain of competence I have.

This said, when I read through the "Collaboration Modelling Metamodel"
document I found myself a little bit lost.
Actually, with the BusinessServiceInterface paper I am looking for
"reconciling" the Conceptual view presented by that (and other) document(s)
with an "execution oriented" view, which is the one which will finally
exercise (at runtime) all the other concepts. Commenting on Bob's first
mail:
        <Bob>
        "Part of my point in this discussion has been that the ebXML (BP)
metamodel
        already specifies a choreographical model for long conversations in
"almost"
        enough detail so that most of the common collaboration patterns can
be
        managed.  What needs to be added is refinements - little if any
additional scope
        (in my opinion). More work on these patterns will be forthcoming
from the
        Core Process group"
        </Bob>
I do not object that the metamodel does this. I think that we need to find
the way to make this "more concrete" and to provide a path to an "execution
model".
        <Bob>
        "Thus I was really interested to see you and a few others starting
        to address these issues, and wanted to engage you in discussing
        the whole range of implications and how they relate to the metamodel
        spec."
        </Bob>
Well, the implications as to the metamodel specs are not evident for me.
Looks like we need to find a contact-point between a top-down versus a
bottom-up approach.

What I am trying to understand is how to find more "concrete" ways to
express the concepts that were nicely expressed at "meta" level. At
meta-level we talk about roles, transactions, collaborations etc. I am
trying to verify how these concepts may translate into something that can be
used to model an execution view.

        I think that thinking to "execution" or, better, thinking to
        the requirements that any future implementation should fulfill, is
        in the scope of ebXML !

        I cannot imagine how runtime interoperability will be granted
without this.

        If I describe a Business Process and I say, in the description, that
        the Party will have
        - to send a Message to Party_A if the previous message tt received
          contained a value for CASH > 1000
        - or will have to send to Party_B if the previous message it
received
          contained a value for CASH <= 1000
        then, I am talking about concrete BPs. The choreographic semantic
        that I describe should be supported by vendors implementing the
software
        that interfaces the Party's legacy applications (if it is not a
        functionality provided by the legacy application itself, of course).

Without this execution level, I think it will be very very difficult to
ensure that a BP is supported across software provided by different vendors.
Bob says in one of his mails :
        <Bob>
        "Real software even for the common collaboration patterns will need
        to be developed by real software vendors, but the hooks for
developing
        them will exist in the ebXML (BP) metamodel and the core process
patterns."
        </Bob>
I think that we do not only provide the hooks but fill these hooks with a
semantic that grants every software means the same!  The software that you
describe here
        <Bob>
        Thus the need for specialized business collaboration
        software that can communicate with trading partners on one hand
        and the internal business systems on the other, in order to
        decide what comes next
        </Bob>
should, IMHO, provide some common "functionalities" (common across vendors)
that apply choreography and state management. The choreography that I talk
about is, probably, what you define as:
        <Bob>
        there is a public logic to the whole collaboration that must
        be shared to some extent
        </Bob>

Here it is not about giving or removing implementation freedom from vendors
or imposing architectural constraints.
As ebXML standardized the "technical infrastructure" and, for sure, the
"technical choreography" behind the TR&P, the payload, the header, the
envelope etc), so I think that the BP choreography needs to be standardized
at execution level". "String definitions" are not enough, in most
situations.

Now, the same consideration applies to the management of state. If I
understood Jean-Jacques's distinction between Collaboration and Business
Logic, I hope that we are heading towards the second. When JJ says
        <Jean-Jacques>
        "A collaboration does not depend on any state, it is an agreed upon
         sequence of messages. The purpose of the collaboration is to change
         the internal state of one or both parties but each party retain
         control on how they change their state. I REPEAT A COLLABORATION
DOES
         NOT DEPEND ON AN "INVENTORY LEVEL" OR "PRODUCTION CAPACITY". It is
         your response within the collaboration that depends on that."
        </Jean-Jacques>
i imagine we are saying the same thing from different points of view. Of
course the message from Party_A changes the state of Party_B; but it also
changes the state of the global system (the global Business Process). I am
not interested in "managing" the private state of each party (of course, I
wouldn't do it also for an EAI solution) but I am interested in managing the
global state (the state of the Business Process) as it evolves through the
sequence of messages and activities.
As well  for this other mention:
        <Jean-Jacques>
        "I think that it is important to separate the message exchange from
        the internal business logic that one particular role may want to
implement
        on its side of the collaboration to best serve its own interest."
        </Jean-Jacques>
I do not want to model the "way" in which a customers uses its Legacy world
in conjunction with ebXML. What happens once the message passes-through the
ebXML infrastructure is not responsibility of the ebXML specs. But a minimum
of instrastructure would grant the execution of a choreography (as well as
proper state management). I agree that, without choreography (in some way,
without a BP...) there would not be state nor infrastructure. But I think
that ebXML does not go in this direction.

In this sense I defend the possibility for ebXML to deal with state
management for the same interoperability reasons I said before. I think it
is important to ensure that the runtime software each vendor implements,
provides the same basic functionalities as to the management of the state of
the overall business process. Very simple things, for sure, such as logging,
tracing, restartability... But I imagine that it will be a frequent need
from customers to interrogate their partner's site for information about
shared data that are not yet there...

About the "sequencing" discussion.
What I think here is that we would need a choreographic model that would be
able to express the richness of conditional routing as well as iterative
constructs (probably something very close to what Cory was saying in his
contribution). Maybe we could go with post/pre-conditions... My point is
again that, when trying to reconcile the conceptual view with the execution
view, we would need to to provide a common semantic that is understood the
same way by all implementations. This semantic should be richer (IMHO) than
timeouts or simple prescription of a fixed sequence of messages.
        <Jean-Jacques>
        These two business rules are sufficient to express collaborations
(as a
        sequence of messages) and can be implemented with any technology or
        architecture. These rules can be agreed upon without any ambiguity.
A
        message sequence is not a state machine even though it might have
some
        aspects. This is important because it is much harder to agree on a
state
        machine than on an unambiguous message sequence. If you introduce
more
        business rules in the collaboration it will become a full state
machine.
        </Jean-Jacques>
Jean-Jacques, again we may agree on the fundamentals but speaking from
different points of view (conceptual vs. execution). From an execution point
of view, I do not think that what you propose is enough, but I may well be
wrong. How would you express conditional routing, for instance?

Conditional routing is based on the response message document type
(AcceptPO, RejectPO). We allow for one response out of n possible responses.
We did not want to express business rules against the content of the
documents which must be harder to agree on. This is a conscious design
decision that we can discuss if you feel it is not appropriately modeled.

I believe that the "execution model" would be a very big task ! We should
start with "something" and, probably, this "something" should be such that
could be used by the maximum number of businesses for the maximum number of
needs. If I understand the context, it seems that most of the people think
that "one-to-one message exchanges" would be the most frequently adopted
model. I do not object on this. And I would be happy to concentrate, in a
first phase, in defining the "execution model" for this sample. I would only
highlight that :
        - this model should be extensible, in order to accomodate more
complex
          needs
        - this model should be clear, constraining what is supported

Finally, I believe that, mostly, almost everything could be mapped as
BusinessProcesses.
BPs have state and require management and have many roles and are
long-living. Not every occurrance of a BP would require all these
characteristics, of course, and here we will talk about specific sub-cases
(one-to-one exchange is a sub-case). What we need to take care is that,
quite differently than most of the other things I saw so far, ebXML is
supporting a completed distributed execution model for a Business Process.
In this sense, it may appear that the BP is "equivalent" to message
exchanges, but I (personally) think that it is much more than that.

So, summarizing this quite long mail:
        - The Business Service Interface paper is about defining the minimal
          characteristics of an ebXML-compliant party AT RUNTIME
        - Some software is required to manage the runtime
        - one-to-one exchanges is a subcase for a more generic BP

Best regards

/Stefano