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

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi Steve

Am Samstag, den 05.02.2005, 13:13 +1100 schrieb Steve Capell:
> Ah - I did not see that definition (of a "BSI").  To my mind something
> ending in "H" is a "Handler" (ie the actual piece of software that does the
> job) and something ending in "I" is an interface to that piece of software.
> So a typical middleware that supports transaction / collaboration state
> alignment has:

I had the same take on this.

> 
> One or more MSH (eg one for ebMS and one for WS-**).  These handle reliable
> and secure messaging and are configured from the messaging properties
> defined in either a CPA or a WSDL/WS-Policy).  These (one day) will present
> a standard interface (MSI) to the next components which is the BSH.  The BSH
> handles transaction and collaboration state alignment and is configured with
> the BPSS (collaboration) and CPA (which can override the transaction
> parameters in the BPSS for a specific bilateral relationship.  If one way a
> BSH is implemented to consume WS-** meta-data then I guess it would be
> configures with WS-CDL (collaboration level) and WS-Policy (transaction
> level)?  In any case the BSH will ideally (one day) present a standardised
> interface (BSI) to the next layer which is the private process execution
> engine (eg a BPM configured with a BPEL).  If I had to choose priorities
> between standardising a MSI or a BSI then I'd choose BSI because that is the
> interface that users will see.  By and large the BSH-MSH interface will be
> buried in vendor product code.

Yes this how I would see it as well. What I am asking about is how to
standardize the interfaces.

I would like to see a standardized BSH-MSH interface just to enable
ebXML endusers to pick implementations. Or if we have today 30 MSH
implementations and maybe 0 BSH you cannot choose from the 30 but you
have to go with one which provides BSH functionalities (I made up the
numbers).

Regards

Sacha

> 
> This is my "understanding" and the way we have implemented.  Perhaps wrong
> but it did all make sense to me at the time :-).
> 
> Regards,
> 
> Steve
> 
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Saturday, 5 February 2005 10:00 AM
> To: Yunker, John
> Cc: Dale Moberg; Monica J. Martin; David Webber (XML); Sacha Schlegel; ebXML
> BP; ebxml-msg@lists.oasis-open.org; ebsoa
> Subject: [ebsoa] Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap
> between MSI and BSI and move on
> 
> John:
> 
> Thanks.  I can now see where the confusion lies.  It appears that the 
> ebXML TA defined BSI as one thing in 1999, then later BPSS defined it as 
> something else.  The official ebXML glossary makes things even more 
> confusing:
> 
> BSI = An ebXML collaboration that is
> conducted by two or more parties each
> using a human or automated business
> service that interprets the documents
> and document envelopes transmitted
> and decides how to (or whether to)
> respond.
> 
> Probably a good idea to fix all of this.
> 
> Duane
> 
> Yunker, John wrote:
> 
> >Concrete itself is an abstract term in this case, or at lease broadly
> applied :-)
> >
> >I agree with the gist of what is stated, but just in case this confuses
> readers about BSI in BPSS:
> >
> >Please note that the BPSS precisely defines the BSI behavior within the
> boundaries of the shared collaboration definition, but does not define its
> technical implementation. 
> >
> >John
> >
> >-----Original Message-----
> >From: Duane Nickull [mailto:dnickull@adobe.com] 
> >Sent: Friday, February 04, 2005 1: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
> >>
> >>
> >> 
> >>
> >>    
> >>
> >
> >  
> >
>