[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebsoa] Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on
Duane, As I said earlier - its clear we have moved a long way from the original early work - and this all needs updating. DW ----- Original Message ----- From: "Duane Nickull" <dnickull@adobe.com> To: "Dale Moberg" <dmoberg@cyclonecommerce.com> Cc: "Monica J. Martin" <Monica.Martin@Sun.COM>; "David Webber (XML)" <david@drrw.info>; "Sacha Schlegel" <sschlegel@cyclonecommerce.com>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>; <ebxml-msg@lists.oasis-open.org>; "ebsoa" <ebsoa@lists.oasis-open.org> Sent: Friday, February 04, 2005 4:37 PM Subject: [ebsoa] Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on > Dale: > > No problem, let me explain. BSI is an abstract, all inclusive > architectural term used to describe how another party can engage with > the party. It was used rather than tying the architecture specifically > to CPP, CPA, BPSS and anything else. We used this for a number of > reasons. One was at the time, it was clear that Core Components would > not produce Schemas or other payload metadata. Such is clearly needed > at the concrete level to build an implementation. Also BPSS told the TA > group that they were not working on a serializable format for BPSS, > something that has since been corrected. It was a catch-all concept > (business items, technical parameters, etc.) but no explicit set of > parameters was named to make up the concept. > > Instead of interfaces to java classes (which do usually use the > convention of the class name), think of it like an abstract java class > that is not for implementation. It gets implemented using other > concrete classes. In a UML class view diagram, when one uses the > <<abstract>> stereotype, I think the convention is not to duplicate the > abstract class name in the concrete class name. > > To implement the concept, one would inherit the concept into their > specific ebXML architectural model, then specialize and elaborate it > using things like CPA, BPSS, SOAP, WSDL etc. In short, it is best > described as a component of a reference model that architecture, even > though it does talk about it within the architecture quite a bit. > > There is no really need to worry about it unless someone starts trying > to discuss building a concrete BSI spec ;-) > > Duane > > > > Dale Moberg wrote: > > >Hi Duane, > > > >It seems a bit confusing to me to say that something that implements an > >interface cannot use the name of the interface when indicating what > >interface it is implementing. > > > >E.g., java classes implement interfaces and use the name of the > >interface to indicate the interface(s) so implemented. > > > >Puzzled what your point is. Too abstruse for me. Not going to worry > >about it unless you clearly explain the badness. > > > >If there is a gap, I guess it means that there needs to be a realignment > >of the outgrown 1.04 draft with what is going on. Too bad we don't have > >a replacement yet :-) > > > >Dale > > > > > >-----Original Message----- > >From: Duane Nickull [mailto:dnickull@adobe.com] > >Sent: Friday, February 04, 2005 1:53 PM > >To: Monica J. Martin > >Cc: David Webber (XML); Sacha Schlegel; ebXML BP; > >ebxml-msg@lists.oasis-open.org; ebsoa > >Subject: Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap > >between MSI and BSI and move on > > > > > > > >Monica J. Martin wrote: > > > > > > > >>mm2: Education is always an opportunity Duane. Remember that the/these > >> > >> > > > > > > > >>interface(s) may actually become physical in a deployable logical > >>environment. I believe our original text surrounding this relationship > >> > >> > > > > > > > >>was clear after all. However, I will in more detail review the many > >>posts last night and today to see what can be improved upon in the > >>text that was agreed to yesterday morning. Thanks. > >> > >> > > > >Monica: > > > >When they become physical, they should be called CPA, eb MS and BPSS. > > > >There is no concrete BSI. BSI is an abstract concept - it would be very > > > >bad practice (and most confusing) for someone to develop a concrete > >thing and give it the same name. > > > >Education attempt: > >When modeling, BSI is an abstract concept. > >When implementing, can be done via CPA, MS and BPSS. > > > >Duane > > > > > > > > > > -- > *********** > Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com > Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ > Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html > *********** > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]