[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
Dick, I was not talking about "managing" application state machine by the messaging layer nor can we expect a message layer to look "up" and see who's there. So the "scope" has not changed. Anyway, the message layer is payload agnostic and even if it understands the payload, the payload could be encrypted. My examples just illustrate the sequencing problem. Either the application or for that matter any layer above the messaging layer can assume sequencing and then proceed from there. Or it can assume a UDP like paradigm and start doing extra work to handle that situation. Just to clarify, I think the issue was about applications which can handle mis-ordering, can live without blocking and applications which cannot handle the mis-ordering will have to do blocking until RM ack. Mark's point was how do we handle a set of one-way messages which are also order sensitive and I thought of a couple of real life examples to amplify his ideas. cheers -----Original Message----- From: Dick Brooks [mailto:dick@8760.com] Sent: Saturday, October 14, 2000 7:08 AM To: Krishna Sankar; Martin W Sachs/Watson/IBM; mark.hale@ajubasolutions.com Cc: Christopher Ferris; Scott Hinkelman/Austin/IBM; Bob Haugen; David RR Webber; Zvi Bruckner; ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org Subject: RE: TPA and ebXML Header question Krishna, The scenario you describe is the management of the "application state machine". The TR&P group has discussed the "scope" of state management and has determined that application state management belongs in the application, not in the Messaging Service. The Messaging Service must provide "facilities" to assist the application layer in managing its state machine (e.g. context variables that are carried by the ebXML header and passed thru to applications), but not manage the application state machine. The RM spec defines much of what the TR&P group considers "transport state machine management". Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions > -----Original Message----- > From: Krishna Sankar [mailto:ksankar@cisco.com] > Sent: Saturday, October 14, 2000 3:20 AM > To: Martin W Sachs/Watson/IBM; mark.hale@ajubasolutions.com > Cc: Christopher Ferris; Scott Hinkelman/Austin/IBM; Bob Haugen; David RR > Webber; Zvi Bruckner; ebxml-tp@lists.ebxml.org; > ebxml-transport@lists.ebxml.org > Subject: RE: TPA and ebXML Header question > > > List-Unsubscribe: > <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe> > List-Archive: <http://lists.ebxml.org/archives/ebxml-transport> > List-Help: <http://lists.ebxml.org/doc/email-manage.html>, > <mailto:ebxml-transport-request@lists.ebxml.org?body=help> > > Hi all, > > We can think of many business scenarios which needs sequencing. > > One such example is the capturing state transitions of a > process e.g.. > order status in the case of a heavy equipment manufacturer and > it's agents: > > Assume orders go thru "recvd", "scheduled", "in mfg", > "ready to ship" and > "shipped". Assume the manufacturer captures these states and exchange > messages across an ebXML network to it's agents. Now if these > states trigger > work flow processes at the agents' end, sequencing is important. > For example > a "ready to ship" might invoke (at the agent's side) a request for > preparation for goods receiving (example prepare customs papers, book > shipping containers) and a "shipped" status could trigger activate a firm > commitment on the containers (booked by the earlier state) > > The systems at the agents end has no way of controlling > sequencing ! It has > to be guaranteed by the sending side and/or the messaging system. If the > agent receives out of sequence messages, for example a "shipped" message > before a "ready to ship" message, would cause problems. > > Another example is that of exchanging prices from a seller > to a buyer. A > seller might change prices many times and if the messages are not > sequenced, > the buyer would end up getting the prices in a random order ! And the > problem here is that the buyer has no way of controlling or knowing the > sequences ! > > In the above examples, without RM, we will not be able to guarantee > anything and that is not acceptable. With RM, we also face the need to > guarantee the sequencing ! It would be nice if the messaging > guarantees the > sequencing so that the business processes need not worry about > this issue. A > counter point is that, in a distributed system, which consists of many > components (e.g. servers) and multiple modes of interaction (e.g.. > SMTP,HTTP...), we cannot guarantee who might generate messages and so > sequencing is still a business process issue. > > I know that B2B products (e.g.. from WebMethods and > Netfish) face this > issue. Any idea how they are handling this ? > > cheers > > -----Original Message----- > From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] > Sent: Friday, October 13, 2000 3:35 PM > To: mark.hale@ajubasolutions.com > Cc: Christopher Ferris; Scott Hinkelman/Austin/IBM; Bob Haugen; David RR > Webber; Zvi Bruckner; ebxml-tp@lists.ebxml.org; > ebxml-transport@lists.ebxml.org > Subject: RE: TPA and ebXML Header question > > > > OK, we have possible scenarios for which the business process is not in a > position to guarantee ordering except by applying a sequence number and > buffering as many messages as necessary to correct misordering (I > mis-spoke > before when I said that it cannot maintain order without business level > responses). > > Now, I had been initially concerned about ordering because RM's recovery > procedure will get messages out of order if blocking is not in force. I > have been assuming, without thinking about it, that if RM is not in use, > the messaging service will send messages in order on a given logical > channel. Is it valid to assume that without RM, the messaging > service will > in fact maintain order at its level? If not, should it? If > blocking is an > option with RM, then an application which needs ordering without > application-level responses could request RM with blocking to maintain > order. > > Of course if the underlying transport misorders (SMTP?), then all bets are > off. > > Regards, > Marty > > ****************************************************************** > ********** > ********* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > ****************************************************************** > ********** > ********* > > > > "Mark Hale" <mark.hale@ajubasolutions.com> on 10/13/2000 04:52:47 PM > > Please respond to <mark.hale@ajubasolutions.com> > > To: Martin W Sachs/Watson/IBM@IBMUS, "Christopher Ferris" > <chris.ferris@east.sun.com> > cc: Scott Hinkelman/Austin/IBM@IBMUS, "Bob Haugen" > <linkage@interaccess.com>, "David RR Webber" > <Gnosis_@compuserve.com>, "Zvi Bruckner" <zvi.b@sapiens.com>, > <ebxml-tp@lists.ebxml.org>, <ebxml-transport@lists.ebxml.org> > Subject: RE: TPA and ebXML Header question > > > > > The problem arises if the application involves a series of one-way > > messages, required to stay in order but with no business-level response. > > There is no way for the business process level to enforce ordering > because > > the sender of a message doesn't know when it is safe to send the next > one. > > The RM component of the messaging sequence can enforce ordering > > by blocking > > on each message in a logical channel until it receives the RM > > Acknowledgment. That's why I suggested that blocking in the RM > > function be > > controlled by a tag in the CPA and CPP. The blocking would be effective > > only for the particular TPA. > > > > Is this a realistic case? I don't know. Can anyone tell us? > > I can see the following scenarios where one way messages with blocking may > be desired: > > - Exchanges where one partner may be a high-throughput hub coalescing > ordered data from subsidiaries > - Omni-directional peer battlefield simulation (HLA work from DoD) > > Thanks, > > Mark > > > > > -----Original Message----- > > From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] > > Sent: Friday, October 13, 2000 1:27 PM > > To: Christopher Ferris > > Cc: Scott Hinkelman/Austin/IBM; Bob Haugen; David RR Webber; Zvi > > Bruckner; ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org > > Subject: Re: TPA and ebXML Header question > > > > > > > > Chris, > > > > I don't believe that pushing ordered messaging up to the > business process > > level is the answer. Consider: > > > > If all the messages at the business process level are request-response, > > with only one message at a time, as in tpaML with its sequencing rules, > > then it doesn't matter what the messaging service does because the > > combination of request-response and one-at-a-time sequencing will > preserve > > order within a conversation. > > > > The problem arises if the application involves a series of one-way > > messages, required to stay in order but with no business-level response. > > There is no way for the business process level to enforce ordering > because > > the sender of a message doesn't know when it is safe to send the next > one. > > The RM component of the messaging sequence can enforce ordering > > by blocking > > on each message in a logical channel until it receives the RM > > Acknowledgment. That's why I suggested that blocking in the RM > > function be > > controlled by a tag in the CPA and CPP. The blocking would be effective > > only for the particular TPA. > > > > Is this a realistic case? I don't know. Can anyone tell us? > > > > Regards, > > Marty > > > > ****************************************************************** > > ******************* > > > > Martin W. Sachs > > IBM T. J. Watson Research Center > > P. O. B. 704 > > Yorktown Hts, NY 10598 > > 914-784-7287; IBM tie line 863-7287 > > Notes address: Martin W Sachs/Watson/IBM > > Internet address: mwsachs @ us.ibm.com > > ****************************************************************** > > ******************* > > > > > > > > Christopher Ferris <chris.ferris@east.sun.com> on 10/04/2000 10:51:10 AM > > > > To: Martin W Sachs/Watson/IBM@IBMUS > > cc: Scott Hinkelman/Austin/IBM@IBMUS, Bob Haugen > > <linkage@interaccess.com>, David RR Webber > <Gnosis_@compuserve.com>, > > Zvi Bruckner <zvi.b@sapiens.com>, "ebxml-tp@lists.ebxml.org" > > <ebxml-tp@lists.ebxml.org>, "ebxml-transport@lists.ebxml.org" > > <ebxml-transport@lists.ebxml.org> > > Subject: Re: TPA and ebXML Header question > > > > > > > > A minor tweak below, otherwise, I concur. > > > > Chris > > > > Martin W Sachs/Watson/IBM wrote: > > > > > > Summing up what I think I have seen on MS ACKS (composite of > > opinion, not > > > necessarily consensus): > > > > > > MS ACKs are needed (this is essential to reliable messaging) > > > > > > The messaging service should not require blocking of a logical channel > > > until an MS ACK is received. > > > > > > Blocking may in any case be enforced by business-level responses. > > > > > > Partner Profile and Partner Agreement should specify whether blocking > is > > ^^^^^^^ > > s/b sequencing IMHO. That is to say that at the business process level > > (not conversation) the sequence of messages might be enforced/required. > > > > > required. > > > Note: in my opinion, this tag would refer to the messaging service > > > ACKs, not the business process. Blocking at the business process > > level > > > would be specified in the business process model and > manifest itself > > in > > > the PA in the response definitions and sequencing rules or whatever > > > equivalent we come up with. > > > > > > New point: For many applications, the latency effects of > > blocking at the > > > MS level would be substantially reduced if what we are calling a > logical > > > channel is really a conversation. A good implementation would provide > > for > > > many concurrent conversations even within a single PA. Thus when the > MS > > > blocks until receiving an ACK it would only affect the conversation of > > > which the message and ACK are a part. > > > > > > Regards, > > > Marty > > > > > > > > ****************************************************************** > > ******************* > > > > > > > > Martin W. Sachs > > > IBM T. J. Watson Research Center > > > P. O. B. 704 > > > Yorktown Hts, NY 10598 > > > 914-784-7287; IBM tie line 863-7287 > > > Notes address: Martin W Sachs/Watson/IBM > > > Internet address: mwsachs @ us.ibm.com > > > > > ****************************************************************** > > ******************* > > > > > > > > Scott Hinkelman/Austin/IBM@IBMUS on 10/04/2000 10:17:01 AM > > > > > > To: Bob Haugen <linkage@interaccess.com> > > > cc: Martin W Sachs/Watson/IBM@IBMUS, David RR Webber > > > <Gnosis_@compuserve.com>, Zvi Bruckner <zvi.b@sapiens.com>, > > > "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>, > > > "ebxml-transport@lists.ebxml.org" > > <ebxml-transport@lists.ebxml.org> > > > Subject: RE: TPA and ebXML Header question > > > > > > It is fine if a specific business process utilizes business > level acks. > > > A robust ms also needs ms level acks. > > > There is a need for both. > > > > > > Scott Hinkelman, Senior Software Engineer > > > XML Industry Enablement > > > IBM e-business Standards Strategy > > > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) > > > srh@us.ibm.com, Fax: 512-838-1074 > > > > > > Bob Haugen <linkage@interaccess.com> on 10/03/2000 07:14:05 PM > > > > > > To: Martin W Sachs/Watson/IBM@IBMUS, David RR Webber > > > <Gnosis_@compuserve.com> > > > cc: Zvi Bruckner <zvi.b@sapiens.com>, "ebxml-tp@lists.ebxml.org" > > > <ebxml-tp@lists.ebxml.org>, "ebxml-transport@lists.ebxml.org" > > > <ebxml-transport@lists.ebxml.org> > > > Subject: RE: TPA and ebXML Header question > > > > > > Marty and David, > > > > > > All of the business aspects of document processing, > > > including what kinds of acks are expected, are defined > > > by the Commercial Transaction patterns that are part > > > of the BP Collaboration Metamodel now (finally) > > > posted on the BP work page at: > > > http://www.ebxml.org/project_teams/business_process/wip/index.html > > > > > > (They are actually pretty much the same as RosettaNet, > > > so the POC vendors should know how to handle them.) > > > > > > -Bob Haugen > > > > > > -----Original Message----- > > > From: Martin W Sachs/Watson/IBM [SMTP:mwsachs@us.ibm.com] > > > Sent: Tuesday, October 03, 2000 6:13 PM > > > To: David RR Webber > > > Cc: Zvi Bruckner; ebxml-tp@lists.ebxml.org; > > > ebxml-transport@lists.ebxml.org > > > Subject: Re: TPA and ebXML Header question > > > > > > DW, > > > > > > Isn't the confirm you are talking about part of the business > > process? It > > > seems to me that you want the business process to say "I got > it" rather > > > than having the messaging service say "I was able to parse it OK and > > passed > > > it on to the business process but I it isn't my job to know if the > > business > > > process actually got it or fumbled the ball." > > > > > > Regards, > > > Marty > > > > > > > > ****************************************************************** > > ******************* > > > > > > > > Martin W. Sachs > > > IBM T. J. Watson Research Center > > > P. O. B. 704 > > > Yorktown Hts, NY 10598 > > > 914-784-7287; IBM tie line 863-7287 > > > Notes address: Martin W Sachs/Watson/IBM > > > Internet address: mwsachs @ us.ibm.com > > > > > ****************************************************************** > > ******************* > > > > > > > > David RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 10/03/2000 > > > 06:46:02 PM > > > > > > To: Martin W Sachs/Watson/IBM@IBMUS > > > cc: Zvi Bruckner <zvi.b@sapiens.com>, ebxml-tp@lists.ebxml.org, > > > ebxml-transport@lists.ebxml.org > > > Subject: Re: TPA and ebXML Header question > > > > > > Message text written by Martin W Sachs/Watson/IBM > > > >I believe there is a strong case for an optimistic > > > protocol: send only "checked not ok" and let the business-level > response > > > imply that the message was delivered to the application with no error. > > > > > > Regards, > > > Marty< > > > > > > >>>>>>>>>>>>> > > > > > > Marty - this will depend on the business workflow use case. Some > > > will require an explicit confirm - before proceeding to the next step. > > > > > > We should support both models - but default to > > > 'delivery accepted without confirm'. > > > > > > DW. > > > > -- > > _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect > > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 > > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM > > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 > > _/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903 > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC