RE: Protocol Bindings

Henrik,

> .. I think we should provide a model that actually enables us to
> talk about what people are doing in a fairly straight forward manner.

Agreed. This is what I am suggesting ...

+------------------------------+------------------+-----------------------+
| XMLP/SOAP (Messaging layer - | Message Formats  | SOAP Extensions       |
| describes messaging semantics| (Xml 1.0,        | (e.g. routing across  |
| - e.g. the soap envelopes and| MIME multipart,  | multiple app protocols|
| rules about their handling   | binary)          |                       |
|                              |                  |                       |
+------<< (binding describes this interface only, not below it) >>--------+
|                                                                         |
|       BEEP or HTTP or Custom or ... (Application protocol layer         |
|                  - describes how apps exchange messages)                 |
|                                                                         |
+-------------------------------------------------------------------------+
| TCP or SCTP or ... (Transport layer - how the bits are carried)         |
+-------------------------------------------------------------------------+

It is just plain wrong to think we can put a SOAP envelope encoded in some
format directly on the transport layer - additional services (what I am
calling an application protocol) are needed in the middle. One example is
authentication of the hops in a multihop connection - not doing this leaves
us wide open e.g. to denial of service attacks.

> Here's my answers to your exercises ;)

I was expecting your answers to A and B but am surprised with C.

> >I think defining the following are all useful exercises:
> > (A) a routing protocol for SOAP,
> A: SOAP-RP

I think the goal of a routing protocol for SOAP should be to route SOAP
envelopes through multiple application protocols, possibly via multiple SOAP
intermediaries.  If the message originator has a direct connection to the
message recipient, there is no need for a routing protocol. If a message
from the originator to the recipient must go through a number of application
protocol intermediaries, and every hop supports the same application
protocol in and out, then there is no need for a routing protocol. For
example, HTTP can happily sail through HTTP proxy servers and BEEP can go
through BEEP peers that support the BEEP TUNNEL profile. Where I see a need
for a routing protocol for SOAP is firstly when we have multiple application
protocols (e.g. HTTP for part of the way, then BEEP for more hops, and
finally, say SMTP onto the ultimate recipient) and secondly when a SOAP
intermediary needs to look at the SOAP message and decide based on something
inside it where next to route the message (i.e. it is not obvious to the
application protocol where to send it onwards). A routing protocol must be
able to handle SOAP messages encoded in a variety of formats (XML 1.0,
SOAPwA and a (future) W3C binary format). The idea of tying the routing
protocol to a specific encoding format is not acceptable.

> > (B) a binary encoding for SOAP envelopes and
> B: DIME

As XML-based messages get larger and larger, there is definitely a need for
a binary compressed encoding of the XML InfoSet. I would be happy to see the
W3C take a serious look at this. It should be recommended to authors of SOAP
protocol bindings to be able to carry XML 1.0, SOAPwA and a (future) W3C
binary format. The SOAP over BEEP spec already has functionality
specifically to support multiple formats, and other do too.

[...]
> .. the DIME spec is just to say that DIME messages cannot be used
> directly for multiplexing. As DIME is a media type, it indeed leaves
> it entirely up to other parties to figure out how it can be exchanged.

The current DIME spec is mixing up discussion of a media type with talk of
its interactions with protocols and multiplexing. I think it would be better
if the DIME spec concentrated solely on the media type - and you completely
deleted every section that discusses "protocol" and "multiplexing". It is
for higher-level specs to discuss such topics - not a media type spec.
Application protocols should obviously carry it to the best of their
abilities.

> > (C) a SOAP-specific application protocol above TCP.
C: left to the designer of the application using SOAP and SOAP-RP

I don't understand this.

I understand an 'application' as what executes inside a process on a
computing device. I understand 'application protocol' as a set of rules of
how two or more distributed applications talk over a network.  I might write
an app using .NET/C# and wish to talk to a remote app written with Java -
for this, it is the application protocol, not the application, that lays
down the rules.

> Note that the scope of SOAP-RP really only is to define how
> to send messages around.
SOAP-RP is trying to do a number of things that should be treated
separately, - one is routing among different application protocols, another
is acting as a mini-application protocol for the likes of TCP. The latter is
incomplete (e.g. missing security) and when it is complete it will be more
substantial document - and more difficult to implement.

There are other ways of doing SOAP-specific application protocols. BEEP is a
framework for designing application protocols - 80-90% of what is in an
application protocol is predefined. That means defining protocols based on
it, or writing implementations based on existing BEEP libraries, is very
simple. If SOAP is the only thing you want your application protocol to do,
there is no problem using it in a single BEEP channel.

> I agree with you that often many more features and functions such
                        ***** ??
> as security and reliability are needed and indeed just as important.

The security folks will go absolutely berserk at the idea that security is
some sort of 'optional' extra to be added later.

> Actually, I am not a believer in layered multiplexing ...
Ahh ... you were a 'layered multiplexist' once (as Stuart might say), in
your WebMuxing days, so how do we get you back again, to be a 'born-again
layered multiplexist'?

Multiplexing does increase complexity over a simple connection, but it does
bring significant advantages. Marshall has described how the potential
problems can be are avoided.

For your comment:
> If you want to have that flexibility then why not simply do SOAP-RP/DIME
> over multiple TCP streams?

Marshall wrote:

>because, in today's operational environments, if you originate two tcp
>connections to the same ip address at the same time, you have no guarantee
>that they terminate at the same system. 10 years ago, this wasn't an
issue...
>regardless, when you do multiple tcp connections, then there's a whole
other
>set of problems that pop up with firewalls, viz., ftp-data for the simple
case

I would add on the idea of multiplexing over a single TCP connection vs.
using separate TCP connections ...
A) Tuning costs (e.g. establishing security & authentication) happen once
per connection
B) TCP slow starts multiplied

Multiplexing is substantially faster.

Eamon

Received on Sunday, 8 July 2001 13:01:01 UTC