OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC