[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
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: 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. 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 >> >> >> >> >> >> > > > -- *********** 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 *********** --- [This E-mail scanned for viruses by IntaServe - MailGuardian Service at http://www.intaserve.com]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]