[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]
Powered by eList eXpress LLC