[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Specification of a Business Service Interface
Patrick, +1 on the binding to protocols. This is the big strength of BPSS - being able to publish a model that then can be quickly purposed to a specific deployment scenario. Thanks, DW ----- Original Message ----- From: "Patrick Yee" <kcyee@cecid.hku.hk> To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com> Cc: <ebxml-bp@lists.oasis-open.org> Sent: Wednesday, June 02, 2004 9:42 PM Subject: Re: [ebxml-bp] Specification of a Business Service Interface > Sorry for the confusion. What I tried to say is only that, in the > pub/sub mechanism you mentioned, with high chance there is only one > publisher and one subscriber. :-) > Regards, -Patrick > > > Jean-Jacques Dubray wrote: > > > I don’t understand your comment, what do you mean by peer-to-peer? I > > assume that the goal is that the BSI should not know anything specific > > about the target system this is why I suggested a pub/sub mechanism. > > The logic which decides who handles what should remain in the back-end > > system. I don’t expect that the BSI should engage in a “collaboration” > > with back-end systems. If further decoupling is needed between the > > collaboration and the back-end system, one can use an orchestration > > engine (e.g. BPEL) for that purpose, but again from a BSI perspective, > > this is completely transparent. A BSI should know nothing about BPEL. > > > > JJ- > > > > ------------------------------------------------------------------------ > > > > *From:* Patrick Yee [mailto:kcyee@cecid.hku.hk] > > *Sent:* Wednesday, June 02, 2004 8:19 AM > > *To:* ebxml-bp@lists.oasis-open.org > > *Subject:* Re: [ebxml-bp] Specification of a Business Service Interface > > > > 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 <mailto:jeanjadu@Attachmate.com> > > > > *To:* Sacha Schlegel <mailto:sacha_oasis@schlegel.li> ; > > ebxml-bp@lists.oasis-open.org <mailto: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 > > <mailto: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 > > <http://www.schlegel.li/sacha.gpg> > > ------------------------------------------------ > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]