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


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


Great words!

As I noted earlier - I think we can just take what you have here - clean
it up some - and then have two call-out sub-sections under
"Assumptions" in the BPSS V2 for people to gain a basic understanding
of the concepts.

Also - a very simple diagram - showing how the BPSS ebBP works
with BSI, MSI etc will help people visualize the relationships.  At
this point I believe that is enough for BPSS V2 specification to

Thanks, DW

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Sacha Schlegel" <sschlegel@cyclonecommerce.com>; "ebXML BP"
<ebxml-bp@lists.oasis-open.org>; <ebxml-msg@lists.oasis-open.org>
Sent: Friday, February 04, 2005 10:31 AM
Subject: 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

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

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




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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]