RE: Protocol Bindings

> I think the current debate is whether layering is an accurate
> and useful model for what SOAP does.

Agreed. To use Stuart Williams' lovely phrase, I'm an unashamed layerist. Is
anyone seriously arguing that layering is not the way to go? The heretics!

If the anti-layerists are prepared to skip a layer or two, why not more - to
use their logic to its ultimate conclusion what argument is there against
creating a wonderful "fiber-optic binding" for SOAP, which might be a 1,000
page document describing how SOAP envelopes can be transported directly in
strands of fiber without any intervening layers (hey, who needs IP?). It
could start off from base principles with the light equations, etc. Good
luck to them.

> Interesting - Akamai uses pre-arranged conventions (distributed,
> out-of-band state) to configure somewhere around 10,000
> intermediaries in a global deployment... what's you're definition of
> 'wide'? ;)

Eh, .. well .. a 'minimalist' wide deployment could start with two
companies.

When we get to 100 companies or 10,000 companies I think we will see the
issues with pre-arranged conventions. Akamai's fine architecture shows it
can work well within a single company - I am not disputing that.

> There are already proposals for routing and endpoint identification
> (SOAP-RP), authentication (XML Digital Signatures), caching
> ("Optimising Web Services with Intermediaries"), and discussion of
> others, including explicit correlation. All of these are expressed in
> SOAP blocks.

XML Digital Signatures provide integrity, message authentication, and signer
authentication only - all (useful) services at the messaging protocol layer.
Authentication services at the application protocol layer would authenticate
the communicating endpoints themselves. XML DigSigs alone do not verify that
the sender of the message (who might not necessarily be the signer as it
could have got the msg routed from somewhere else) is who the recipient
thinks it is, or vice versa. What proves that the validly signed XML message
is actually being transported to the intended recipient, as opposed to an
imposter recipient (and no, we do not wish to encrypt it, for business/legal
reasons). Authentication at the application protocol level would provide
these (very necessary) additional services.

> so many people have figured out how to make bindings to all kinds
> of underlying protocols including SMTP, FTP, TCP, IPC, HTTP, MIME
> multipart, BEEP, SIP, etc.

Good .. The more the merrier!

I would class most of what you listed as application protocols. I would
class MIME multipart as mainly an encoding - the fact that you have a SOAP
envelope encoded as MIME multipart does not define how such envelope gets
from point A in a network to point B. I would class TCP as a transport
protocol.

I think defining the following are all useful exercises: (A) a routing
protocol for SOAP, (B) a binary encoding for SOAP envelopes and (C) a
SOAP-specific application protocol above TCP.

They are three distinct issues, and should be separately defined. There is a
need to clearly think through what is the goal of such work.

Section 7 of the SOAP-RP spec is the beginnings of an application protocol
above TCP dedicated to transporting SOAP messages. It needs a lot more
detail, starting with security (e.g. security is not something to be left to
later - it should be one of the first topics you address, not the last).
Also error handling needs to be defined (what happens if I only received
half a DIME record), etc.

Your DIME specification is mixing up a description of a binary format with
some message semantics (e.g. discussing how DIME records must be sequenced
on a transport). I think a better approach would be for the XMLP WG to
define the binary encoding and leave it up to the individual bindings to the
application protocols to describe how such an encoding (or current XML 1.1
encoding, or SOAPwA encoding) could be transported. If the binary
representation involved multiple records within one message, some bindings
might have to put all on-the-wire in a serialized fashion, but some, such as
BEEP, could be capable of carried multiple binary messages at the same
time - by interleaving their "records" - thus you could get pairs of threads
in multithreaded apps talking without serialization, which is highly
desirable. The binary encoding certainly should not be specifying this info.

> The binding is exactly what it sounds like - a gluing mechanism
> between SOAP and whatever underlying protocol. There should be no
> additional semantics defined by the binding because the places where
> we add semantics is either as SOAP extensions or as underlying protocol

Agreed - thin bindings are good, fat bindings are bad.

Eamon

Received on Saturday, 7 July 2001 07:41:44 UTC