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.