Steve Vinoski reviews my paper for the IEEE, and what an excellent review it is. It also reinforces why it is so important for technical papers to have a broadly-accessible URL at the end; documents in a walled garden get read less.

One nice thing about the RPC model is that it mostly meets its goals on a LAN, especially one that is fairly fast. On the early eighties workstations, a 1MBbit LAN was relatively nippy compared to the 8MHz 680000 CPU on the pizza box, and the shared 20 MB filesystem on the server. Now even home storage capacity is starting to be measured in terabytes, CPU frontside and internal buses go hundreds of times faster, and yet network latencies are still there, as inevitable as the speed of an electro-magnetic wave through copper.

Clearly then, blocking invocation is a bad thing, and it is nice to see that Axis2 has an async client. But the issue where Ed and I really gave JAXRPC a kicking was in its data model. And it deserved it.

I am using Axis2 for my next CDDL DeployAPI prototype, and have just set up XmlBeans to generate structures for all the (many) types of message we get in the payloads. This is still compile-time brittle; a core of each session, the deployment descriptor, is unstructured XML and will be handed off to Xom. I just want to see if XmlBeans makes my life easier, working with XSD docs that are now effectively frozen (i.e. being standardised in an industry standards body). No opinions on XmlBeans yet, though I am not happy that the Ant task in XmlBeans CVSHEAD is not compatibile with that in version 2.0.0, so breaking Gump. Time for joining xmlbeans-dev, I suspect.

Incidentally, on the subject of RPC-versus-Distributed Objects-versus Async Messaging, there is one other broadly popular metaphor: Distributed Filesystem. This may appear to have fallen out of favour since the days of Netware filestores went away, but what, pray tell, is a remote HTTP server supporting the full WebDAV verb set, but a remote filestore with metadata?