Fw: [ebxml-bp] Closing the gap between MSI and BSI and move on

["David Webber \(XML\)" <david@drrw.info>]

More thoughts from BPSS-land.

Clearly better granularity and clarity will help sort out the
roles of the various components - and the overlaps!

DW

----- Original Message ----- 
From: "Sacha Schlegel" <sschlegel@cyclonecommerce.com>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "ebXML BP"
<ebxml-bp@lists.oasis-open.org>; <ebxml-msg@lists.oasis-open.org>
Sent: Friday, February 04, 2005 11:54 AM
Subject: AW: [ebxml-bp] Closing the gap between MSI and BSI and move on


Hi Dale,

So MSI part is as I understand.

The BSI part becomes a bit vague. Its abstract, its virtual, its logical,
all well and good but at one point it has to become specific.

So what we agree is that whatever the BSI is, it will be responsible for
BPSS signals.

So what is a specific BSI?

o J2EE applications, busses, simple backend application, series of web
services, currently íts just about anything ...

I can argue contrary that you do not want to give the responsibilities of
the BPSS signals to all and everything being part of the BSI. This is the
opposite to rip out existing applications or internal data formats.

So I see two cases:

1) A BSI is anything spread among anything at one party
2) A BSI (or BSH) is a specific component (a ebBP business process engine)
which takes on the responsibity of the BPSS signals. A component that is
build for ebBP´s.

With the second case we could close the gap between BSI and MSI.

But with the second case we still have not integrated with the actual
backend applications, services. With this approach we would at least, have a
proper ebXML chain consisting of BSI and MSI.

Following private business processes from too far away it seems to me that
private business process engines (such as WSBPEIL) are discussed today as a
solution for private business processes.

If we were at this stage we would still have the gap between the BSI and
WSBPEL. That would be the next task.

To come back to the BPSS signals. If a WSBPEL instance knows to communicate
with a BSI and vice verca, a WSBPEL instance would know about BPSS signals,
such as Acceptance Acknowledgements.

So, having a specific BSI (with an interface between BSI and MSI) and an
interface between BSI and WSBPEL for example is ONE way to get where we
want.

Regards

Sacha

PS: Of course MSH implementations can still be connected straight to their
backend applications or service or abstract-virtual BSI ;) as is probably
done today.

________________________________

Von: Dale Moberg
Gesendet: Fr 04.02.2005 08:31
An: Sacha Schlegel; ebXML BP; ebxml-msg@lists.oasis-open.org
Betreff: RE: [ebxml-bp] Closing the gap between MSI and BSI and move on



Hi Sacha,

The BSI concept mainly comes from the ebXML architecture document and the
BPSS working area.

The MSI concept was, I think, one that has been worked on from time to time
in Messaging and was basically an API for communication between the software
component(s) functioning in the MSH role (at a given node) and the software
(other middleware or business applications) that needed to communicate with
a MSH at that node. [An interface between "levels" of the stack at a node.]
Submitting and being notified of message payloads (along with selected
metadata concerning that payload), being notified of exception conditions,
and so on were the envisioned functions of the MSI API. Matt and others even
submitted materials for an API definition and we found that OAG (or was it
OMG?) had drawn up some IDL for an API in this area. Messages on this are
probably still in the Messaging list archive. [If you go back several years,
you will find other contributions. It is a perennial topic.]

I think that the Messaging TC decided to work on version 3.0 as a higher
priority than the API for MSI. That doesn't prevent someone from submitting
a draft for TC consideration eventually, though Ian would need to check the
process for us in Messaging. I agree with you that someday this needs to get
done. At the moment each MSH integration is a customized exercise depending
on the deployment environment (EAI or not; if so, what style, etc. etc.)

The BSI as discussed in BPSS and the early Architecture document is IMO an
interface at a specific level of the protocol stack, but an interface
between the same stack level but at different nodes. It is a virtual (or
logical) interfacing whose actual realization is accomplished by using the
supporting layers of the stack to carry out its protocol. Abstractly the BSI
is accomplished whenever ebXML message exchange carryies out (via its lower
protocol levels) a BusinessTransaction (in the BPSS sense). BSI in BPSS
involves the "signals" (both positive and for exceptions) that achieve state
alignment (including clear failure states).

So BSI is somewhat defined. What more do you think needs to be done for it?

It is true that BSI will be realized by some assignment of responsibilities
to software as deployed in some environment. I am not certain that anyone
has proposed standardization of its implementation by even saying which
roles of software components carry out which BSI related tasks. There are
just a whole lot of existing combinations in businesses for these deployment
environments, and overall the consensus view has been that standardizing
these largely internal configurations would be too controversial to achieve
consensus. [A standard which said that businesses had to rip out existing
applications or internal data formats or message busses would be probably
doomed to sit without any market traction, with at most one large vender
supporting it, which would be the vender whose software or platform or
language or development IDE followed the standard!] So I am a little dubious
that we should try to standardize this area without receiving clear broadly
based requirements and commitments from the end user community. Absent their
interest, a basis for consensus in standardization among ISVs is most
unlikely.


-----Original Message-----
From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com]
Sent: Friday, February 04, 2005 7:32 AM
To: ebXML BP; ebxml-msg@lists.oasis-open.org
Subject: [ebxml-bp] Closing the gap between MSI and BSI and move on

Hi ebXML Message Service team
Hi ebXML Business Process team

I suggest to define an interface between

o MSI and BSI (or MSH and BSH)

and close that gap in the ebXML spec and move on to the next step, from a
ebBP view point, to define an interface between

o BSI and private business process engines (or BSH and OASIS WSBPEL for
example)

Regards

Sacha

-----------------------------

MSH = Message Service Handler
BSH = Business Service Handler
MSI = Message Service Interface
BSI = Business Service Interface
WSBPEL = Web Services Business Process Execution Language

PS: BSH is to ebXML Business Process what MSH is to ebXML Message Service