[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
Marty wrote............
>The messaging service should not have to know anything about the
sequencing
>requirements of the application. The question is only whether the
>messaging service can provide a (possibly optional) valuable service to
the
>application by maintaining ordered delivery. For an application using
>one-way messages (see subsequent posting for example) and needing ordered
>delivery, providing ordered delivery in the messaging service avoids the
....................
I believe that an application using one-way messages by definition does not
need ordered
or reliable delivery from my view of using a "Messaging Service".
(Also, All one-way calls at the app level should not expect a
business-document return.)
(hold the rocks please, but...)
In CORBA, the issue of RM on oneway calls is addressed by the use of Event
Services,
which provides reliablity on non blocking calls. As extensions to this base
service,
Priority functions, etc, are used to support ordering, etc. This is part of
the
Architecture on where QOS is intended.
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
Martin W Sachs/Watson/IBM@IBMUS on 10/16/2000 09:01:51 AM
To: Rik Drummond <rvd2@worldnet.att.net>
cc: ebxml-tp@lists.ebxml.org, ebxml-transport@lists.ebxml.org
Subject: RE: TPA and ebXML Header question
The messaging service should not have to know anything about the sequencing
requirements of the application. The question is only whether the
messaging service can provide a (possibly optional) valuable service to the
application by maintaining ordered delivery. For an application using
one-way messages (see subsequent posting for example) and needing ordered
delivery, providing ordered delivery in the messaging service avoids the
need for the application services layer to buffer a (possibly) large number
of sequence-numbered messages in order to correct any mis-ordering before
passing them to the application.
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
*************************************************************************************
Rik Drummond <rvd2@worldnet.att.net> on 10/14/2000 01:45:14 AM
To:
cc: ebxml-tp@lists.ebxml.org, ebxml-transport@lists.ebxml.org
Subject: RE: TPA and ebXML Header question
i still do not see that the transport has to know a whole lot about the
message sequencing in the application... maybe i am dense.....
-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Friday, October 13, 2000 3: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