RE: [ebxml-bp] Specification of a Business Service Interface

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

Yes, I guess, my notion of pub/sub in this instance requires more
clarity. I think we are aligned, I really meant that once a system has
subscribed to a business transaction activity there would not be other
systems registering for the same BTA(I don't want to use should not). I
mentioned a pub/sub mechanism because the system registers once and then
each time an instance of that BTA is performed the corresponding
documents are "published" to the system. I did not imply necessarily the
usage of MOM and queues

Jean-Jacques

-----Original Message-----
From: Patrick Yee [mailto:kcyee@cecid.hku.hk] 
Sent: Wednesday, June 02, 2004 6:43 PM
To: Jean-Jacques Dubray
Cc: ebxml-bp@lists.oasis-open.org
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>
>     ------------------------------------------------
>