Re: [ebxml-bp] ebBP 2/3/2005: Minor Update to Descriptive TextMSI-BSI Relationship

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

John / Sasha / Monica,

I think we need a conceptual overview of the BSI and MSI somewhere
that is called out.

Maybe in the Assumptions section?

As a team we've kinda internalized the BSI / MSI concepts - and for
new readers we need to give them a quick on-ramp.  I think we can
also possibly reference existing BSI and MSI examples to put them
into context for people.  BSI - something like JMS, J2EE?  MSI -
how an ebMS server supports transaction handling?  I thought I
saw something to this effect in the document already - but we
need to give it its own headings, etc.

I'm trying to get some coding finished for Monday deadline here - so
if someone else can find time to draft up something for us?

Thanks, DW

----- Original Message ----- 
From: "Yunker, John" <yunker@amazon.com>
To: "Sacha Schlegel" <sschlegel@cyclonecommerce.com>; "ebXML BP"
<ebxml-bp@lists.oasis-open.org>
Sent: Thursday, February 03, 2005 6:33 PM
Subject: RE: [ebxml-bp] ebBP 2/3/2005: Minor Update to Descriptive
TextMSI-BSI Relationship


Sacha,

The point the specification is making in the refereced text is:  The
interaction between the MSI and BSI is not specified in the BPSS spec.
Also, for any specific partner, the BSI may not exist as a separate entity,
but may only exist "logically" and be implemented in the behavior of the
MSI.

The BSI as described in the BPSS is the logical orchestration of the (set
of) transactions, and prescribes behavior of the MSI in the context of the
overall collaboration, as well as providing requirements to the MSI related
to quality of service (such as non-repudiation, privacy, authorization,
etc), and other service configuration information.

I recognize that it would be helpful to have a reference implementation (or
even model) of the BSI collaboration state engine, however that is out of
scope and left to individual implementers of the eBusiness Protocol Stack.

Please note that the exchange of messages through the MSI "is" the way
partners align the state of their BSI, there is no other mechanism provided.

We are focused on creating a machine readable "shared definition" of
behavior, which is the basis for consistent behavior across the messaging
interface.

Hope this helps.
John

-----Original Message-----
From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com]
Sent: Thursday, February 03, 2005 3:16 PM
To: ebXML BP
Subject: Re: [ebxml-bp] ebBP 2/3/2005: Minor Update to Descriptive
TextMSI-BSI Relationship


Hi ebBP team

Some comments

a)

A concern I have is to ensure that any BSI can be used with any MSI and vice
verca.

>From the quote:

"For example, the BSI may be instantiated or provide requirements that guide
or generate the MSI to react to specific events defined in the business
process"

I do not want to have a proprietary "BSI is guiding an MSI" because that
would not allow for exchangeable a BSI and MSI.

The goal should be to achieve this "guiding" through an ebBP spec
standardized way.

Appolgies if this can be done already by the BSI sending defined BPSS
signals to the MSI for the remote trading partner.

Otherwie a disclaimer to not define how a BSI and MSI interact should be
added.

One thought: If the MSH receives an ebXML message from the remote trading
partner the MSH does its job of decrypting, sending technical ack AND
forwarding the payload to the next component in the chain. Well, the next
component in the chain is the BSI. Without metadata along the payload the
BSI would not be able to associate the payload (imagine encrypted payload)
with any ebBP instance it executes or monitors. The requirement to have this
metadata is such a "not specified or defined" part which is needed for a BSI
and MSI to be able to communicate with each other.

I admit to come from an implementer side :)

b)

>From the quote:

"The ebXML concept of a business transaction and the semantics behind it are
central to predictable, enforceable commerce."

Is this limited to ONE "business transaction" only or also to a choreography
of business transactions (including fork and joins)?

Regards

Sacha



Am Donnerstag, den 03.02.2005, 09:30 -0800 schrieb Monica J. Martin:
> Minor update (Thanks to Hima Mukkamala, for the details): Change is
> designated by [add]...[end-add].
>
> Thanks.
>
> > =================
> > Section 4: Language Overview
> > =================
> > FROM:
> > The BSI is completely separate from the Message Service Interface
> > (MSI). In particular an MSI MAY be used without a BSI. A CPA, which
> > contains a reference to a ebBP definition serves as the basis for the
> > configuration of the BSI to enforce the protocol and semantics of the
> > ebBP definition, as depicted in Figure 1.
> >
> > TO:
> > The BSI is completely separate from the Message Service Interface
> > (MSI). They may effectively be used together even though the MSI MAY
> > be used without a BSI.. The BSI is a logical definition for a party's
> > actions. A CPA specifies actually the interface with access points
> > defined by the business process specification used. The CPA, which
> > contains a reference to an ebBP definition, serves as the basis for
> > the configuration of the BSI to enforce the protocol and semantics of
> > the ebBP definition, as depicted in Figure 1.  [add] The use of the
> > MSI for a particular business interaction is constrained by the BSI
> > based on the characteristics defined in the business process
> > definition used. [end-add] The ebXML BPSS technical specification does
> > not specify how the BSI is implemented.
> >
> > <<Implementer's note: The ebXML BPSS technical specification does
> > not
> > specify how the BSI is implemented.  For example, the BSI may be
> > enabled through a BSI-aware business application or through behavior
> > implemented  as part of an MSI component.  The business application
> > may produce the business signals that are sent (realized) by the
> > Message Service Handler.>>
> >
> > At a minimum, the BSI relates to the MSI in three ways:
> >
> >   1. Provide requirements to MSI.
> >   2. Constrain implementation of the MSI.
> >   3. Provide for auto generation of MSI.
> >
> > Design and deployment decisions may guide where an implementation
> > lies
> > on this continuum. In the ebXML BPSS technical specification, option 2
> > is recommended. As a design choice, the ebXML architecture, and this
> > specification, modularizes and separates these different process and
> > messaging functions.
> >
> > Section 4.7: Core Business Transaction Semantics
> > Additional text proposed for the first paragraph or a second
> > paragraph
> > after the first.
> >
> > FROM:
> > The ebXML concept of a business transaction and the semantics behind
> > it are central to predictable, enforceable commerce. It is expected
> > that any Business Service Interface (BSI) will be capable of managing
> > a transaction according to these semantics.
> >
> > TO:
> > The ebXML concept of a business transaction and the semantics behind
> > it are central to predictable, enforceable commerce. It is expected
> > that any Business Service Interface (BSI) will be capable of managing
> > a transaction according to these semantics.  As the BSI is a logical
> > definition, design and deployment choices are not specified (See
> > Section 4).  For example, the BSI may be instantiated or provide
> > requirements that guide or generate the MSI to react to specific
> > events defined in the business process.  The MSI may interact with the
> > BSI, that
> > recognizes the state of a business transaction. This may enable the
> > MSI to implement rules when specific steps occur. The semantics
> > defined in the ebXML BPSS technical specification enable the BSI to
> > constrain and guide design and deployment based on the business
> > transaction semantics.
> >
> >
>
>