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

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

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
>