The SOAP and other bindings

[Alastair Green <alastair.green@choreology.com>]

I've been thinking about bindings, defined and undefined.

My thoughts on two topics follow:

TOPIC 1: SOAP binding

We've ended up always using SOAP because SOAP has an Envelope, Header and Body. We do not use SOAP encodings, we do not use SOAP actions, we do not use SOAP RPC conventions. This leaves three aspects of SOAP that influence our specification.

1) Header attributes: actor and mustUnderstand

Do we wish to define an actor for BTP headers, so that we can indicate that a BTP communicator is the intended recipient/processor?

eg. SOAP-ENV:actor="http//www.oasis-open.org/BTP/2001/1.0/communicator"

Do we wish to set mustUnderstand to "1"? As I read the SOAP spec, either the header entry gets stripped out by the actor, or the actor is not present, in which case the header entry hits the ultimate recipient, who presumably knows he is ultimate and therefore can decide that the actor doesn't exist. At which point, it does what? There is no defined fault for this eventuality that I can detect.

What does mustUnderstand add to the picture? Doesn't the presence of an actor attribute essentially allow the same "catch" to be made?

It seems to me that we should make the attributes be present in any SOAP Header entry that we use for a BTP message, irrespective of whether we expect the message to be handled by a SOAP server per se.

If that is unacceptable (presence of attributes which instruct a SOAP server is deemed to be a strong indication that they must be processed and understood by a SOAP-compliant server) then I believe we should revisit the decision to use a SOAP-ENV: Envelope rather than a BTP relationship mechanism of some kind.

2) mandatory fault messages when using request/response protocols beneath

If I'm not mistaken the SOAP spec is vague on the responsibility of a server to return a faultcode message. The statement in "4.1.2 Envelope Versioning Model":

' If the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message (see section 4.4) using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace.'

could be taken to imply that other defined faultcode classes (Client, Server, MustUnderstand) also MUST be returned when using a "request/response protocol".

If this is is the standard interpretation of the responsibility of a SOAP server then BTP-over-SOAP-over-HTTP is different from BTP-over-HTTP.

3) SOAP actions

Presumably we just don't use them. However, this raises (again) the issue of BTP-over-SOAP-over-HTTP versus BTP-over-HTTP. Do we allow BTP to be used over HTTP without following the SOAP-over-HTTP binding rules? I can't see any good reason to preclude that.

However, once again, the decision to use SOAP as the enveloping mechanism may turn out to be counterintuitive.
 

TOPIC 2: Content of <btp:binding>

In this context I want to delve into the content of <btp:binding>.

In the draft messaging spec we have:

<binding>btp:btp-soapbinding-v1</binding>

[Parenthetic dumb XML questions: the encoding as <binding> versus <btp:binding> is a choice open to the instance generator, I assume. In other words, the schema defines elements within the namespace represented here by the prefix btp. The presence or absence of that prefix in element names--what significance does this have? Is the context inherited from the immediate parent element, such that <btp:foo><bar></bar></btp:foo> is equivalent to <btp:foo><btp:bar></btp:bar></btp:foo>?

[From this example I also assume that an element content can also be schema-constrained, and that fact is represented in the use of btp:btp-soapbinding-V1 as the content in the example shown? In other words the btp prefix in the content enables validation against a BTP scheme elsewhere]

The binding string is communicating two facts: the version of BTP, and the protocol stack that is being used.

The version of BTP is presumably implied by the namespace/prefix (btp means today "http://www.oasis-open.org/2001/BTP/1.0" or the like, and may tomorrow mean "http://www.oasis-open.org/2001/BTP/2.0".

The protocol being used must be communicated to our interlocutors. Agreed, we are already in communication using some ur-protocol, but our matrix-like addresses can include multiple bindings for alternation, and each must indicate the protocol to allow the address user to figure out whether they are capable.

So, a more minimal view of this binding would be:

<btp:binding>btp:SOAP-HTTP1.1</btp:binding>
<btp:binding>btp:HTTP1.1</btp:binding>
<btp:binding>btp:SOAP-JRMI1.3</btp:binding>

etc, etc.

Now, for purposes of foreseeing the unknown future, and for proprietary compacts between BTP users, I would also like to be able to do:

<btp:binding>foo:my-value-none-of-your-businessbtp:HTTP1.1</btp:binding>

or some prettier variant of an easily parsable scheme for identifying the protocol (using BTP-constrained content) and proprietary content (constrained in some other place).

As always, I excuse my wobbly XML and ask the reader to focus on the infoset.

The upshot of this is: if the BTP spec has a list of allowed protocol descriptions, and the maintainers of the spec allow anyone to suggest new ones, according to some rule like

<protocol stack> ::= <protocol-abbreviation><version-number-punctuated-by-points> |
                            <protocol stack>, <protocol-abbreviation><version-number-punctuated-by-points>

then we could whack out "bindings" pretty rapidly.

Yours,

Alastair
 
 

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