Frankly, I don't see what the "abstraction of the transport
layer" provides you.
It means you don't have to define the same things again and again.
SOAP is important, but there are many others types of messaging -
Are we expected to duplicate and define slightly different variations of
the 50 pages of the BEEP spec inside each of these? And repeat roughly
every 6-8 weeks when the IETF and others start work on a new type of
messaging (e.g. http://www.ietf.org/html.charters/provreg-charter.html).
Rather than concentrating solely on SOAP, we have to consider the wider
picture, and come up with an appropriate solution - in this scenario I
think using BEEP is very sensible. Other people have differing views -
that is fine. Diversity is good!
I personally find BEEP quite atrocious. It introduces a "channel"
artifact that is gratuitous complexity; it breaks at least one
fundamental rule of networking, by allowing for multiplexing on
top of TCP.
On the issue of whether BEEP itself is a good idea or not based on these
On the issue of "gratuitous complexity":
I can tell you in practical terms it is roughly 50 lines of C# code.
For those people who - after carefully examining the alternatives for
richer messaging (e.g.
http://www.clipcode.com/peer/http_async_notif.htm) - think BEEP is a
good thing, and now wish to use it to carry SOAP messages - is there
anything technically wrong with, or do you have any suggestions for
improvements to, the SOAP over BEEP spec as proposed?