RE: Xtreme Ease-of-Implementation

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

I would like to add my little 2 cents to this thread, especially since my name has been mentioned here and there. I apologize in advance for not being able to properly follow up at methodological level.

I think that this thread, together with its parent message "Proposal for specifying business collaborations in business terms" [1], is very interesting because it is a concrete attempt to address the issue of "translating" the BP metamodel into something that could be implementable at runtime in a consistent way.

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. 

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?)

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

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

	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.

	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.

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.

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.

I will be very happy to continue this discussion further. Best regards

/Stefano


[1] : http://lists.ebxml.org/archives/ebxml-bp/200011/msg00052.html
[2] : http://lists.ebxml.org/archives/ebxml-tp/200010/msg00070.html
[3] : http://lists.ebxml.org/archives/ebxml-tp/200012/msg00010.html
[4] : http://www.ebxml.org/project_teams/trade_partner/tpaml106.zip


> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Thursday, November 30, 2000 9:41 PM
> To: 'ebXML-BP@llists.ebxml.org'
> Subject: Xtreme Ease-of-Implementation
> 
> 
> One of the stated goals of ebXML is to enable smaller and less
> technically sophisticated businesses to participate in electronic
> business.  One of the hindrances to such participation in traditional
> EDI is the long time and high cost of implementation, getting up
> and running in the first place.
> 
> Here is an idea for nearly-instant implementation.  It makes 
> use of my companion "Proposal for specifying business collaborations 
> in business terms".
> 
> Here are two scenarios:
> 1. A larger and technically more-sophisticated customer wants to 
> do business 
> with smaller and less-sophisticated suppliers.  
> 2. Two smaller or less-sophisticated (or smarter) companies want to do
> business together.
> 
> *First, the large-customer scenario:
> 
> The customer uses the ebXML Order-Fulfillment collaboration software 
> to package up the collaboration protocol for the suppliers.  The package 
> could take the form of a Web business service or a download or plug-in.  
> (Actually, most of what the customer needs to do will be preconfigured
> by the ebXML Common Process Catalog and my upcoming order-fulfillment 
> patterns, so their job is pretty easy too.)
> 
> All the supplier needs to conduct electronic business with the 
> customer is 
> Internet access and either a browser for Web services or whatever kind of 
> computer is required to run downloaded software. 
> 
> The collaboration protocol package contains the following 
> commercial transactions:
> . Order-acceptance, where the supplier receives orders from the 
> customer and the 
>   package contains preconfigured acceptance documents.
> . Fulfillment-confirmation, where the package presents 
> preconfigured shipping documents 
>   and the supplier can just fill in the blanks and push the Send button. 
>   (Think of it as an XML form in a self-addressed envelope.)
> . Payment protocol transactions depending on the trading partner 
> agreements, e.g.:
>   . Pay on Invoice, the package configures Invoice documents for 
> the supplier to 
>     send to the customer.
>   . Pay on receipt, the package receives and acknowledges 
> Receiving Advice 
>     documents from the customer.
>   . Pay on consumption or production, the package receives and 
> acknowledges 
>     the relevant documents from the customer.
>   . Prepayment, either directly or thru a 3rd party as in 
> International orders.
> 
> The package should also contain terms and conditions and actions 
> for all the
> possible things that could go wrong.
> 
> The basic idea here is that the more-sophisticated customer packages up
> both sides of the business process with its less-sophisticated suppliers
> and all the suppliers need to do is fill in the blanks in some forms and
> send them back.  The suppliers can extend the packages as much 
> as they want, e.g. connect them to their internal systems, but the basic 
> collaboration will still work correctly and new suppliers can get up
> and running very quickly.
> 
> *For small customers dealing with small suppliers, the whole 
> collaboration could be packaged up as a Common Business Process
> and used as-is.
> 
> Comments?  Suggestions? Etc?
> 
> Thanks,
> Bob Haugen
> 
>