RE: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary ofBSI-MSI

["Yunker, John" <yunker@amazon.com>]

re: [Sacha]Why are is a Message Service Interface mentioned. This interface is that abstract that not even the interface is described. Guess it is not even an interface if it is not defined."

The BPSS (together with CPA) _defines_ the MSI interface and _SHARED_ MSI behavior as seen from the Collaboration.  The BPSS defines the _SHARED_ BSI behavior as visible to the Collaboration.  In this case the Collaboration is defined as the shared view to the business process and the messages that support it.

Both BSI and MSI are not formal acronyms in the sense of something to be trademarked.  Conceptually they are:
	- Message(ing) Service Interface (MSI): the set of messages exchanged between partners, and the interface defined rules governing sequencing and processing, used to support a business process.  The BPSS specifies the sequencing and (some of the) procesing rules.
	- Business Service Interface (BSI): the allowed set of business process and business object states of a business process, and the rules governing transitions between these states.  Within the BPSS, the only physical interface to the BSI is through the messages.  

The key here is that "interface" refers to the published (public) access and behavior specification.  

I really don't care if we call it MSI/BSI or Messaging Service Interface / Business Service Interface.

Thanks,
John

-----Original Message-----
From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com] 
Sent: Tuesday, February 08, 2005 12:50 AM
To: Duane Nickull
Cc: ebXML BP
Subject: Re: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary ofBSI-MSI


ebBP team, Duane,

comments inline ...

Am Montag, den 07.02.2005, 13:26 -0800 schrieb Duane Nickull:
> 
> Monica J. Martin wrote:
> 
> > 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. 
> 
> I would caution you that there are companies who have prior use of the
> term "MSI" in the context of a programmers interface to ebXML MS 
> software.  Accordingly, it may be subject to trademark and/or 
> copyright.  I cannot verify this any further at this time.
> 
> Discussing concrete interfaces also violates one of the core 
> principles
> of ebXML in the architecture which was not to impose any specific 
> implementation style *where unnecessary* upon those building software.  
> Prescribing interface based design is one constraint that is not in 
> alignment with either the core requirements or architecture of ebXML.

I cannot argue against the "principles of ebXML" as I have not been there at that time the pricnciples were put into stone.

But I can ask why? What was the rationale to not have components based ebXML building software?

Why are is a Message Service Interface mentioned. This interface is that abstract that not even the interface is described. Guess it is not even an interface if it is not defined.

With everything being so abstract everyone tends to do whatever he/she thinks is right. And because it is so abstract, virtual, logical, everyone is having a valid solution.

Please excuse me but I see value for ebXML end users to be able to pick their building ebXML components.

I feel silly because it is currently just one interface the one between the MSH and an ebXML business process component. The one between an ebXML business process component can follow thereafter.

> 
> Accordingly, it may be a better idea to discuss this as the 
> association
> with the messaging component of the architecture, not the interface.  
> Align the functionality abstract of the implementation.  Interface 
> descriptions are probably better handled in a JSR type group than the 
> core standard.

OK so there is a place for interface descriptions. The thing to me is if they are not part of the core standard they are simply of less importance, in particular to the Independet Software Vendors (ISV's).

JSR as in Java Specification Request is not what I am looking for as that is language specific.

But I recognise you saying that there is room for interface descriptions.

Regards

Sacha

> 
> Duane
>