[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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