Random Thoughts

At the end of my last post, I mentioned a conversation between Roger Sessions and Terry Coatta. I did a google search on Roger, and found the object watch website, and spent a bit of time reading his newletters. Here are my thoughts. Newsletter #49 The rings of the enterprise. Different rules apply at different levels of the system. Sessions identifies four rings: Application, enterprise system, collaborative partners, everybody else - it looks very traditional (i.e. Unix permissions for user/group/world). Newsletter #45 What is a service oriented architecture? (I sure wish I knew!). Starts by identifying three ways in which SOA is commonly defined:

1. a collection of components that can receive method requests over the internet
2. the next release of CORBA
3. an architecture for publishing and finding services

He rebuts each of these definitions, but the arguments could be just over the meanings of the words. For example, he doesn't like the word component, and dismisses the first definition of an SOA by requiring each component-level method represent(s) a subsumable transactional boundary, and then having introduced the notion of transaction, argues that a component that accepts requests over the internet is a contradiction in terms. The rebuttal of SOA is the next release of CORBA is much stronger, and worth a read. The points raised are similar to those in the ACM Queue conversation with Terry Coatta. Finally, Sessions argues that defining SOA as an architecture for publishing and finding services (i.e. using UDDI, WSDL, and SOAP) is rather meaningless, since UDDI etc... are just technologies. An architecture is not just a collection a of technologies! Session succinctly states Defining an architecture "as anything that uses a particular technology is not very meaningful. It is like defining a house as anything that uses bricks. I agree strongly with this point. The newsletter ends with an attempt to define SOA: SOA is a set of architectural principles that define how autonomous systems interoperate; and highlights the keywords autonomous and interoperate. Autonomous software systems have the following characteristics:

1. created independently
2. built by well-defined groups
3. work independently of outside systems
4. self-contained functionality, and would be useful even if not associated with other systems.

There is a tension between autonomy and interoperability, and SOA deals with this tension. Five principles guiding the development of an SOA are then identified as:

1. there are no mutual dependencies, so neither system interrupts its own work to wait for some other system to complete a task. This implies asynchronous communications.
2. if two autonomous systems interoperate, there must be a communication channel between the systems that is independent of the technology used by either system; i.e. heterogenous communication channels.
3. if two systems are truly autonomous, there must be a healthy mistrust/suspicion between them, and hence, proof of identity.
4. error management across systems boundaries
5. workflow coordination between multiple autonomous systems

Newsletter #47 Service oriented architecture: why bother? Article starts with two big questions:

• why do we care about interoperability?
• why use SOA to achieve interoperability?

The article focuses on the cost of communication between systems, how different architectures scale, and (a rather simplistic) exposition on system complexity (but I agree entirely that many simple systems is less complex that one large system). The points for interoperatiblity are summarised as:

1. improved decision making
2. improved data integrity
3. increased revenue
4. decreased cost of software development
5. decreased cost of software maintenance

Overall, a balanced article good for business types. Newsletter #48 Web services: the SCRAM generation. The entire article centers around a new acronym, and a critique of SOAP not making any guarantees about message delivery. Sessions predicts that the current synchronous model of web-services will become obsolete by 2007, and be replaced by an asynchronous model. I can't see that happening - asynchronous models can get very complicated, and managing failure will be extremely complex in such a situation. Synchronous models, for all their imperfections, have a relatively simple messaging interactions that are humanly understandable. I believe that asynchronous messaging will require more formal models of messaging using state machines, and getting stressed and time-pressured software engineers to start rethinking their understanding of communication protocols is a big ask.

I had a troll through the microsoft research site today - there are some impressive people working there. I was actually looking for some notes on Computer Systems Research: Past and Future which I'd stumbled upon previously. The author of these notes is Butler Lampson - check out the work that he's done. Anyway, he makes the point that 'inventions' in computer science have typically ridden the free wave of Moore's Law. He makes the interesting point that the web was not invented by computer scientists, even though it is "the most important invention of the last decade". His lists of successes, failures, and unknowns comprise:

Successes	Failures	Unknowns
Virtual memory	Capabilities	Parallelism
Address spaces	Fancy type systems	RISC
Packet nets	Functional programming	Garbage collection
Objects/subtypes	Formal methods	Interfaces and specifications
RDB and SQL	Software engineering	Reuse
Transactions	RPC (except for web)
Bitmaps and GUIs	Distributed computing
Web	Persistent objects
Algorithms	Security

[Crikey! The code for that table was ugly - it all had to be on one text line...] These are certainly interesting lists, and good for discussion. He then goes on to discuss why the web is "the failure of systems research" (because computer scientists didn't invent it!), and states that the web is too simple, and old idea (but never tried), wasteful (but fast enough), and flaky -- all of this sounds like good, solid engineering to me! The academic response is that the web doesn't scale, but it seems to have done pretty well so far. Lampsons lists of challenges is a bit weak, but in the 'information challenges' he mentions the 'Memex'... this topic is better discussed by Jim Gray in his lecture for the Turing award (What Next? A few remaining IT problems). Gray credits the Memex idea to Vannevar Bush, and goes into considerable detail (more than I can comprehend at 1am...). Finally, there is an interesting conversation between Roger Sessions and Terry Coatta in ACM Queue on the differences between objects, modules, and components. Before commenting I should really re-read the article - it was very good, and I could certainly learn some more from it. That's enough blogging for now. Good night!

Random Thoughts Well, that was easy! I've finally jumped onto the bandwagon, and got myself a blog.... does that make me hip? Anyway, It's all going to be rather self-indulgent, and with any luck, I'll be able to use this blog to record links to stuff that interests me. This is enough of a first post - best to check that everything works before spending hours composing a comprehensive work :-)