RE: [bt-spec] Messaging issues

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

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>
>