[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
I think the key point in your example is: where is the buffering (on the receiving side) and resending (on the sending side) being done? Nothing about buffering is prescribed for the Receiving_MSH in the current MS spec, and resending (for a certain number of tries, depending on some parameters) is done in the Sending_MSH. And, using some linearity prediction of reception rates (to set buffer size, etc.) certainly implies more than just awareness of a transport. We'll need to talk in Tokyo about this. BTW, I think Marty is correct that some kind of Service Interface is needed to deal with it, especially with the current MS spec. Jim At 08:31 AM 10/18/2000 -0700, Burdett, David wrote: >I think you can do sequencing without blocking on the RM ACK. In the >following example a message is lost and resent ... > >Msg Seq No 1 ---> Passed to App ><--- Msg Ack Seq no 1 >Msg Seq No 2 ---> Passed to App >Msg Seq No 3 ---> GETS LOST ON THE NETWORK ><--- Msg Ack Seq no 2 >Msg Seq No 4 ---> Buffered ><--- Msg Ack Seq no 4 >Msg Seq No 5 ---> Buffered ><--- Msg Ack Seq no 5 >Msg Seq No 3 ---> RESEND Passed to App > Pass Msg Seq no 4 to APP > Pass Msg Seq no 4 to APP ><--- Msg Ack Seq no 3 > >... and if the transport sends messages out of sequence then you would get >the following variation ... > >Msg Seq No 1 ---> Passed to App ><--- Msg Ack Seq no 1 >Msg Seq No 2 ---> Passed to App >Msg Seq No 3 ---> IS DELAYED ><--- Msg Ack Seq no 2 >Msg Seq No 4 ---> Buffered ><--- Msg Ack Seq no 4 >Msg Seq No 5 ---> Buffered ><--- Msg Ack Seq no 5 > Msg 3 arrives and is Passed to App > Pass Msg Seq no 4 to APP > Pass Msg Seq no 4 to APP ><--- Msg Ack Seq no 3 > >The key point is that if the sender does not get the ack for message 3 then >he will eventually re-send the original message as in the earlier example. > >Also if you know ... >1. The arrival rate of messages and >2. The timeout interval that triggers a resend if an ack is not received >... then you can calculate the likely maximum size of your buffer. So if the >time out interval is, say 1 minute and you are sending two messages a second >and you assume that you have to do two re-tries before the message gets >through then a buffer size of 3 x 120 or around 360 messages would be >required, so make it a 1000 and it should suffice. > >If eventually the recipient fills up their buffer for that conversation then >it can send an error message in response to the lost message and stop >buffering further messages. > >Thoughts? > >David >-----Original Message----- >From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] >Sent: Wednesday, October 18, 2000 7:17 AM >To: Burdett, David >Cc: ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org >Subject: RE: TPA and ebXML Header question > > > >Without blocking on the RM ACK, it is not sufficient to say that sequence >numbers be used in conjunction with RM since a mis-ordering transport layer >could still prevent bounding the number of messages to be stored. > >An alternative to blocking on the RM ACK, which I pointed out somewhere >back in this thread, is to define the API to the messaging service such >that a sending application can block until the messaging service informs >it that the message has been send. This takes care of misordering by the >messaging service with and without RM and misordering by the lower level >transport. > >Historical item: In the early '90s, the designers of the ANSI Fibre >Channel standard discussed this issue endlessly. The endpoint folks (I/O >channels and device controllers) wanted to receive data frames in order but >the frame-switch builders preferred to build misordering switches. >Constructs were added to the end to end architecture to take care of the >ordering problem for the acknowledged-frames (Class 2, for those into Fibre >Channel terminology) but not for unacknowledged-frames (class 3). The >industry then moved toward a loop architecture which inherently keeps the >frames ordered. It still remains to be seen whether they really solved the >ordering problem for frame switches. > >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 >**************************************************************************** >********* > > > >"Burdett, David" <david.burdett@commerceone.com> on 10/17/2000 11:13:07 PM > >To: ebxml-tp@lists.ebxml.org, ebxml-transport@lists.ebxml.org >cc: >Subject: RE: TPA and ebXML Header question > > > >I've been off-line for a while and just catching up ... this is, as several >people have said, an interesting thread. > >My 2c worth ... > >Although it is useful to consider the use cases represented by the various >business scenarios, I think we should focus on what we can document in the >**protocol** with a perspective of whether or not is useful to higher >layers. > >What I think would be a useful service is for the *receiving* MSH to be >able >to make sure that the application it is passing messages onto are delivered >in the correct sequence. This could be used to makethe life of a business >process easier, but it could also (again no rocks please) be used if you >wanted to dis-assemble a large message and send each separately and then >re-construct it at the receiving end. > >However this does imply buffering at the receiving end in order to ensure >that the messages are passed on in the correct sequence. However, without >some sort of "ack" that supports reliable messaging, the receiver has no >way >of informing the sender of messages that messages were lost in transit. > >So, how about us including a "sequence number" in the message header that >has a semantic along the lines of ... > >"The optional Sequence Number identifies the sequence, within the >ConversationId, in which messages received by the To Party SHOULD be >processed. It is set to 1 and is then incremented by 1 for each message >sent. If the To Party cannot process the messages in the specified sequence >then it MUST return and Error Message." > >One question is how many messages should the receiver "buffer" before >giving >up. The receiver cannot keep on buffering messages indefinitely. > >One way around this problem is to recommend that sequencing of messages is >only done in conjunction with reliable messaging. So we could also add to >the spec ... > >"It is recommended that Sequence Number is used in conjunction with a >Delivery Semantic of 'OnceAndOnlyOnce'. If the Delivery Semantic is not >'OnceAndOnlyOnce' then the recipient of the message must either respond >with >an error message with a Severity of: >* "Error" if it does not want to continue, or, >* "Warning" if it does in which case, delivery of messages in the correct >sequence is not guaranteed." > >Thoughts? > >David >PS Trimmed the addresses. > >-----Original Message----- >From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] >Sent: Monday, October 16, 2000 7:56 AM >To: Krishna Sankar >Cc: Moberg, Dale; dick@8760.com; mark.hale@ajubasolutions.com; >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 > > > >(Please forgive the possible repetition. It isn't clear to me that the >following was transmitted the first time.) > >the IBM tpaML proposal has the notion of a conversation, which can be >viewed as a session. This notion includes multiple business processes at >either end as long as each one can be represented by one or more actions >(request/response pairs) within the same 2-party TPA. > >The tpaML conversation is above the level of the messaging service. The >messaging service has only to include the conversation ID in the message >header (as it already does). In the IBM proof of concept prototype (BPF), >the middleware provides a set of application services such as conversation >state tracking, sequencing rules, logging, security services, etc. These >services are the equivalent of the application services layer which people >are starting to discuss in TRP and elsewhere > >Ordered delivery could be provided by the application services layer if the >proper interface constructs are defined between the messaging service and >the application layer. At the sending end, ordering can be accomplished by >the application services layer if it can block until the messaging service >signals that it has sent the previous message (and assuming that a >mis-ordering transport layer is not used). At the receiving end, I see >little that the application services layer can do to maintain ordered >delivery except to buffer up as many messages as required to correct >misordering; this requies that the sending application or application >services layer apply a sequence number to each message. > >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 >**************************************************************************** > >********* > > > >"Krishna Sankar" <ksankar@cisco.com> on 10/14/2000 03:34:21 PM > >To: "Moberg, Dale" <Dale_Moberg@stercomm.com>, <dick@8760.com>, Martin W > Sachs/Watson/IBM@IBMUS, <mark.hale@ajubasolutions.com> >cc: "Christopher Ferris" <chris.ferris@east.sun.com>, 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 > > > >Hi all, > > This thread is getting interesting. > > One point I wish to make is the hypothesis that session could span >multiple >business processes. The business messages (using ack, accept et al) have >the >notion of virtual sessions. But business processes could be related ( and >as >Dale pointed out, this relationship need not even be linear) and would >require some notion of a session to manage those relationships. And yes, I >agree that this topic is not directly a trp issue. > > cheers > > Note : Even the POC retail example has the session notion; send order >is >related to the item alignment. In real life, for example RosettaNet, item >alignment is the PIP2X and manage order is PIP3X - different BPs. Of >course, >we have the pseudo session by persistence (i.e. store the data and then >other BPs can use it) in most cases, but there would be cases where we will >need to have sessions to capture these relationships. > >-----Original Message----- >From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] >Sent: Saturday, October 14, 2000 11:53 AM >To: 'dick@8760.com'; 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 > > >Dick, > >In the original OSI model there was both a presentation and >a session layer between transport and the application layer. While >MIME, security, packaging, routing elements-- as well as XML itself-- >are probably all best regarded as in the presentation layer, >the use case Krishna presented is in the session layer. > >Applications could handle session, if they were newly created to know about >PIPs, choreographics, and the more elaborate forking and joining BPs >that Krishna clearly describes. These "sequencings" are clearly >more elaborate than just a linear sequence and are more like >trees where some of the branches join back up ( DAGs, lattices, >and graphs for the mathematically inclined). > >Anyway, I believe that it is probably good to keep TRP out >of the session layer and I fully support our TRP's >scope constraint. > >Neverthless, ebXML looks like it may need to >consider developing specifications >for session-related functionality for >applications without session logic. >Karsten Riemer at the recent TPA F2F indicated BP >and the metamodel people are going to have BPs >that have the more complex sequencing that Krishna >discusses. Where exactly are ebXML specifications >for the classic session layer under development? > >I think an element is falling through the cracks. > > >Bye >Dale Moberg > > > > > -----Original Message----- > > From: Dick Brooks [mailto:dick@8760.com] > > Sent: Saturday, October 14, 2000 10: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