MHonArc v2.5.0b2 -->
ebxml-msg 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
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.