[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] Closing the gap between MSI and BSI and move on
Hi John, Comments inline. Am Freitag, den 04.02.2005, 10:22 -0800 schrieb Yunker, John: > Hmmm... I'm a little concerned about where this is going. We are trying to decouple the business execution from the physical software components. Please see comments below. > > >>So what is a specific BSI? > >> > >>o J2EE applications, busses, simple backend application, > >>series of web services, currently íts just about anything ... > >> > >>I can argue contrary that you do not want to give the > >>responsibilities of the BPSS signals to all and everything > >>being part of the BSI. This is the opposite to rip out existing > >>applications or internal data formats. > >> > >>So I see two cases: > >> > >>1) A BSI is anything spread among anything at one party > >>2) A BSI (or BSH) is a specific component (a ebBP business > >>process engine) which takes on the responsibility of the BPSS > >>signals. A component that is build for ebBP´s. > > The above is a fine description of a conceptual BSI, that is a partner exposing business services. OK. > However BPSS is much more explicit in defining the BSI so that partners can truly define and optimize shared business behavior. I do not understand what you mean with optimize. > > A BSI is a partners implementation of the shared definition of business states and actions used to accomplish a business use case. Agree. > > BSI execution uses the current state of the business process (as defined in the neutral collaboration model) to prescribe actions and report the current state of the business process. Agree. > > In the context of the BPSS the business process being managed by the BSI is only the SHARED business process. Agree. To me, shared business process and public business process are synonyms. > > So a BPSS BSI is: > 1) A discrete set of business process states (results of transactions) shared and aligned between partners. > 2) A discrete set of business transactions. > 3) A discrete set of transitions between business transactions. > 4) The rules governing the above. Agree. (I tend to think that the execution of business transaction is OK but I have no experience when using joins, forks, and decisions) > > The MSI supports (and enforces) the BSI through OK here you start to bring together MSI and BSI. > 1) Messages that represent transactions > 2) Signals that align state > 3) Behavior upon receipt/non-receipt of messages and signals > 4) Enforcement of security constraints I guess I agree here, too. Thanks to real world ebMS implementations we feel comfortable to think of a MSI. I think of a MSI as an interface to the ebMS MSH (very symplistic eg sendMessage(), sendSignal(), etc. ). If you have to get specific, again, what is the BSI? I am interested to get down to the implementation of this and for that I need one example of specific BSI. Once I have a specific BSI then we can define an interface between the BSI and MSI. Eg what are the parameters of sendMessage()? conversation ID?, CPA id?, ebBP instance id?, ebBP. Who creates the conversation ID? The MSH or the BSH? Whois responsible to responsible to check the timeToPerform? Again I want to implement against a MSI which is the same for all MSH's. The same should be true the other way round. It is very nice if my MSH also works with any BSI. The ebXML message is the reason we have interoperablity between ebXML Message Service implementations. So we need something similar for BSI and a ebXML Message Service implementation (MSH). Only then we can start to test interoperability between BSI's. I guess I start to repeat myself. > > The MSI can do this either through design time embedding of BSI rules in the MSI, or through communication between the MSI and BSI implementations at run time. This is left to the implementer at this time. > > The set of web services, beans, etc that define the business services are NOT the BSI, they are the business services that the BSI fronts and abstracts. Agree. The set of web serices, beans etc that define the business service is what I call the private business processes. > The BSI is the shared definition of how those business services are EXPOSED to the parties as a defined business process and discrete set of business messages. Also agree. One can ask: what was first? o the private business process? or o the public business process? Probably you will find both: b) Organisations sit together to define their public business processes. Then each party goes home and organizes their own private business processes to participate. c) An organisation provides a service, composed of private business processes. The organisation wants to connect its trading partners. The organisation creates public business processes to allow its trading partners do B2B with the organisation. Another pro for a specific BSI component (say BSH) (ebBP aka BPSS execution instance). A component between MSH and backend application or services: o This BSH can termine time signals because it is the instance monitoring message flow. o This BSH can teremine if a business message is in accordance with the ebBP instance. This is true for incoming and outgoing business messages. (once I was looking at this a bit closer and I remember that it might be tricky if it is the first message of a eBP but I might not have thought that through). Please remember that for this I need an interface between BSH and MSI. Oh yeah I remeber when a backenapplication sends a new business messages, that is the pure payload. Again without metadata ... the BSH would not know what type of business message this payload is. For which trading partner is this payload? Impossible to know without looking into the payload or having that information accompanied the payload document. This BSH still is not in a position to know about Acceptance Acknowledgements (positiv nor negative) but it can handle time signals. Actually, to me the definition of a BSI is so vague, that my world view of a specific BSI (an ebXML business process execution engine implementation having a specific interface with a MSH and having a to be defined interface to backend applications, services, business process execution engines) is likely to be valid ;) The one way or the other a BSI has to communicate with a MSH and vice versa. If we want to have interoperable BSI's and MSH's we need an interface. Regards Sacha > > Thanks, > John > > -----Original Message----- > From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com] > Sent: Friday, February 04, 2005 8:55 AM > To: Dale Moberg; ebXML BP; ebxml-msg@lists.oasis-open.org > Subject: AW: [ebxml-bp] Closing the gap between MSI and BSI and move on > > > Hi Dale, > > So MSI part is as I understand. > > The BSI part becomes a bit vague. Its abstract, its virtual, its logical, all well and good but at one point it has to become specific. > > So what we agree is that whatever the BSI is, it will be responsible for BPSS signals. > > So what is a specific BSI? > > o J2EE applications, busses, simple backend application, series of web services, currently íts just about anything ... > > I can argue contrary that you do not want to give the responsibilities of the BPSS signals to all and everything being part of the BSI. This is the opposite to rip out existing applications or internal data formats. > > So I see two cases: > > 1) A BSI is anything spread among anything at one party > 2) A BSI (or BSH) is a specific component (a ebBP business process engine) which takes on the responsibity of the BPSS signals. A component that is build for ebBP´s. > > With the second case we could close the gap between BSI and MSI. > > But with the second case we still have not integrated with the actual backend applications, services. With this approach we would at least, have a proper ebXML chain consisting of BSI and MSI. > > Following private business processes from too far away it seems to me that private business process engines (such as WSBPEIL) are discussed today as a solution for private business processes. > > If we were at this stage we would still have the gap between the BSI and WSBPEL. That would be the next task. > > To come back to the BPSS signals. If a WSBPEL instance knows to communicate with a BSI and vice verca, a WSBPEL instance would know about BPSS signals, such as Acceptance Acknowledgements. > > So, having a specific BSI (with an interface between BSI and MSI) and an interface between BSI and WSBPEL for example is ONE way to get where we want. > > Regards > > Sacha > > PS: Of course MSH implementations can still be connected straight to their backend applications or service or abstract-virtual BSI ;) as is probably done today. > > ________________________________ > > Von: Dale Moberg > Gesendet: Fr 04.02.2005 08:31 > An: Sacha Schlegel; ebXML BP; ebxml-msg@lists.oasis-open.org > Betreff: RE: [ebxml-bp] Closing the gap between MSI and BSI and move on > > > > Hi Sacha, > > The BSI concept mainly comes from the ebXML architecture document and the BPSS working area. > > The MSI concept was, I think, one that has been worked on from time to time in Messaging and was basically an API for communication between the software component(s) functioning in the MSH role (at a given node) and the software (other middleware or business applications) that needed to communicate with a MSH at that node. [An interface between "levels" of the stack at a node.] Submitting and being notified of message payloads (along with selected metadata concerning that payload), being notified of exception conditions, and so on were the envisioned functions of the MSI API. Matt and others even submitted materials for an API definition and we found that OAG (or was it OMG?) had drawn up some IDL for an API in this area. Messages on this are probably still in the Messaging list archive. [If you go back several years, you will find other contributions. It is a perennial topic.] > > I think that the Messaging TC decided to work on version 3.0 as a higher priority than the API for MSI. That doesn't prevent someone from submitting a draft for TC consideration eventually, though Ian would need to check the process for us in Messaging. I agree with you that someday this needs to get done. At the moment each MSH integration is a customized exercise depending on the deployment environment (EAI or not; if so, what style, etc. etc.) > > The BSI as discussed in BPSS and the early Architecture document is IMO an interface at a specific level of the protocol stack, but an interface between the same stack level but at different nodes. It is a virtual (or logical) interfacing whose actual realization is accomplished by using the supporting layers of the stack to carry out its protocol. Abstractly the BSI is accomplished whenever ebXML message exchange carryies out (via its lower protocol levels) a BusinessTransaction (in the BPSS sense). BSI in BPSS involves the "signals" (both positive and for exceptions) that achieve state alignment (including clear failure states). > > So BSI is somewhat defined. What more do you think needs to be done for it? > > It is true that BSI will be realized by some assignment of responsibilities to software as deployed in some environment. I am not certain that anyone has proposed standardization of its implementation by even saying which roles of software components carry out which BSI related tasks. There are just a whole lot of existing combinations in businesses for these deployment environments, and overall the consensus view has been that standardizing these largely internal configurations would be too controversial to achieve consensus. [A standard which said that businesses had to rip out existing applications or internal data formats or message busses would be probably doomed to sit without any market traction, with at most one large vender supporting it, which would be the vender whose software or platform or language or development IDE followed the standard!] So I am a little dubious that we should try to standardize this area without receiving clear broadly > based requirements and commitments from the end user community. Absent their interest, a basis for consensus in standardization among ISVs is most unlikely. > > > -----Original Message----- > From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com] > Sent: Friday, February 04, 2005 7:32 AM > To: ebXML BP; ebxml-msg@lists.oasis-open.org > Subject: [ebxml-bp] Closing the gap between MSI and BSI and move on > > Hi ebXML Message Service team > Hi ebXML Business Process team > > I suggest to define an interface between > > o MSI and BSI (or MSH and BSH) > > and close that gap in the ebXML spec and move on to the next step, from a ebBP view point, to define an interface between > > o BSI and private business process engines (or BSH and OASIS WSBPEL for example) > > Regards > > Sacha > > ----------------------------- > > MSH = Message Service Handler > BSH = Business Service Handler > MSI = Message Service Interface > BSI = Business Service Interface > WSBPEL = Web Services Business Process Execution Language > > PS: BSH is to ebXML Business Process what MSH is to ebXML Message Service > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]