RE: Collaboration Services (was: Business Service Interface)

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

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?

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