bt-spec message

Subject: Re: [bt-spec] Messaging issues

From: Alastair Green <alastair.green@choreology.com>
To: Pal Takacsi-Nagy <pal.takacsi@bea.com>
Date: Wed, 24 Oct 2001 22:45:44 +0100

Pal, Jim, Alex:

I've been getting a bit of light relief from the spec (you'll get that next tonight!), by discussing this RPC issue with Alex. What follows is just my view, (Alex is not responsible, haven't had a chance to talk to Peter).

Application RPCs and protocol RPCs

First, my comments are about using RPCs for protocol messages sent from BTP actor to BTP actor. I assume that applications are of course going to use SOAP RPCs, and that our header elements (<btp:messages>) will happily hitch a lift in both directions. The question seems to be whether implementers will be able to use RPCs interoperably for the communication of protocol messages between, e.g. Coordinators and Inferiors.

SOAP RPC conventions

I am taking off from a fundamental point that Alex has made to me, which illuminated the whole discussion, at least for me.

A SOAP envelope observing RPC conventions might look this:

<SOAP-ENV:Envelope>
    <SOAP-ENV:Body>
        <tns:aMethod xmlns:tns="TargetNamespaceURI">
            <AnArgument > ... </AnArgument>
            <AnotherArgument ... </AnotherArgument>
        </tns:aMethod>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Which implies:

dispatch "aMethod" on the target identified by "TargetNamespaceURI", with arguments "AnArgument", "AnotherArgument".

A BTP message (protocol actor to protocol actor) looks like this:

<SOAP-ENV:Envelope>
    <SOAP-ENV:Body>
        <btp:messages xmlns:btp="urn:oasis:names:tc:BTP:xml">
            <btp:begin>
               <btp:context> ... </btp:context> ...
            </btp:begin>
        </btp:messages>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Which could imply to a SOAP processor:

dispatch "messages" on the target identified by "urn:oasis:names:tc:BTP:xml", with one argument of complex type, called "begin".

With this in mind, I had the following thoughts --

Using SOAP documents (one way)

Pal's alternatives 1 and 2.

SOAP envelope out, empty SOAP envelope back. Is this simply convention, or is there a good reason to do this (such as immaturity of SOAP/WSDL toolkits)? If it is convention then I'm not arguing. When in Rome ... If it is driven by immaturity or incapacity in current implementations of another standard then I'd say we should support it, but with a note that we look forward to its deprecation.

SOAP envelope out, HTTP ack back seems like the correct way of doing SOAP document over HTTP (one ways, asynchronous).

Using SOAP RPC

There are three good arguments for using SOAP RPC. One is that it is efficient (use the inevitable HTTP ack to do some real work). Second is to get round the problem of deaf clients (systems that can't listen for inbound messages, but can only receive them as responses). Third is to accomodate practical difficulties with existing toolkits that do RPC well, but handle oneways badly or not at all.

There is a less convincing argument, which is the "natural request-response" nature of BTP as a protocol. I'd like to come back to that (see "Natural request-response").

SOAP RPC with one operation, messages in, messages out

I suspect that the current SOAP binding that can be used with SOAP RPC, with a minor tweak. I like this solution because it keeps a single SOAP binding, which is really desirable for interoperation and simplicity. It also involves less work.

The basic concept is: have a single RPC operation, which accepts a <btp:messages> as its one input argument, and sends a <btp:messages> back as its one output argument.

If an implementation wants to send out BEGIN and await BEGUN (or a FAULT) then it can do so. If it wants to send out PREPARE and await PREPARED (or CANCELLED or FAULT) then it can do so. And so on.

The arguments are singular in each direction. This avoids any attempt to map to variable-length argument lists in the procedural language mapping, which is going to be troublesome. For this to be achieved we need the tweak:

<SOAP-ENV:Envelope>
    <SOAP-ENV:Body>
        <btp:transmission xmlns:btp="urn:oasis:names:tc:BTP:xml">
                <btp:messages>
                <btp:begin>
                   <btp:context> ... </btp:context> ...
                </btp:begin>
                </btp:messages>
            <btp:transmission>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The argument becomes <btp:messages> on an operation called transmission.

By convention the response becomes:

<SOAP-ENV:Envelope>
    <SOAP-ENV:Body>
        <btp:transmissionResponse xmlns:btp="urn:oasis:names:tc:BTP:xml">
                <btp:messages>
                <btp:begun>
                   <btp:context> ... </btp:context> ...
                </btp:begun>
                </btp:messages>
            <btp:transmissionResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

If we don't like that (it involves specifying two possible names for the same functional element) then we could violate the convention and make the "response" have the same name as the request (just transmission). As this is a single remote operation, and each implementation will have to implement it zero or one times, this is not onerous (it might involve a hand edit of generated code for one WSDL definition, for example).

"Natural request-response"

My worries on this go back to my discomfort with Savas' push for the use of WSDL in the spec. Here's how I've thought about the problem. I'm going to use CORBA IDL to express myself, because it's compact, like Java, and it's familiar to me!

I'm going to assume that we must use output arguments, and not return types, because SOAP doesn't distinguish return values from arguments output on the parameter list.

Intuitively, a la OTS, we have

void begin (out Begun begun);

void prepare (out Prepared prepared);
void prepare (out Cancelled cancelled);

    void requestConfirm (out Confirmed confirmed);
    void requestConfirm (out Cancelled cancelled);
    void requestConfirm (out Hazard hazard);

etc, etc.

In OTS they bundle up these multiple possible return values into enums (analogous to schemas that allow choices, I guess), and so we see things like:

void prepare (out Vote vote);
void requestConfirm (out Outcome outcome);

Once we've started down this route we end up with new, special schemas which allow constrained choices (<btp:vote> -- a specialization of <btp:messages> that can only contain <btp:prepared> and <btp:cancelled> and <btp:fault>). Or we resist that conclusion, and stick with <btp:messages>, tending towards:

    void begin (out Messages);
    void prepare (out Messages);
    void requestConfirm (out Messages messages);

which is a half-way house back to the simple, general RPC

void tranmission (in Messages inboundMessages, out outboundMessages).

which I favour.

As an exercise for the reader, consider the problem of compounding of messages (which is unrestricted within the scope of <btp:messages>) if we have specialized collections.

API versus interop protocol

The "request-response" view of BTP is actually more natural and appropriate to an API. And for a language like Java we might might extensive use of exceptions, which would take the thing further and further away from the actual message flow/encoding being used underneath the covers. I also believe that the independence of BTP from underlying carrier protocol, its ability to operate asynchronously, and without need for RR is a great strength which we should not de-emphasize. In any event, keeping it simple is a good motto, and the changes that my proposal would induce are very restricted. Finally, the problem is an implementation one, not an end-user one.

Deaf clients

The last point I want to make is on the idea of deaf clients, which Bill Pope has raised a couple of times. This is a very legitimate issue: it always arises in distributed transaction implementations. They can talk but they can't listen (no, not a self-reference).

If we support a means of RPC as suggested then we are half-way to solving the problem. There is a protocol-level issue, however, and not just a binding problem. Failure recovery involves spontaneity: the inferiors have to contact superiors to get replays/replay their status (via INFERIOR_STATE in our case). If the inferior cannot talk to the superior then it cannot know if the superior is still there, or has gone away. It may therefore end up waiting for ever, when it should cancel. (If the superior is there then it should eventually send SUPERIOR_STATE downwards, and may receive one of several messages back in return.) This isn't insuperable but there is a risk of unknown contradictions (heuristics) if the inferior uses a timeout to escape. I may be missing something here, but I think that's about the extent of the problem.

Alastair

Pal Takacsi-Nagy wrote:

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>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

begin:vcard 
n:Green;Alastair
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
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard

References:
- RE: [bt-spec] Messaging issues
  - From: Pal Takacsi-Nagy <pal.takacsi@bea.com>