Model-driven SOA

Model-driven design is the process of describing a system as a series of graphical models prior to implementation. Graphical models are a great way to show the intent of a system, but there are no widely adopted SOA modeling techniques. In fact there are no widely adopted architectural modeling standards at all. How are architects supposed to create working software that is on-time and budget without good tools?

Other disciplines in software engineering do have good modeling tools. Developers have good tools that help them describe lower-level design such as referencing design patterns and the various UML templates such as object models and sequence diagrams. Business analysts often create use cases to show system functionality. Database designers often will use Entity-Relationship Diagrams to show the intent of a database. But what about the application and enterprise architect? They have no such standard models to communicate their architectural designs.

No wonder so many software engineering efforts fail, or at least why we have so many frustrated architects. This is partly the reason why SOA as a concept exists. SOA is a discipline to help correct a flawed architecture, but the real root cause is poorly architected systems, and a severe lack of architectural tools is part of the problem. It is surprising that we have gotten this far in the software engineering discipline and there is no standard way to represent the most important artifact, the application architecture.

Take a look at these three architectures. They are all architectural designs at the same level of abstraction. They were all created by Sun Microsystems, a company full of very competent architects. There is nothing wrong with the pictures individually, except they look nothing alike. The nomenclature is different. The layers a different, the first diagram is laid-out vertically, the second is horizontal and the third is kind-of clockwise.

Figure1: SUN's Java Composite Application Platform Suite

Figure 2: SUN's Logical Architecture for Enterprise Communications

Figure 3: SUN's Java Web Application Request Handling

And we don't mean to pick on Sun, this problem is pervasive – no two architectures look alike. The architects are not to blame for these inconsistencies, they have nothing to use as a guideline. And these are simple architectural diagrams, how are developers supposed to follow an architect's vision without more consistency? Engineers are a creature of habit, starting from scratch is no way to design application architecture.

The architectural blind spot

UML is the best known modeling technique, but does not have a nomenclature for the application architecture. There have been other attempts at models, but nothing has stuck. Service Component Architecture is a way to assemble components, not represent architecture. Business Process Management Notation shows process more than the core elements of an architecture. The most famous may be the Zachman framework, created by IBM back in the 1980s. This framework is often referenced in teachings, but not commonly used in practice. This is a good tool to describe what architecture is, but does not provide a way to model architecture.

Figure 4: Zachman Framework

So what will we do about this lack of architecture modeling techniques? This series of articles to-date has concentrated on SOA and open source. Modeling is about open standards, which is the cousin of open source. The open source community shares the culture of standards bodies and the open standards they create serve as the primary requirements for open source.

In fact open source software typically follows open standards religiously. Where standards exist, open source solutions are sure to follow. And where standards are lacking, the open source community is willing to offer help, which is the spirit of this article. In this article we will review a model-driven architecture model that I have used many times before with good success. It translates particularly well to the SOA-minded architect as the services are given a special place in the design.

This model-driven architectural technique consists of a graphical blueprint that diagrams the architecture and a couple of simple tables to describe the purpose and relationships of the components within the architecture. This is not a very complex technique, which is why it is easy to use. There are two models, one for enterprise architectures and one for application architectures. The only difference is the application architecture includes "UI Framework" and "Client" tiers and the enterprise architecture replaces these with an "Application" tier. Looking at the examples makes this distinction easy to understand.

Here is an example of an enterprise architecture model. This purposefully represents a very simple architecture so you can take a look at the nomenclature of the model rather than a complex architecture.

Figure 5: Enterprise Architecture Blueprint

The following diagram shows an application architecture model. This is the same general nomenclature as the enterprise model, except rather than an "Application" tier, we diagram a "Client" and "User Interface Framework" tier. We show these tiers on the application architecture because they a relevant to an application, but generally lose their usefulness within an enterprise architecture. This model also shows a more complex architecture so you can see how this model demonstrates an application that has many components.

