RE: [ebxml-bp] ebBP 2/3/2005: Minor Update toDescriptiveTextMSI-BSI Relationship

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi John

See comments inline ...

Am Donnerstag, den 03.02.2005, 16:22 -0800 schrieb Yunker, John:
> Ahhh...  I think I might understand what you are looking for now.
> 
> Are you are looking for the specific elements in the ebBP that specify configuration of an ebMS_MSI_Implementation so that it is in compliance with the BSI?  (of course CPA enters this picture)
> 
> This is an excellent point Sacha, and one we should make sure is addressed.  

> The ebMS, ebBP, CPA should be able to act as a reference set and should (as completely as possible) define MSI/BSI behavior without requiring human interpretation...

ebBP = electronic business Business Process aka BPSS aka collaborative
business description in XML

Once created, the CPA is very central. You can cross out ebMS and ebBP
because the CPA references the ebBP and the ebMS is configured with the
CPA.

Yes the ebBP is one input for a CPA creation, if we take the short cut
and circumvent CPP's. Of course, there can be many ebBP's be input for a
CPA.

What is a MSH and an MSI?

In my world:

o The CPA includes the interface of one party for the other party (there
are always only two party's per CPA)
o The MSH is the component which physically receives and sends ebXML
messages, if defined with encrypts and decrypts them, sends technical
acknowledgements, takes care or reliablity, non-repudiation etc.
o The MSI is the interface of a MSH. Unfortunately, the ebMS
specifications do not define the interface. The interface (MSI) is what
the next component in the chain would use to communicate with the MSH.
When having an ebBP execution or monitoring component, that would be the
component interacting with the MSI.

In my world (before Monica mentioned that the ebBP TC charter states
that the ebBP is not intended to be executable):

o A Business Service Handler (BSH) is the component which executes or
monitors the ebBP instance. A BSH is able to run different ebBP
instances simultaneously. The BSH would receive a message (thinking that
the MSH only forwards the payload of the ebXML message with metadata as
opposed to that the MSH sends the ebXML message) and checks if the
message is in conformance with the ebBP instance the payload with
metadata is associated with (the BSH must get the correct ebBP instance
through lookup of the conversation ID). If the message is in
synchronization with the ebBP instance the BSH send the receipt
acknowledgment. The BSH will then forward the message to the next
component in the chain which can be a bus, a mom, a backend application,
a web service, a ws-bpel engine waiting for this event, others, clearly
leaving ebXML territory). Good luck to get a positiv or negative
Acceptance Acknowledgment. Here is the clear, to me, interface between
ebXML infrastructre and domain or organisation infrastructre. The
integrator has to make sure that the BSH gets the Acceptance
Acknowledgement (negative or positive) somehow. As specified, and
mentioned many times in the phone conferences, only with the usage of
the Acceptance Acknowledgement signals state alginment between partners
can be guaranteed. So only if the backend services are capable of
providing this information ebBP can be used wen state alignment is
required (commercial transaction).

So what is the BSI? 

I guess historically in the ebXML circle people have used the notion of
a BSI before the notion of a MSI, so I can be wrong as I got the MSI
first in my world and now try to map from the MSI to the BSI. 

In accordance to my understanding of the MSI, the BSI should also be the
interface of the BSH. Which side of the BSH? BSH interface to MSI or BSH
interface to backend application?

Sometimes I think to understand that the BSI would like to be the
interface even infront of the MSH towards the trading partners, level
with the CPA's just without technical information ... so I think it is
important to clarify this, maybe in ebSOA or the place to update the
ebXML technical architecture.

Otherwise the MSI and BSI terms are used differently.

So let me use BSI as the interface to the BSH component. So in my world
I have the BSI facing the MSI. 

Maybe the BSI can even face the backend as well...this becomes a bit
fuzzy...similar to the CPA being the interface of one party to the other
instead of the MSI also being the interface to the other party.

MSI and BSI sound like API's or synchronous interfaces. I guess MSI and
BSI should have asynchronous interfaces, so there is a need for metadata
along the paylod (similar to the ebXML message holding the payload). 

Here my original question for an asynchronous interface:

In an asynchronous MSH and BSH communication are special signals to
interact with each other necessary?

To interact in the sense of the BSH guide the MSH or the BSI guide the
MSI?

Sorry for introducing BSH.

I am aware that other people can have a complete different view of the
things. I am interested in seeing different views.

Regards

Sacha

> 
> I haven't reviewed the spec from this point of view.
> 
> Dale, you probably have a more complete knowledge of these dependencies...
> 
> Thanks,
> John
> 
> 
> -----Original Message-----
> From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com] 
> Sent: Thursday, February 03, 2005 4:03 PM
> To: Yunker, John
> Cc: ebXML BP
> Subject: RE: [ebxml-bp] ebBP 2/3/2005: Minor Update to DescriptiveTextMSI-BSI Relationship
> 
> 
> Hi John
> 
> See some comments inline...
> 
> Am Donnerstag, den 03.02.2005, 15:33 -0800 schrieb Yunker, John:
> > 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.  
> Thanks. This is the statement I was looking for but not liking ;) But as long as this is clear to everyone it is fine for me.
> 
> > 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.
> Agree.
> 
> So we have loosly coupled ebXML specifications (ebBP and ebMS in this case). This does not mean that implementations of the specifications are also loosly coupled. Eg it can happen that one implementation implements more than one specification. My question makes only sense when looking at individual implmenetations of specifications. In that case, as you stated above, the interaction is not specified, which means that I can end up having an ebBP specification implementation and an ebMS specification implementation which I cannot used together. 
> 
> I am talking just about the setup up at one party. As mentioned above this party does not know about the other party but knows that the other party is following the same ebBP instance and that is all it has to know.
> 
> > 
> > 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.
> Agree.
> > 
> > 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.
> Agree.
> >  
> > 
> > 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
> Helps, thanks.
> Sacha
> > 
> > -----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.
> > > >
> > > >
> > > 
> > > 
> > 
>