[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
David,
We have another case of violent agreement.
No, I can't think of a realistic use case with 1000 1-Mbyte messages. The
problem is that I can't think of a way of bounding the number of messages
to buffer once message size and unknown failure modes are factored in.
Providing an option for the sending application to block until the
messaging service has sent the message allows the buffer size issue to be
avoided.
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/19/2000 10:47:38 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>,
ebxml-tp@lists.ebxml.org
Subject: RE: TPA and ebXML Header question
I agree that blocking at the sending end is OK to do, you just shouldn't
have to do it.
I've also just got a new notebook with a 12Gb disk, so this would buffer a
1000 1 megabyte message conversation with no problem. BTW can you think of
a
use case that would involve a 1000 1mb messages??? ;)
David
-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, October 18, 2000 2:54 PM
To: Burdett, David
Cc: Burdett, David; ebxml-tp@lists.ebxml.org;
ebxml-transport@lists.ebxml.org
Subject: RE: TPA and ebXML Header question
Yes, that looks like it would work.
One catch: Your calculation doesn't factor in the message size. 1000
1-kilobyte messages is fine. 1000 1-megabyte messages may be less fine.
Providing the option of blocking at the sending end may be desirable to
avoid the need for huge buffers. It also isn't clear that there is a
realistic way of estimating the retry frequency other than a by a guess. A
lot would have to be known about the possible error modes.
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/18/2000 11:31:30 AM
To: Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
<david.burdett@commerceone.com>
cc: ebxml-tp@lists.ebxml.org, ebxml-transport@lists.ebxml.org
Subject: RE: TPA and ebXML Header question
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