RE: [bt-spec] Messaging issues

[Pal Takacsi-Nagy <pal.takacsi@bea.com>]

According to my recollection most of the BTP messages pair up as request
response: BEGIN/BEGUN. ENROL/ENROLED etc.
So allowing an RPC style binding seems natural to me.

Pal

> -----Original Message-----
> From: Alastair Green [mailto:alastair.green@choreology.com]
> Sent: Wednesday, October 24, 2001 12:33 AM
> To: Pal Takacsi-Nagy
> Cc: alex@ceponkus.org; bt-spec@lists.oasis-open.org
> Subject: Re: [bt-spec] Messaging issues
>
>
> Pal, Alex:
>
> I believe a separate phone meeting of the messaging sub-group
> would be in order.
> I have some related issues. How prevalent is "oneway" support in
> actual SOAP
> toolkits today? If we allow true RPC (Alternative 1) then we end
> up with some
> natural pairings, but with potential issues if the sender cannot actually
> receive spontaneous inbound messages (is not a listener). In
> particular, if a
> superior, coordinator cannot listen, and relies on RPC for
> inbound responses,
> then failure recovery is affected. The inferior cannot probe its
> superior after
> failure to stimulate replays, and cannot replay "responses".
>
> It's worth noting that BTP does not have a strict
> request-response model for its
> protocol messages, and that to introduce that would be a wholesale change.
>
> I say a separate meeting, because I think we know what the (full)
> agenda of
> Friday's meeting is going to be.
>
> Alastair
>
> Pal Takacsi-Nagy wrote:
>
> > I would propose an approach, where we allow 3 kinds of bindings:
> >
> > Alternative 1:
> >
> > sender --> HTTP req + SOAP + BTP "req" --> receiver
> > sender <-- HTTP res + SOAP + BTP "res" <-- receiver
> >
> > Alternative 2:
> >
> > sender --> HTTP req + SOAP + BTP "req" --> receiver
> > sender <-- HTTP res + SOAP (empty)  <-- receiver
> >
> > sender <-- HTTP req + SOAP + BTP "res" <-- receiver
> > sender --> HTTP res + SOAP (empty)  --> receiver
> >
> > Alternative 3:
> >
> > sender --> HTTP req + SOAP + BTP "req" --> receiver
> > sender <-- HTTP res 200  <-- receiver
> >
> > sender <-- HTTP req + SOAP + BTP "res" <-- receiver
> > sender --> HTTP res 200  --> receiver
> >
> > Pal
> >
> > P.S. Notice I did not use inferior/superior -:)
> >
> > > -----Original Message-----
> > > From: Alex Ceponkus [mailto:alex@ceponkus.org]
> > > Sent: Tuesday, October 23, 2001 4:06 PM
> > > To: bt-spec@lists.oasis-open.org
> > > Subject: [bt-spec] Messaging issues
> > >
> > >
> > > BTPers,
> > >
> > > I have been looking over the messaging portion of the spec and have a
> > > concern that might need discussion.
> > >
> > > In the case of the SOAP over HTTP binding, the SOAP messages are
> > > modeled as
> > > one-way messages, but the underlying transport (HTTP) is
> request-response.
> > > As it stands right now, a message gets sent (say a BEGIN) and
> then nothing
> > > at the SOAP layer gets returned, just an HTTP 200 signifying
> that the SOAP
> > > message was received.  We are currently using an asynch messaging
> > > model, so
> > > the response message (the BEGUN) will be sent with a new
> connection at a
> > > later time.  Here's my concern: I haven't seen too many existing SOAP
> > > implementations that behave this way (soap message over http
> request, http
> > > only response.)  Typically, a SOAP message with an empty Body
> is returned.
> > > Are there any objections to returning an empty soap message
> for the soap
> > > over http binding?
> > >
> > > Alex
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>