From: Kragen Sitaker (kragen@pobox.com)
Date: Tue May 23 2000 - 11:34:02 PDT
Justin Mason sent the following yesterday morning. I have included the
mail at the end.
Hi Kragen,
just noticed FoRK is recycling a discussion on SOAP, IIOP, and binary vs
text protocols, which is somewhat orthogonal to one I was talking in at
http://tinker.editthispage.com/ -- you might want to post a pointer to
that if it's still under discussion.
I was the designer and implementer of Wonderwall, a firewall proxy for
IIOP while I worked at Iona.
--j. (putting off subbing to FoRK until I get more time ;)
--
Justin Mason Work: http://www.netnoteinc.com/ <jm@netnoteinc.com>
Personal: http://jmason.org/ <jm@jmason.org>
"It's true that some sharks get cancer. I said this in my book."
-- William Lane, author of _Sharks Don't Get Cancer_
[included messages below --- Kragen]
"Hi Brad,
came across your 'blog via HTP, it looks good -- that kind of hardcore
techie 'blog is right up my street ;)
Anyway I spotted this:
Is it possible to do an HTTP version of IIOP? What would be the
performance of this? Also, seperately, would binary serialization of a
Java object over HTTP still get stuck on some firewalls? I've been
trying to work on a next-generation, easy to use ORB that is firewall
friendly and language neutral. Must learn more about firewalls.
SOAP and XML have serious performance problems - Is this true?
I wrote the IIOP-over-HTTP tunneling code for OrbixWeb, Iona's Java CORBA
implementation, and the CORBA firewall proxy, Wonderwall -- so I'm a bit
of a wiz in that field. ;)
IIOP is a clunky protocol -- there are many stages where you need an
intimate knowledge of the exact interface and types you're marshalling to
be able to tweak the binary data even slightly, due to the padded
marshalling structure of CDR. This was a complete PITA for wonderwall.
When you base64-encode IIOP to send it over HTTP, then base64-decode it,
you lose a hefty wodge of the performance benefits of IIOP as well.
However I'd say SOAP is much slower; considering how slow IIOP is compared
to plain ol' sockets, and considering SOAP introduces lots of text-based
marshal/demarshalling, that must be sloooow ;)
Firewalls can handle IIOP/HTTP fine, but you need to watch out for
implementation bugs; e.g. some versions of Squid if I recall correctly
couldn't handle application/octet-stream data in a POST (which is where
the base64 came in ;).
Also one of the big wins of IIOP -- namely callbacks, and thereby
bidirectional comms between client and server -- gets lost once you put
stuff into HTTP, which is inherently one-way; the client requests, the
server responds. (There is a very kludgy way to do it BTW but it is very
gruesome)
BTW if you do work out some way of slimming java, I'd love to hear it.
I've given up on it simply because the ultra-bloated JRE is just too big
for any platform I'm looking at.
--j. (currently hacking on the low end -- internet appliances ;)"
After sending a response to Justin, he sent another interesting email:
"Bradley Neuberg said:
> We need a 'commidified' version of Wonderwall that is in the open-source
> community, such as Apache, that can easily spread throughout the market.
yeah, deffo.
When I was starting on wwall, I tried to persuade Iona to do it as an open
source project; I didn't get very far with that though. :(
It's funny though, the code is very simple, and it works just like a
traditional UNIX firewall proxy -- accept() connection, fork(), and
select() and swap the bytes back and forth (with ACLs to block
non-permitted requests or replies). So I think if people really wanted
such a thing, it could be done quite easily!
> Can I post your message to Tinker? It is excellent.
sure, no problem! cheers! (anything I'm writing here is OK
for reproduction there too BTW.)
> IIOP is interesting; I have heard of IIOP implementations for embedded
> real-time factory devices, though that's probably pretty nasty.
Craig Ryan in Iona wrote a well-cool IIOP library in C, which did the raw
marshalling; it was designed for an embedded profile, so it was pretty
easy to use raw IIOP from an embedded device with this; you could call
something like: iiop_insert_unsigned_int(&iiopctx, temperature); or
whatever.
As an efficient protocol for throwing arbitrary data around from a client
to a server and vice versa, in a compact and fast manner, IIOP is fine;
it's just that it got quite painful when:
* proxies are included between the client and server -- which always happens
with firewalls;
* or an ORB is used to marshal the data, with the intricacies of sequences
and any types and what-not interacting with the IIOP alignment rules;
* or interoperability between versions of IIOP was required.
Basically IIOP's certainly well-suited to fast and compact requirements
like embedded systems, just not flexible in other ways. :(
> One thing I have wanted to work on is an a binary protocol 'compiler'
> that will take an arbitrary XML-markup language, such as SOAP or SVG,
> and then 'compile' and 'produce' a binary protocol, giving you a writer
> and reader for this binary protocol that makes it 'feel' like you are
> dealing with a simple XML based protocol.
yep, that would be a good one; handy for a "compressed" on-disk format
too!
Top tips from my IIOP experience: don't try to align the data! if you do,
then any kind of intermediate step that needs to move along existing data
to insert another segment will have a nightmare time trying to preserve
alignment. (Each CDR data type has different alignment rules based on how
many bytes it takes up)
The other thing is, you want to ensure compatability between versions;
that was another problem with IIOP, which XML solved. Judicious use of
name-value pairs, with well-defined boundaries, fixes this; ie. if a
reader encounters an NVpair with a Name it doesn't support, it can just
skip the value entirely and carry on. In IIOP, there was quite often
no indication how many bytes that datum took up, so the only thing to
do was barf.
> It IS possible to make distributed protocols that can do call-backs, it is
> just that the current IIOP spec has the IIOP messages going back and forth
> over two different sockets. What is necessary is to 'multiplex' both messages
> onto a single socket, which is on port 80.
yep, myself and Martin Chapman at Iona, proposed an addition to the IIOP
spec, "bidirectional GIOP", I think it made it into CORBA after I left
Iona. That causes callbacks to objects in a "client's" space to go over
that socket, sorting that problem out.
It's implemented in OrbixWeb, but I dunno about the other Iona ORBs or
other vendors' ORBs; myself and a few others in Iona used to push it as a
useful feature, but as you can imagine it takes quite a bit of rework to
support it, so without someone to push it I'd say it's been left at the
back of the "nice features" queue. :(
> Of course, this would keep a
> server from making an 'ad hoc' connection to a client. However, a client
> would connect to a server, and then the server could do call-backs. An HTTP
> Keep-Alive connection would have to be opened; it sounds like there might be
> proxies that don't implement this correctly, though.
However putting it on port 80 is the problem, as you say -- there's *lots*
of proxies that just can't handle even-slightly-nonstandard HTTP, and
changing the request-response semantics in such a way would almost
certainly not get through most HTTP proxies out there.
One trick though is to put that traffic through using the proxy's
"CONNECT" protocol, which browsers use to connect to HTTPS servers; the
protocol for that is simply "CONNECT http://url/", proxy makes a
connection, and the proxy simply swaps packets without any knowledge of
the protocol after that point. ;)
BTW obviously all these things cause horrendous problems for the firewall
admin ;) As an ex-firewall admin, just pretend I never mentioned 'em ;)
> I think it's time for a next-generation ORB. What is _really_ needed is a set
> of compelling application ideas that couldn't be done without ORBs, and then
> make an ORB that takes into account what has been learned in the past. I am
> interesting in hearing your ideas on this subject!
Hmmm... to tell you the truth, I really have trouble thinking of such apps
;)
I'm not really a CORBA believer. I guess I just haven't worked on enough
really large-scale projects where it became useful.
My opinion is that there are a lot of lessons it never learnt from the
IETF set of protocols, and other fields, which would have made it more
useful, extensible, and version-compatible. It's great code-wise and
object model-wise, but in terms of system interaction and protocol design
IMHO it's not as good :(
I'm still waiting to find I'm wrong; IMHO GNOME's Bonobo component
architecture (which I think is a promising application for CORBA) may just
do that. Fingers crossed!"
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 11:36:11 PDT