OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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]