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" <>
To: "Dale Moberg" <>
Cc: "Monica J. Martin" <>; "David Webber (XML)"
<>; "Sacha Schlegel" <>; "ebXML
BP" <>; <>;
"ebsoa" <>
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:]
> >Sent: Friday, February 04, 2005 1:53 PM
> >To: Monica J. Martin
> >Cc: David Webber (XML); Sacha Schlegel; ebXML BP;
> >; 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
> ***********
>
>
>
