RE: [ebxml-dev] BPMI?

[Jean-Jacques Dubray <jjd@eigner.com>]

Stephano:

Thans for all the precisions 

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

[JJ] Yes, and consequently, isolate the internal systems from the
details of the CPA: if all is well don't tell me anything, just notify
me of exceptions (unauthenticated users, wrong message formats, timeout,
out of sequence messages, ...)

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

[JJ] Actually, mapping is a responsibility that fits well BPMS as a
broker of very disparate entities, so I would not necessarily put that
in the BSI unless it is a preliminary mapping (e.g. Flat file attachment
to some XML).

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

[JJ] yes, this is definitely a responsibility of the BSI though it is
hard to implement in practice. 

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

[JJ] The problem is that the semantics and protocol of a business
transaction does not land well in the web service concept. For instance,
in BPSS you send a request and waiting for a response. In the mean time,
two acceptance signals can flow back before you actually receive the
response. This is done for good reason: non repudiation, guaranteed
message delivery (at the business level). Also a response in BPSS is one
of many possible formats. Lastly, a business transaction has a series of
possible exceptions which must be handled at the process or enterprise
system level (clean up). For all these reasons, I think that a business
transaction should be a first class citizen in the BPML metamodel, just
like web services are.

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

[JJ] Sorry for the confusion, I never said it should be removed, I just
meant that the internal systems do not care about the details of the
protocol. Only exceptions should be escalated for further processing as
they impact the "business process".

[JJ] Cheers,
[JJ]