Objex Consulting

Service Oriented Architecture (SOA) can provide significant improvements in business flexibility, and decreased software maintenance and development costs, by promoting the implementation of flexible systems for business automation. The key aspect is an extra degree of freedom within the design space, enabled by adding a new type of articulation to the architect's toolkit. This new kind of joint allows systems to interact within the information and functional architectures, without intertwining those systems in the technical and application architecture spaces. In other words, systems can exchange information, and perform functions for one another, without having to synchronize their lifecycles, or to infect each other with environmental and design dependencies.

We call this mystical element an interface, and it's not at all new, nor especially mystical. The concept of interface has been around a long time, even if you just count the software engineering context. The basic idea is to hide how a particular function is performed behind an abstraction that specifies what is to be done. In the context of SOA, an interface is more precisely defined as a set of operations, and an information model. The information model specifies the data exchanged by the interacting parties in the course of requesting operations, and replying to requests. At the logical level, the owners of the systems that need to interact now have a core ontology on which to build a more encompassing contract of the functionality to be built, and the quality of operational capability. This simple hinge frees the two system lifecycles from having to synchronize at specific points, or for changes in one system to cause ripples in the other.

Another key element is the technical mechanism by which the intentional behaviors of the systems are expressed. If interaction requires specific technical means to communicate and coordinate requests and responses, then changes to the system environments can ripple through the interaction; requiring the other parties to the interaction to change in lock-step. There are two approaches to this problem: standardized interaction syntax and semantics(!), or a rich and dynamic translation/transformation/routing capability that can mask the technical changes, and absorb the ripples.

Standardization is one current rage, and has the advantage of a single messaging syntax that can be used and processed by an open toolset without significant customization. The down side is the cost of the syntax itself (XML processing), and the slow pace of standard evolution; although some standards are evolving so fast that they are effectively moot. The second approach is a middleware approach. The current trend is toward a bus architecture that allows systems to "plug in" to a common messaging context. Events are propagated across the bus according to rules defined for that bus. Systems can propagate and absorb events to and from the bus. The bus is likely to be virtual and distributed, and provide for optimizations. For example, a simple bus with only a few systems connected might be mapped to point-to-point connections. In this case, the bus adapters route and manage independently. More sophisticated architectures will involve many components of varying types and purposes (business, application, technical), gateways, brokers, hubs, data marts, context managers, etc. This solution is more realistic, allows for semantic translation and transformation, and is likely to perform better. However, significant architectural vision and principles must be applied across a wide technology set to succeed.

A hybrid approach

Send mail to cppc@objex.com with questions or comments about this web site.
Copyright © 2004 Objex Consulting
Last modified: 03/16/05