[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [ebxml-bp] Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]