RE: Xtreme Ease-of-Implementation

[Bob Haugen <linkage@interaccess.com>]

<Stefano Pogliani>
I would like to add my little 2 cents to this thread, especially since my name has been mentioned here and there. 
[...]
One of my points with the "Business Service Interface" proposal [2], was actually to specify the functionalities associated with the runtime software implementing the ebXML specifications (excluding the part dealt with by the TR&P specs). By properly specifying these functionalities, I thought, it will be easier to define some common ground where runtime interoperability could happen, thus enabling "cheap and modular" software to be installed at SMBs. 
</Stefano>

Stefano, thanks for the feedback.  Yes, your BSI proposal was why
I mentioned your name in my articles.  I also thought we were working
on complementary problems, both having to do with ebXML runtime
software.

<Stefano>
Now, some of the things that I agree with in the papers from Bob are:
a.	The separation between the "Business Transaction Software" and the
	"Business Collaboration Software".

	If I got it right, the Trx software is the software that actually 
	performs the business work, i.e. the legacy application which 
	stands behind the b2b exchange (is it the resource in the REA model?)
</Stefano>

No, I miscommunicated.  By "Business Transaction Software", I meant
the ebXML Business Transactions, that is, single requesting business
documents sent from an an initiating trading partner, coupled with
either an acknowledgment or a business reply document from the
responding partner which closes the transaction.

An ebXML Business Collaboration is a choreographed group of
Business Transactions.  You included legacy applications in
your BSI proposal; I did not include them in mine, thinking you
had already covered the necessary functionality (for which I was glad).

<Stefano>
	The Collaboration software is the software that drives the choreography
	and drives the liason between the MessageServiceHandler and the Legacy itself.
	In some way, this looks like the BSI I have been proposing (and the
	BPF from IBM [3]).
</Stefano>

I separated the software that handles the business transactions
and drives the liaison with the MessageServiceHandler (the
"Business Transaction software") from the software that handles
more the more complex choreography of Business Collaborations
(the "Collaboration software").  If we call them the BTM for Business
Transaction Manager and BCM for Business Collaboration Manager,
then in my view the layers and flows would go like this:

APP<>BCM<>BTM<>MSH<>TRP<>MSH<>BTM<>BCM<>APP

The main reason for the separation is that I think that business
collaborations have a logical boundary that is much larger than
some other people in ebXML (seem to) think.  For example,
in the resource exchange scenarios I have been focusing
on, a single collaboration typically consists of order, delivery
and payment and all of the document exchanges in between.
The collaboration is not complete until all the commitments
have been fulfilled and all the claims balanced.

All stages of the collaboration may not go through ebXML in all
situations, but sooner or later I think they will.  There are lots
of problems, both legal and financial, in the current disconnect
between order, fulfillment and payment in some consumer
e-commerce sites.  The same problems exist in B2B.

Legacy apps are totally clueless about how to conduct
B2B collaborations, especially using ebXML protocols.
Therefore ebXML collaboration software will be required,
that looks a lot like your BSI.

The reason for separating out the business transaction
level is that there needs to be a simpler "infrastructure"
release and that level can stand alone as well as being
used as a component by the business collaboration
software.

<Stefano>
b.	Within the Collaboration software, the separation between the
	"choreography description" and the "business process state".

	Again, I hope to have interpreted correctly Bob's idea.

	The "choreography description" (Bob's collaboration model) should be
	something "close" to the hand-off layer that, I guess, has been discussed
	in Burlington during the f2f of last week. I consider this as 
	the final bridge between the modelling activity of the BP group and
	the pragmatic needs of the CPA. In some way, the CPA would use the
	"collaboration model" (expressed as an XML vocabulary) from the BP
	as the "replacement" for the tpaML's "action menu" (see first IBM
	specs for TPA, [4]).
</Stefano>

The collaboration model for the early or infrastructure release of
the CPA will be much simpler than what either you or I are proposing.
Choreography expressions will be limited pretty much to success
or failure of business transactions.  And there will be no links to
legacy apps.

But I think what you and I want will be required very soon.  Again,
a reason for the separation of two "service levels" of ebXML software.

