OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[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]