RE: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

So far I gather:

1. The BSI (Business Service Interface) is not really an interface.
2. BSI is like an abstract class (or a stereotyped <<abstract>> UML
class diagram) and not meant to directly have instances (no "new" method
defined). It can be extended to classes that are themselves
implementable(?) or concrete. Not clear here, but probably not relevant.

An item named "interface" that is not an interface seems a bit
confusing. You can imagine how some of us might have overlooked that
subtlety. 

Still where is the harm in saying that a business has services that have
interfaces? Shall we talk of these as BSI<<ebXML>> to ward off our
apparent "abuses of notation"? 

It might really be fairer to allow non-architectural groups to use the
term and acronyms involving "interface" because that is what we are
talking about. Maybe Abstract Business Service Class for the
architectural catch-all?



-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: Friday, February 04, 2005 2:38 PM
To: Dale Moberg
Cc: Monica J. Martin; 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

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
***********