RE: Last Call: Using SOAP in BEEP to Proposed Standard

["Eamon O'Tuathail" <[e-mail]>]

>> ... but SOAP can be mapped to a variety of transports,
>> including direct mapping over TCP or UDP. 

If your goal is to send a series of opaque pieces of data over a network
from peer A to peer B, you cannot simply place them directly on a TCP
socket and hope everything works. Something (we will politely argue
about 'what' in a second) has to provide authentication, transport
security, asynchrony, framing of messages etc. This "something" is
normally called an application protocol. You can give it a different
name (I am not too worried about what this collection of functionality
is called) but I assume you agree this is definitely needed. 

Marshall has a "must-read" paper on all this at:
http://www.ietf.org/internet-drafts/draft-mrose-beep-design-03.txt

In this context, by "opaque piece of data" I mean any data (e.g.
application programmatic XML messages) that gets through the application
protocol without having to be parsed or edited by the application
protocol itself. 

I think it will mislead some people when talking about opaque pieces of
data to say "direct mapping over TCP", given that the above range of
services must be provided - some people will think a 'direct' mapping is
magically faster, because a layer has been omitted, which is plain
wrong. 

But we are not talking about opaque pieces of data - we are talking
about SOAP envelopes - which do have SOAP extension fields - into which
any control information could be placed. The "application protocol"
services have not been omitted - they simply have be added into the SOAP
message. 

Now we reach our point of disagreement - which is whether it is better:

a) to use fat SOAP messages that extensively use these extension fields
for application protocol-like services, and that sit directly on top of
a TCP socket, or 

b) to use thin SOAP messages that carry the programmatic messages and
higher level services in the SOAP extension fields, over BEEP over TCP. 

>> Do we really believe that carrying SOAP over BEEP is better 
>> than carrying it over TCP? 

Do we really believe that carrying XHTML over HTTP is better 
than carrying it over TCP?

For each piece of "application protocol"-like information you are
planning to put inside the SOAP envelope, I could argue why not put it
inside the XHTML document (heck - they are both blobs of XML Infoset
items). At first this might seem a great idea, but what about those
users who need SVG, X3D, flash, PDFs, PNGs, etc. hmmm. 

Yes, SOAP over BEEP is obviously better. 

I agree that SOAP is more than just content (which is what you will
argue), but I think the extras should be used for higher level services
(see below), not to duplicate what is already provided. 

The whole concept behind BEEP is to define once all the common tasks
that an application protocol needs - session establishment, framing,
security, etc. I can't see the logic in defining all these things again
.. and again .. and again for each new thing we need to carry. SOAP is
just one of many things people wish to have carried. 

>Did we even discuss that? 
Yes. All the relevant BEEP and SOAP mailings lists were informed - 
* The BEEP WG mailing list:
http://lists.beepcore.org/pipermail/beepwg/2001-June/001118.html
* The W3C XMLP WG list:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0115.html
* The DevelopMentor SOAP list:
http://discuss.develop.com/archives/wa.exe?A2=ind0106&L=soap&F=&S=&P=868
4
* The SoapBuilders List:
http://groups.yahoo.com/group/soapbuilders/message/3867

Feedback was incorporated into the spec as appropriate.  

There was a LONG discussion of this at:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0013.html
(follow it all the way to the end!) which concluded with
http://lists.beepcore.org/pipermail/beepwg/2001-July/001210.html

>Did we get some form of requirement from the WG defining
the XML protocol in the W3C?
Yes. 
http://www.w3.org/TR/2001/WD-xmlp-am-20010709/
Also we had extensive discussions with many SOAP people about this. 

>How can we define a mapping to BEEP channels without even considering
the >potential requirements for multi-step forwarding of SOAP messages
across >various transports? What is the relation with SOAP extensions to
handle >such forwarding, that are currently debated in the W3C? 

Now we are seeing the obvious benefits of clean layering.

BEEP carries the SOAP envelope as an opaque block of data between peers
(possibly using the BEEP TUNNEL spec where needed, to get between >2
peers where each knows about BEEP). When we are talking about using
differing protocols together (where some peers understand one protocol
and others a different one), then additional information needs to be
carried - this is a higher level service and is ideally suited for those
SOAP extension fields. 
Whatever the W3C puts in those fields will be carried by BEEP - because
BEEP does not even look at the SOAP envelope. 

You should seriously consider using BEEP for your SOAP work.

Eamon O'Tuathail