OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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>
begin:vcard 
n:Green;Alastair J.
tel;cell:+44 795-841 2107
tel;fax:+44 207-670 1785
tel;work:+44 207-670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
adr:;;13 Austin Friars;London;;EC2N 2JX;England
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
fn:Alastair J. Green
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC