[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Specification of a Business Service Interface
Hi Jean-Jacques, Patrick, David, Monica and others Thanks for your replies. Please remind yourself that I have an academic background without practical integration exeprience. Also this post more talks about the implementation of the ebXML architecture (Backend,BSI,MSH) rather then ebXML BP specific items. Some thoughts. Qustiones indicated with Q: o Use of BSI ------------ I sort of see that a BPSS is not per se executed but rather observed if the exchanged messages actually follow what is defined in the ebXML BP. Q: How do you see the business document message flow? In my scenario I have 3 components: Backend Application, BSI, and MSH. So far I was considering the following message flow: <-|-> MSH <--> BSI <--via pub/sub--> backend application Is this how you see the message flow as well? Could the MSH send the message straight to the backend application or is it necessary to go through the BSI, to make sure the that collaborative business process is followed? o Integration of BSI with Backend(s) ------------------------------------ Seems OK to use the publish/subscribe pattern for backend integration. In the case that there is only one publisher and one subscriber one could think to directly connect the BSI with the backend application. One drawback here I see, is that this would allow to create dependency between BSI and a specific backend application, eg customised code, BSI using backend specific API etc. I am sure this is against the idea of having seemless application integration. Q: Do you see a loose coupling between backend application and BSI? Don't you think, that the backend application might need information of the ongoing collaboration (BSI system)? I think this questions where collaboration logic is handled, whether a backend system is collaboration agonistic or if it also follows collaboration information (collaborative business process). Q: Must the backend application be aware of the engaged collaboration with other parties? Must the backend application know about the collaborative business processes (would look like BSI and MSH beome an internal component of the backend application)? Example: collaboration agonistic backend application. ebXML BP is running. BSI sent Order message... according to BPSS the Order receiving party must acknowledge the Order with a Order Confirmation business document within 2 days. After 2 days no Order Confirmation which means the ebXML BP fails. Here comes my problem: The BSI must communicate the failure of the collaborative business process to the backend system, eg the BSI sort of must call a "order cancellation" procedure on the backend system. This seems like a problem to me as I do not want to code procedures of specific BSI (of vendor X) to specific backend (of vendor Y). I am not sure if the BSI should have such business logic (like if we fail to receive a order confirmation I have to notify the backend system) at all. This notification of order cancellation could be an internal busienss process.... I think this is JJs comment about using WSBPEL for the internal business processes or to have the separation/integration of the collaborative ebXML business process from/with a local internal business process. Q JJ: where would the internal business process (eg WSBPEL) run?`BSI, Backend Application or even in a third application? Q: Is a BPEL BP executed also in two places (analog to ebXML BP with BSI 1 and BSI 2) in a WSBPEL application 1 and a WSBPEL application 2 or maybe a "master" WSBPEL application 3? o Integration of BSI with MSH: ------------------------------ Apparently, today there are a couple of ebXML Message Service Handler implementations and some must be running in the real world today. Maybe a next step is to have them fully CPA driven (not sure if this is the case in some MSH implementations). Then maybe BSI tools will be developed to monitor a MSH or the execution of an ebXML BP. So I am not sure how far the specification should go to enable customers to choose MSH of vendor X and choose BSI of vendory Y. But from a customer point of view this is what gives customer the freedom to choose the best of each (sounds like marketing ;). So are there any ideas, how a BSI (with an ebXML BP) uses a MSH to monitor an ongoing collaboration? An API is maybe too strong but would help in the first place to understand what information exchange is necessary between these two systems. Q: Are there any first approches of the BSI and MSH communication/integration? Kind regards Sacha Schlegel On Wed, 2004-06-02 at 17:19, Patrick Yee wrote: > For the integration between BSI and back-end, the publish-subscribe > pattern is general enough. However, in most cases, the relationship > between BSI and back-end will only be one-to-one (in order > words, peer-to-peer). Under this assumption, we can have the BSI API > reduced to use the peer-to-peer pattern. This simplifies the API > and permits easier binding to physical protocols. > > Cheers, -Patrick > > ----- Original Message ----- > From: Jean-Jacques Dubray > To: Sacha Schlegel ; ebxml-bp@lists.oasis-open.org > Sent: Wednesday, June 02, 2004 9:48 PM > Subject: RE: [ebxml-bp] Specification of a Business Service > Interface > > Sacha: > > Note that an ebXML collaboration is not "executed" per say (in > the > orchestration sense) but observed. Messages are generated by > back-end > systems and merely processed by the BSI as part of a business > transaction protocol. The only part that is physically > executed by a BSI > is the "receipt acknowledgement". Everything else is > "executed" by back > end applications calling into the BSI API. > > On the integration with the back end systems, we should > explore a > subscribe/publish relationship between applications and the > BSI. The > applications will subscribe to specific collaboration/business > transaction activities (more than one back end systems can be > involved > in a collaboration). The BSI would then publish the > corresponding > messages at run-time. > > JJ- > > -----Original Message----- > From: Sacha Schlegel [mailto:sacha_oasis@schlegel.li] > Sent: Tuesday, June 01, 2004 2:58 PM > To: ebxml-bp@lists.oasis-open.org > Subject: [ebxml-bp] Specification of a Business Service > Interface > > Hi BP team > > I am not sure if there was a discusion whether its time to > further > specify the functionality of the ebXML Business Service > Interface (BSI). > > Some obvious functionalites will be: > > o execution of ebXML Business Processes > o monitoring of ebXML Business Processes (Dales use case) > o integration with an ebXML Message Service Handler (MSH) > o integration with backend applications > > I think, there is no API specification of a MSH, but such an > API would > help implementors. The same is probably true for BSI's. Maybe > its not > API based afterall but messaging based. > > Maybe this can become a work item for 3.0 ... > > Kind regards. > > Sacha > -- > ------------------------------------------------ > Sacha Schlegel > ------------------------------------------------ > public key: www.schlegel.li/sacha.gpg > ------------------------------------------------ -- ------------------------------------------------ Sacha Schlegel ------------------------------------------------ public key: www.schlegel.li/sacha.gpg ------------------------------------------------
Dies ist ein digital signierter Nachrichtenteil
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]