OASIS ebXML Messaging Services TC

Back to discussions
Expand all | Collapse all

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

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

    Posted 02-08-2005 09:01 
     MHonArc v2.5.0b2 -->


















    ebxml-msg 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 thegap between MSI and BSI and move on
    







    



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


Related Content