<Stefano>
	The "state of collaboration instances" should be close to the concept
	of a statefull component that manages the choreography as a long running
	conversation among partners.
</Stefano>

You got that one exactly right.

<Stefano>
	If I got the concept, both of these concepts are highlighted in my paper [2].
	I fully agree that they should be shown as XML documents.
</Stefano>

Yes, we agree.

<Stefano>
Now, it is very interesting and encouraging (from my very software-oriented point-of-view) to see how Bob arrives to some of the same conclusions I arrived from an implementation point of view. I like the idea of having some patterns that represent a vast majority of business situations and that could become a sort of "template" for customizing the runtime. The main advantage of this is, surely, the possibility to "quickly" map business level concepts (economic domain objects) onto implementation constructs (classes, documents and attributes). 
This could be a good starting point. But I would like to propose a slighlty different point of view:
	If, instead of having to "customize" a framework composed by already
	choreographed building blocks, we could have something that "magically"
	compiles the "collaboration model" XML document into some runtime, 
	we could still be able to use the templates that Bob proposes but we 
	would not need to mirror them in any implementation framework. The
	"generation" of runtime sofwtare would completely hide the need of
	such objects in the developer's domain. 
	Though, the conceptual mirroring of a vast majority of business situations
	to the order-fulfillment pattern (or the GL pattern or anything else) 
	would be of jewel value for the people who will need to "design" the
	BP. We could think to a sort of "focused" CASE tools that would simply
	allow a business analyst to "fill the blanks" (mapping documents to 
	actions and attributes to parameters...) for creating the XML document
	representing the "collaboration model" (after all, these tools do not need
	to be very sophisticated since the semantic is already fully documented
	by the pattern and the result should be something "constrained" by the
	"collaboration model" XML vocabulary.)
	Once the XML document is created, some other tool will generate the
	runtime for it.
In this respect, I would see a perfect marriage between modelling and implementation.
</Stefano>

Generating the software is attractive and may be a good idea in some contexts.
My concern here is that I want to be able to model the business scenarios
as re-usable patterns or templates regardless of what business documents
the participants use.  For example, I want all the concepts, relationships
and logic of order-fulfillment-payment patterns to be packaged as a
business collaboration model, where all the business partners would
need to do is plug in which actual documents they want to use, and how
they want to handle specified exception conditions.  Of course, if they
wanted to get fancy, they could also change the pattern.  But both
the patterns and the specific collaboration model would be XML.
I am not sure if code generation is necessary for the software that
executes these patterns.  It seemed to me that off-the-shelf components
would do as well, but they would need to have the vocabulary (not
the patterns) of ordinary business relationships built-in in a generic
cross-industry way that Bill McCarthy has specified.

<Stefano>
And, still, we are talking about things that:
	-	are not monolithic.
		We can have modular piece of software, each devoted to a specific
		need. The idea here is that the generated piece of software will
		function as an "adapter" for the legacy application implementing the
		business functionality required by the b2b exchange. 
		I do not see any need to "modify" the legacy, but only to "wrap" it
		(anyway the wrapping is logically required for plugging the Messaging
		layer...)
	-	are cheap.
		Granting interoperability at runtime grants that every vendor can
		jump onto the boat and propose a minimum set of common functionalities
		that are granted "regardless"...
	-	are well documented.
		I have been focussing in many discussions on different lists on the 
		need to define the behaviour of the "collaboration model" agent (the
		BSI in [2]) as well as to define a clear XML vocabulary for expressing
		choreography information.
</Stefano>

I am happy to leave the wrapping of the legacy system to you, although
I fully agree that it needs to be done.  I think it is properly part of the
"collaboration software" layer.  Where I think we may disagree is the
separation between a collaboration software layer and what I have
called the "business transaction" layer, that directly drives the
messaging layer.  I think there needs to be at least three logical software 
layers between the MessageServiceHandler and the non-collaborative
legacy app:  the adapter, the collaboration manager, and the transaction
manager.

<Stefano>
I will be very happy to continue this discussion further. Best regards
</Stefano>

Me too,
Bob Haugen