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