[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Conversations, or BP alignment with TR&P and Architecture
It is extremely important that we be clear about the distinction between transport level conversation and application level conversation (i.e., business process). Transport level conversation encompasses receipt and processing (i.e., saved, checked, processed) acknowledgement and error messaging. This level of conversation management is currently within the purview of the TR&P specification. Application level conversation definition encompasses the set of message exchanges required to complete a business process. Individual message exchanges within application level conversation require transport level conversation. Application level conversation and control is not within the domain of TR&P. However, the TR&P must recognize in its documentation and examples the necessity of providing support at the transport level for long running application level conversations. These are alternately referred to as "message sets" and "multiple round trip document exchange" in the TR&P Overview and Requirements doc (at the time the TR&P overview & requirements doc was put together, the BP metamodel was not yet complete and therefore required that terminology be created to explain the concepts - the vocabulary should be brought in line with the BP metamodel terminology to avoid confusion). That support takes the form of information like message set ids and transaction ids within the TR&P header specification. The TR&P spec does not, and should not, extend to the specification of *business process* choreography. It simply provides multiple methods of reliable message exchange to the business process conversation manager (some combination of the "Enterprise System" and "Integration System" referred to in the TR&P doc). ========================================================================== Marc Breissinger voice (W): 703-460-2504 Director, Product Strategy - webMethods, Inc. voice (C): 703-989-7689 Email: marcb@webmethods.com We're hiring!!! Email2: breissim@earthlink.net URL: http://www.webmethods.com ========================================================================== > -----Original Message----- > From: owner-ebxml-transport@lists.oasis-open.org > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Bob > Haugen > Sent: Sunday, July 02, 2000 11:54 AM > To: ebXML-transport@lists.oasis-open.org > Subject: FW: Conversations, or BP alignment with TR&P and Architecture > > > I sent the following message to the ebXML-Business Process > list, and (of course) also seek comments from TR&P and > Architecture groups. > > Thanks, > Bob Haugen > > -----Original Message----- > From: Bob Haugen [SMTP:linkage@interaccess.com] > Sent: Saturday, July 01, 2000 7:11 AM > To: 'ebXML-BP@lists.oasis-open.org' > Subject: Conversations, or BP alignment with TR&P and Architecture > > Has anybody discussed alignment of the BP metamodel > with the Transport, Routing & Packaging and Architecture > specifications? > > I just did some reading in the most recent documents for > both groups, focusing on the issue of conversations. By > "conversation", I mean message exchanges consisting > of more than one message, e.g. a long-running Business > Transaction. > > The BP metamodel assumes the need for long-running > conversations. So does TR&P, and (maybe) Architecture. > However, the responsibility for defining the software > that manages these conversations is not clear. > > Practically speaking, long-running conversations require > some software to manage the ongoing state of the conversation > and apply the rules, e.g. Business Transaction Constraints > and Ordering Rules, and possibly manage Duality relationships. > This software could live at both ends of the conversation, > using a shared or duplicated Business Process Definition, > or it could live in a shared Business Transaction processing service, > e.g. an Internet "marketplace". > > ebXML TR&P specifies in diagrams an Integration System > where Business Rules and Document Choreography from > Business Process Modeling are supposed to take place. > However, this Integration System is then declared out-of-scope > for TR&P. > > In the TR&P diagrams, instances of the Integration System > live at both ends of a message exchange. The Integration > Systems have their own private repositories, which can > access a Master Repository. > > The ebXML Architecture documents use these same > diagrams. However, Architecture goes on to propose > an "ebXML Application" at each end of a message > transmission which uses a Business Process model. > Architecture does not mention transaction semantics > or long-running conversations. > > However, transaction semantics are declared to be within > the scope of TR&P, including "support for a session-based > transaction and/or a long term transaction". > > TR&P also wants to support Multiple Round Trip Document > Exchanges: > "A Multiple Round Trip Document Exchange consists of: > 1) a Request Message sent from one Party to a second Party, followed by > 2) a series of Exchange Messages that are exchanged between the > two Parties until finally > 3) the second Party generates and sends a Response Message back > to the first Party. > Examples of Multiple Round Trip Document Exchanges include: > 4) the exchange of messages required to make a payment using > payment method protocols such as [SET] or [Mondex] > 5) the exchange of messages required to negotiate an agreement on > terms and conditions." > > TR&P also has a (simpler) counterpart to the Business Process Definition > hierarchy of the BP metamodel: > "A Service Definition describes a process that can be carried out > by a Party. It consists of either a > Document Exchange or a set of Sub-Services. Each Sub-Service is a > Service in its own right. So, at the > lowest level, all Service Definitions are described in terms of a > Document Exchange. > The dependencies between the Sub-Services in a Service is > described in a Sub-Service Choreography. > An instance of the execution of a Service Definition is called a > Transaction." > > "A Transaction is an instance of the execution of a Service 10 . > Examples of a Transaction include: > 1) a Purchase Transaction that buys a Company Report for $20. It > consists of three Sub-Service > instances: > a) an Offer Service instance to buy the Company Report for $20 > b) a Payment Service instance that accepts a Payment for $20 > using a credit card, and finally > c) a Delivery Service instance that delivers the Company Report > as an HTML web page. > 2) a Buying Service that consists of the following Sub-Services: > a) three Price Negotiation Service instances that negotiate the > price of a Photocopier > b) a Purchase Order Service instance that places the order for > the Photocopier." > > TR&P is also proposing conversation templates (as I have > repeatedly proposed > in BP discussions). > > tpaML, which we considered briefly in Seattle, proposes TPA "objects" > that live at each of a long-running transaction, managing the > conversation. > It appears that tpaML has software that manages conversations. > > My impression in Seattle was that Edifecs/RosettaNet has software > to manage conversations as well. > > Comments? > > Respectfully, > Bob Haugen > > ======================================================================= > = This is ebxml-bp, the general mailing list for the ebXML = > = Business Process project team. The owner of this list is = > = owner-ebxml-bp@oasis-open.org = > = = > = To unsubscribe, send mail to majordomo@lists.oasis-open.org with = > = the following in the body of the message: = > = unsubscribe ebxml-bp = > = If you are subscribed using a different email address, put the = > = address you subscribed with at the end of the line; e.g. = > = unsubscribe ebxml-bp myname@company.com = > ======================================================================= > > > ======================================================================= > = This is ebxml-transport, the general mailing list for the ebXML = > = Transport project team. The owner of this list is = > = owner-ebxml-transport@oasis-open.org = > = = > = To unsubscribe, send mail to majordomo@lists.oasis-open.org with = > = the following in the body of the message: = > = unsubscribe ebxml-transport = > = If you are subscribed using a different email address, put the = > = address you subscribed with at the end of the line; e.g. = > = unsubscribe ebxml-transport myname@company.com = > ======================================================================= ======================================================================= = This is ebxml-transport, the general mailing list for the ebXML = = Transport project team. The owner of this list is = = owner-ebxml-transport@oasis-open.org = = = = To unsubscribe, send mail to majordomo@lists.oasis-open.org with = = the following in the body of the message: = = unsubscribe ebxml-transport = = If you are subscribed using a different email address, put the = = address you subscribed with at the end of the line; e.g. = = unsubscribe ebxml-transport myname@company.com = =======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC