From: Kragen Sitaker (email@example.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.
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/ <firstname.lastname@example.org> Personal: http://jmason.org/ <email@example.com>
"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]
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.
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