RE: more on the FW: Draft RegRep and TRP transport harmonization

[Jim Hughes <jfh@fs.fujitsu.com>]

As a prelude to discussion in the F2F, I think these conversations are 
*again* making the requirements more complex than necessary and will impede 
progress. If there are BPs that require *BP level* reliability on a 
synchronous transport, then let's put something into the TPA so that the BP 
can ask for this level of functionality.

As a completely separate discussion, having a Messaging Service Handler use 
different algorithms based on the Transport protocols (synch, asynch, 
MQseries, whatever) is possible but I'm afraid unspecable in the short 
term. In any event, we need to again make sure the requirements are clearly 
specified and agreed to before we go down implementation discussions...

Jim

At 12:01 PM 9/22/2000 -0700, Burdett, David wrote:
>Nick/Rik
>
>I think this is an issue to resolve next week at the F2F.
>
>But to sum up I think that:
>1. There are some valid business applications and software environments
>(e.g. client/server) that demand both reliable messaging and a synchronous
>response as in the the use case I described.
>2. If we accept that reliable messaging over a synchronous transport
>protocol is a requirement (do we?) then I can't see any option other than
>combining the business response and the message ack in the same message (is
>there an alternative?)
>3. I see synchronous and asynchronous responses to a message as valid
>business alternatives from which an application designer should be able to
>choose - we shouldn't force them to work only one way (as SOAP does and we
>*might* do).
>4. I can't see why asynch and synch reliable messaging should be handled in
>a fundamentally different way and therefore we should plan support for both
>now. I think my earlier emails showed that this was straight forward.
>
>Best wishes and see y'all next week ...
>
>David
>
>-----Original Message-----
>From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
>Sent: Thursday, September 21, 2000 6:27 PM
>To: Burdett, David
>Cc: Ebxml Transport
>Subject: RE: more on the FW: Draft RegRep and TRP transport
>harmonization
>
>
>At 10:42 PM 9/20/2000 -0700, Burdett, David wrote:
> >Nick
> >
> >I think there is a real need for reliable synchronous responses as I
> >described in an earlier email. The essentials of the case was where you
>have
> >a SME using something like Quickbooks, that wants to use HTTP to call a
> >remote service to do a payment reliably. It doesn't have an HTTP server so
> >it HAS to get the response from the payment service on the HTTP Response.
>
>Actually I felt the use case you posted was assembled such that there could
>have only been a single answer to the scenario you presented! Be that as it
>may. I don't think we disagree on the need for sync responses. Where I
>think we part company is in jumbling transport level responses, MS level
>responses, and Business level responses. I'm just not convinced that sync
>or async behavior at the network transport layer should drive the
>programming model at the business application layer.
>
>Now I know in the most trivial of "client/Server" style interactions all of
>these layering issues can be ignored and one can reduce TRP into a
>monolithic piece of code. IMHO, once we think through ebXML RM & MS in the
>context of a consistent application programming model then my contention is
>that ebXML TRP is more than yet another way of doing Client/Server
>programming.  I don't think ebXML business components should have to be
>re-written depending on what type of communication infrastructure they
>happen to be deployed on at any given time.
>
>Nick