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

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi David

See comments/question below ...

Am Fre, den 04.06.2004 schrieb David RR Webber um 16:06:
> 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 

Yes, that is what I am asking how that is done.

> - however
> that's implemented. 

Where, how? Do you have an example how a runtime MSH and a runtime BSI
communicate? Or better, how do you see a runtime MSH communicating (both
directions) with a runtime BSI?

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

Yeah I question how its communicated, possibly in some defined manners,
so I can use any MSH implementation with any BSI implementation and vice
verca.

Unfortunately I did not follow BP that closely to know where this
information (how to communicate, and which information/signals) can be
found.

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

Isn't in this case such a CAM tool another backend application?

Kind regards

Sacha

> 
> 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
-- 
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------

Dies ist ein digital signierter Nachrichtenteil