Figure 6: Application Architecture Blueprint

This is a simple diagram, relatively easy for the reader to consume, which is the idea - to show a complex thing in a simple way. The most important aspects of the blueprint are the tiers, the ordering of the tiers and the representation of encapsulated and cohesive components within the tiers.

The blueprint is technology agnostic. This is important because it separates the design of the architecture from its implementation. The same is true for object and ERD models - the underlying technology is not referenced. The architectural model represents the core functional components.

We will use simple tables to show more detail about each component and how they relate to each other. We will see samples of these tables later, but first let us review quickly review the purpose of each tier in the blueprint.

Application Tier (enterprise model): This tier shows the various user applications that exist within the scope of the architecture being represented. This tier is placed at the top of the diagram, where a user interface would typically be placed, because it is really the interface that defines and differentiates one application from another. The services and data beneath the application tier are assembled, and hopefully reused, to support the application.

Client (application model): This is the platform the user runs to access the application. This is important because the client platform can execute functionality. For example, a regular browser vs. a rich internet application have very different capabilities at the client tier that we need to distinguish.

User Interface Framework (application model): In a Web-based application this tier gains in importance. A non-Web application may not need this tier, but we see fewer of those nowadays. This tier shows the capabilities on the server that supports the Client's presentation, navigation and state.

Service (both models): This is arguably the most important tier in the model, especially for an audience interested in SOA. Too many SOA initiatives start by prototyping SOA middleware and not defining the services. Services are the point of SOA, why start a SOA initiative without defining the services first? Creating an architectural blueprint forces the services tier to be considered prior to implementation. SOA middleware can also be represented in this tier as it really is just another service in the architecture, a service responsible for routing and transforming messages.

Integration (both models): The components in this tier allow the services in the tier above to communicate to the data and legacy systems below or to other services. These components are locators and transformers that bind to endpoints and can marshal data. In an SOA, they are the adaptors that the middleware would use to connect to various data sources and systems.

Resources (both models): A resource is typically either a data source or a legacy system. A legacy system is any system that is outside the domain of the architecture, but still has to be integrated. This is different than a service, because services are more fine-grained and likely better encapsulated to provide a cohesive set of functionality. A legacy system is not as cohesive as a service and its API is not as well defined. A data source is simply a data repository used to persist data, such as a database.

General Services – These are components that any tier may integrate with. These services may be tightly integrated, compiled directly into the component that requires the service. For example, the components in this tier may be created as helper objects rather than the loosely coupled components in the Service tier.

Bring out the tables

The blueprint does not show details about components or the relationships between components. Adding more detail or showing the relationship lines between components within the blueprint makes the diagram complex to read and hard to maintain. Rather we will use some basic tables to document more detail and the relationships. Specifically we will use two tables: the component-dictionary and component-relationship tables. The component-dictionary is a table that lists each component on the blueprint and a textual description of what the component's purpose and capabilities are. This table can contain as much functional and technical information as the architect requires. The component-dictionary also lists any contact details for the owner of the service. The following is a basic sample of a component-dictionary table.

The component-relationship table describes how the components within and across the tiers integrate. The table is easy to read and maintain. A "Uses" relationship exists between two services. A "Owns" or "Reads" relationship exists between a service and a resource. "Owns" means the service reads and writes to a resource - ideally only one service may "Own" a given resource. Here is a small example of the component-relationship table:

These are the core artifacts of SOA architectural modeling that I find useful. Of course you may add or alter any artifact to meet your needs. If model-driven development is the desired way to design and build applications, then architects need more tools at their disposal. The tools and techniques outlined in this article will hopefully provide enough of an introduction to this technique to help you architect your next SOA solution.

About the author

Adam Michelson has more than a decade of technology implementation experience. Adam is currently the director of service-oriented and enterprise architecture for Optaros Inc., an international consulting and systems integration firm that provides enterprises with best-fit solutions to IT business challenges, maximizing the benefits of open source software.