[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 David See comments/question below ... Am Fre, den 04.06.2004 schrieb David RR Webber um 16:06: > Sacha, > > I like to keep things simple. While BPSS is not like BPEL - that > does not preclude you having a system like JBoss / jBPM, > Websphere, BizTalk, J2EE etc, referencing the BPSS and > being able to manage and control the business process > accordingly at runtime. > > What that means - as you identified - is that there needs > to be a standard set of signals between the transport > services and this BP manager component Yes, that is what I am asking how that is done. > - however > that's implemented. Where, how? Do you have an example how a runtime MSH and a runtime BSI communicate? Or better, how do you see a runtime MSH communicating (both directions) with a runtime BSI? > We've certainly got a set of those > already in the schema - and the transport must be able > to communicate those to the BP engine. Yeah I question how its communicated, possibly in some defined manners, so I can use any MSH implementation with any BSI implementation and vice verca. Unfortunately I did not follow BP that closely to know where this information (how to communicate, and which information/signals) can be found. > We do need to > do a better job of aligning that - right now we are > working with the ebMS folks to make that better - and > so that our QoS settings tightly align with the ebMS and > CPA details too. > > I think the idea is to get that done for V2 release - so it > works well - and then use lessons learned there to do > a broader BSI for V3. > > Notice also that the ability to call tools like CAM for > document handling and have context instances - covers > the need to integrate into the backend applications. Isn't in this case such a CAM tool another backend application? Kind regards Sacha > > This is definately loosely coupling - people can choose > a variety of ways to implement a deployment from the > BPSS model. And of course they can make it tight > coupled if they wish. > > Flexiblity is a key advantage. > > Thanks, DW > > ----- Original Message ----- > From: "Sacha Schlegel" <sacha_oasis@schlegel.li> > To: <ebxml-bp@lists.oasis-open.org> > Sent: Friday, June 04, 2004 8:53 AM > 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 -- ------------------------------------------------ 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]