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
>
> -----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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]