Jini and XML
Tim Bray is feeling a touch guilty...
ongoing · Bits on the Wire? So I wrote a quick note to Jim along the lines of “Uh, what about XML?”
Months later(!) Jim Waldo responds with "What is XML?" - in effect elaborating on the question in interesting ways without attempting an answer. Elaborating on the question is quite reasonable. XML is simply data structures serialized into a common text format - but different folks tend to attach different connotations to the use of XML.
Saw Jim Waldo when he gave a (quite interesting and entertaining) talk at the first JavaOne conference in 1995 - I believe he was talking about Jini (or a precursor?). Interesting stuff, but not relevant to anything I was doing at the time, so I filed Jim away under "guys whose work is worth checking on".
About a week ago I checked back, read up on Jini, and can see how using Jini could introduce some powerful simplicity into complex distributed applications. Might even be useful to apply to some of the larger problems I can see working on over the next several years.
To my mind the use of Jini versus XML primarily comes down to a single question - "Loosely coupled or tightly coupled?" - in the context of distributed applications.
Within an organization you can reasonably deploy tightly coupled applications. If you can reasonably expect a JVM on both ends of the network connection, using Jini makes a lot of sense, as you could save boatloads of development time, and some classes (no pun intended) of problems simply go away.
Between organizations you want things to be more loosely coupled. The notion of dynamically loading a Java class from another organization into my JVM gives me hives. There might be cases where this makes sense, but this would be more the exception than the rule. Pumping your inter-application data through XML is likely going to require more development and runtime work compared to Jini. The payback is better isolation - essential when the level of trust is less, and when the range of versions is greater.