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

["David RR Webber" <david@drrw.info>]

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 - however
that's implemented.  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.  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.

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