OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC