RE: [ebxml-dev] BPMI?

[Vishwanath Shenoy <VShenoy@infy.com>]

Hi,

I agree with JJ on the purpose that ebXML serves of being a robust framework to support collaboration. 

BPML addresses the needs of enterprise IT infrastructure. It attempts to provide a process-based view to functionalities addressed by current enterprise IT infrastructure like legacy systems, ERP, EAI and Workflow applications. BPML would have greater visibility into the enterprise applications - handling of application exceptions. 

This distinction should be good enough to keep us from reducing overlap across standards.

An implication of this is that the BPMS would have to support both BPSS and BPML. 

Given that a significant number of processes would be collaboration based, would the BPMS be better off using the same layer for transaction and collaboration within BPSS and BPML. One of the objectives is doing this is to ensure that the BSI for BPSS and BPML has to interoperate.
 
Another aspect to this issue is of facilitating the business modeler to use consistent notations. The modeling notation should be consistent across these two standards. BPMN is a likely candidate for the notation being standardized across the two underlying process standards.


						____________________
				  	Specific Process- Vertical /Horizontal (E.g. RN) 
						____________________
Internal Organization	 			BPMS - BPSS/BPML					Customer Facing Process
						____________________					Supplier Facing Process
							BSI - Transaction/Collaboration
						____________________
							Message
						____________________
							Transport
						____________________


-Vishwa

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Saturday, February 23, 2002 1:43 AM
To: 'bhaugen'; 'Jean-Jacques Dubray'; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] BPMI?



>>
>>If your point in the preceding paragraph was to differentiate
>>between business transaction and business collaboration layers,
>>I agree.  But then I get confused...
>>

[JJ] what I mean by protocol is the different signals which are
necessary to enforce the business transaction semantics (guaranteed
message delivery, non repudiation, ...) Typically, a BPMS and its BPML
should not deal with these details, the BSI should however report
exceptions (business transaction failure). 

>>1. What does "BPMS" mean?  Business Process Management System?
>>Does it live on top of the transaction layer?

[JJ] yes and yes (though top might not be the right view).
>>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.
[JJ] I think that it is pretty clear that you need a) to enforce the
collaboration definition, b) to do it at the BSI level, again, you don't
want to bring to much knowledge of the B2B world into BPML.
 
>>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."

[JJ] Clearly the implementation of a BSI is left to whatever people want
to do. If you want to take the risk not to enforce this, you are free to
do so, in this case you must trust your partner to send you things in
the right order.
>>
>>>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?
[JJ] Sorry, I meant that if the BSI handles the protocol, you can then
pass the relevant business documents to the BPMS, free of the protocol.
It would not be efficient for the BPMS to deal with the signals.

>>
>>Exactly.  But then some people complain (justifiably) that
>>ebXML ignores internal business systems...
>>
[JJ] I think that ebXML does its job well. If I can use a basic image,
an ebXML infrastructure is the equivalent of an HTTP server. You can put
a lot of things behind a web server to increase its value or you can put
a few lines of code or even just a file. I don't think it was the role
of ebXML to provide a model for a large portion of the IT
infrastructure. Rather it provides a robust framework to connect
applications, or BPMS to business partners. Just like HTTP, it would be
a nightmare if web server would support various protocols, the most you
can bear is HTTP 1.0, 1.1, ... I think we passed that point today, ebXML
is going to be the HTTP of the B2B, whether people like it or not. 


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