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

["Sacha Schlegel" <sschlegel@cyclonecommerce.com>]

Hi Hima
 
I did look at your diagram but to be honest I did not understand it.
 
Are there 2 parties involved? 
 
o Auto Parts Manufacturer 1
o Auto Parts Manufacturer 2
 
Are these two parties doing B2B?
It looks like what you draw between the two Auto Parts Manufacturer includes backend application integration, such as access to a VW Supply Chain System.
 
To which party belongs the VW Supply Chain System on the left and on the right in the picture?
 
What is the line, the one which is drawn behind the "CPA instance" documents? What do you want to indicate with that line?
 
The "MSH" component ... does it belong to Auto Parts Manufacturer 1? Same question for BPM/BPE/BSH.
 
Excuse me but I do not get your picture...
 
Sacha

 
________________________________

Von: Himagiri.Mukkamala@sybase.com [mailto:Himagiri.Mukkamala@sybase.com]
Gesendet: Di 08.02.2005 10:11
An: Sacha Schlegel
Betreff: Re: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI







Sacha, This has been my view of the whole BSI/MSI mix. FYI
(See attached file: MSH_MSI.doc)


                                                                          
             Sacha Schlegel                                               
             <sschlegel@cyclon                                            
             ecommerce.com>                                             To
                                       Duane Nickull <dnickull@adobe.com> 
             02/08/2005 12:49                                           cc
             AM                        ebXML BP                           
                                       <ebxml-bp@lists.oasis-open.org>    
                                                                   Subject
                                       Re: [ebxml-bp] Re: ebBP 2/7/2005:  
                                       Updated Combined Summary of        
                                       BSI-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
>