[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
David, I think this opens an interesting topic. I assume that when you mention "Service Interface" you refer to the thing called "Business Service Interface" that is discussed in a parallel thread. If not, please forgive my comments here ! The interest I see is in the fact that, as described here, the MS should in some way be stateful. Now, it makes sense in my opinion that a reliable MS provides such a feature. But, I think also that not all the behaviour of the sender/receiver can be expressed in terms of the Messaging Service (for this I can point you to the thread on the Business Service Interface). So, we could end-up by having two separate ways for managing the state, one which is "technically bound" and one which is more "business bound"... Does this make sense? One more thing. I do not think that it is good for the MS to depend on information in the TPA. The MS should exist, in my opinion, "independently" of the TPA, just as a way to move messages around. /Stefano > -----Original Message----- > From: Burdett, David [mailto:david.burdett@commerceone.com] > Sent: Wednesday, October 25, 2000 12:32 AM > To: 'Jim Hughes'; Transport Work Group > Cc: ebxml-tp@lists.ebxml.org > Subject: RE: TPA and ebXML Header question > > > Jim > > I agree it will be a good idea to talk about this in Tokyo. My opinion is > that you can express behavior of the sender and receiver of a message > without having to define a Service Interface. For example you could say > something like ... > > ================== > If Delivery Semantics is "OnceAndOnlyOnce" then, unless a Data > Communications Protocol is being used that provides equivalent message > delivery reliability, the following behavior should be followed: > 1. The Sender of a message should re-send the identical message if no > acknowledgement to the message is received > 2. The Recipient of a message should check to see if a duplicate > message has > been received before. If it has then the previous response to the message > should be sent, if it has not then the message should be passed > to whatever > applicaiton needs to process it. > > In the above, several parameters are required to control the > behavior of the > sedner and receiver of the message. These parameters are: > 1. The delay between the sending of an original message and its resending > 2. The number of times a message is re-sent before a sender "gives up" > 3. The action to take if a message cannot be sent > 4. The length of time the recipient of a message retains message-ids and > replies to messages for duplicate checking purposes. > > These parameters are determined either from: > a) the CPA that has been agreed between the sender and receiver > b) the Party Profile of the recipient, or > c) the default paramter value for ebXML, this is indicated by a > CPA profile > of "ebXML:cpa1" > ================== > > The key point is you don't need to specify a Service Interface - let's > discuss in Tokyo > > David > > > -----Original Message----- > From: Jim Hughes [mailto:jfh@fs.fujitsu.com] > Sent: Tuesday, October 24, 2000 2:21 PM > To: Transport Work Group > Cc: ebxml-tp@lists.ebxml.org > 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