RE: [ebxml-dev] BPMI?

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

I have lost some of the latest developments on BPML, so what I
am going to say may be "technically" not completely up-to-date.
Nevertheless I hope that the "meaning" will not suffer.

1.	From a BSI perspective I may have explained myself in a
	wrong way; in my mind the BSI should enforce whichever
	semantic is described by a CPA; so, if the semantic is
	the one of collaborations built using transactions, this
	is what should be done.

2.	The BSI should, whenever possible, be directly derivable
	from the CPA.
	As far as I understand the problem, the only information
	required to make the BSI fully automated is the mapping
	of the "messages" to some internal action.
	Not always it is "possible" to map a message to the
	execution of some legacy in an automated fashion. But the
	BSI software could, in those case, function possibly as
	a mailbox.

3.	It is important, in order to have a BSI, to describe
	a protocol for accountability of the shared process.
	What I mean is that having the BSI on both sides, it
	will be important that each partner may be able to
	ask to the other about the status of what it is doing.

4.	I am not sure I understand the initial distinction JJ
	made about BPML going in the w/s direction and loosing
	the B2B bus.
	I may be certainly wrong, but I think that the BSI will
	be, in itself, a Web Service.
		- is accessable via SOAP (w/A)
		- is discoverable via UDDI (and RegRep)
		- is describable via the CPP/CPA...
		  and I think that it could "reflect" some WSDL

	What changes between the ebXML as we see today and the
	w/s as we see today, is the "process". In ebXML the BSI
	executes a shared process; this requirement is not yet
	formalized (maybe it will never be or it will...) for
	w/s.

	The work that JJ and Antoine did in BPML was to show
	how to "link" the BPSS with the BPML.

	JJ, could you pls better explain which is the hole
	you see?

5.	I like the separation JJ makes in BPSS between the
	protocol-related things and the process-related
	things.
	But, in my understanding, these two views are not
	separated and live well together. I think that the
	fact that BPSS specifies protocol-related things is
	not to be removed but, actualy, could help in
	better configuring the underlying system.

	What am I missing ?

Best regards

/stefano



» -----Original Message-----
» From: bhaugen [mailto:linkage@interaccess.com]
» Sent: 22 February 2002 20:54
» To: Jean-Jacques Dubray; ebxml-dev@lists.ebxml.org
» Subject: Re: [ebxml-dev] BPMI?
»
»
» From: Jean-Jacques Dubray
»
» >BPSS contains two things: a) a protocol which sits on top of the MS
» >protocol and b) a collaboration specification based on the concept of
» >choreographed business transactions. The protocol is inside the
» business
» >transaction.
»
» If your point in the preceding paragraph was to differentiate
» between business transaction and business collaboration layers,
» I agree.  But then I get confused...
»
» >A BPMS should not deal with protocol level semantics, in other words it
» >is not here to enforce/implement the protocol. This is actually the
» role
» >of the BSI layer as proposed in the BPSS spec and well documented by
» >Stephano Pogliani.
»
» 1. What does "BPMS" mean?  Business Process Management System?
» Does it live on top of the transaction layer?
» 2. Last time I talked to Stephano, he was not making a distinction
» between transaction and collaboration layers - and his BSI document
» also contained mappings to internal business apps.
» 3. The latest BPSS is ambiguous:
» "It is anticipated that over time BSI software will evolve to the point
» of monitoring and managing the state of a collaboration, similar to the
» way a BSI today is expected to manage the state of a transaction. For
» the immediate future, such capabilities are not expected and not
» required."
»
» >However, if you get rid of the protocol you still have a flow of
» >information (request/response and exceptions generated by the BSI based
» >on the analysis of the protocol).
»
» Do I understand correctly that you do *not* mean literally
» to "get rid of" the transaction protocol, but only to delegate
» it to a different software component?
»
» >What I propose is that BPML support at the metamodel level the concepts
» >of business transactions and collaboration. Isn't a business process a
» >series of coordinated collaborations (with partners, with enterprise
» >systems, and with users) ?
»
» Makes sense to me...
»
» >Don't get me wrong, I would like to see BPML to succeed, I am just
» >trying to point at the past and show that BPML suffers the same lack of
» >vision that a WfMC or OMG has had (I need to catch up on UML 2.0 to see
» >where the OMG is going). It is actually amazing to me that each group
» >(WfMC, BPMI, EDOC, OMG MS, IBM...) consciously omits one or more side
» of
» >the problem. BPML acts just as if B2B did not exist. Aren't 90% of
» >enterprise processes driven by some kind of customer, supplier or
» >channel partner interaction?
»
» Exactly.  But then some people complain (justifiably) that
» ebXML ignores internal business systems...
»
» -Bob Haugen
»
»
»
»
» ----------------------------------------------------------------
» The ebxml-dev list is sponsored by OASIS.
» To subscribe or unsubscribe from this elist use the subscription
» manager: <http://lists.ebxml.org/ob/adm.pl>
»