Thursday, October 13, 2005
Service Oriented Architecture
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:
- a collection of components that can receive method requests over the internet
- the next release of CORBA
- an architecture for publishing and finding services
- created independently
- built by well-defined groups
- work independently of outside systems
- self-contained functionality, and would be useful even if not associated with other systems.
- 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.
- 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.
- if two systems are truly autonomous, there must be a healthy mistrust/suspicion between them, and hence, proof of identity.
- error management across systems boundaries
- workflow coordination between multiple autonomous systems
- why do we care about interoperability?
- why use SOA to achieve interoperability?
- improved decision making
- improved data integrity
- increased revenue
- decreased cost of software development
- decreased cost of software maintenance