Charles Weir's Reflections on the Distribution Retreat Day
On what I learned:
XML is worth watching in this area. It's a format for sending structured data to a service that can either display it or process it. Much like ASN.1, it consists of tags and data. However there seems to be much more support for it, including 'off the shelf' products for displaying XML data using HTML.
From a design point of view, the important feature of XML is that it provides a format for sending Objects between systems (or at least, the data comprising objects). This is something that CORBA is conspicuously bad at. Java does provide mechanisms - but this is useful only if both client and server are running Java. Is this likely?
I was particularly interested in John's assertion that "Java has failed for client platforms". The experience of public network application developers suggests that Java was not very helpful for client platforms, because of the time cost of distributing the software (never mind the incompatibilities of different browsers…). For an Intranet they are fine; for general public use they are painful. Which is why everyone's looking to XML.
In the main design process, my main insight was that this wasn't really a suitable task for CORBA-style distribution at all. Implicitly, I've assumed so far that the only interesting form of object distribution is 'real-time'; where the client sends a message that is processed more-or-less immediately by the server. Another possibility is Message-Oriented-middleware (though so far, I've not had a need to use it to pass objects around…).
But as far as I could see, the ideal distribution mechanism for this application would be Lotus Notes (or an equivalent); it's something I use daily, but I'd never thought of it as an object-distribution mechanism. Yet it satisfies more or less exactly the requirements of that particular project.
So if I were taking the design further, I'd ask "how would one componentise a Lotus Notes package to use in this project". And in the process of following that up, I'd no doubt find myself appreciating at last just why it is that Lotus provide a Java manual as part of the standard Notes installation :-).
Thoughts on the Process
Our team didn't really get very far. Why? Because we all knew very well that in order to choose an architecture we needed to know much more about the system than we could learn from the exercise sheet. So we spent much of the time envisioning the system and guessing additional requirements and likely numbers of users and transactions. (One way we did this was to set up "straw men" of various architectures, so that we could ask questions to differentiate them.) Clearly these requirements are something we'd need to have specified or specifiable in a larger workshop.
There's much more we could do. I don't believe implementing it would help. What would we learn from an implementation? What would help would be to have expert representatives for the various technologies - CORBA, Notes, and Java Beans. Such people wouldn't need to be suppliers - anyone who's implemented a released commercial system using that technology in an interesting way would be fine.
I feel encouraged that there's sufficient meat both in the subject and in this particular way of approaching it to justify a longer, larger and perhaps more intensive session. I'd like to do that.