Principles of SOA

The Web services honeymoon is over. Numerous enterprises have built their Web services pilot projects and have proven to themselves that this most recent evolution of distributed computing technology can reduce integration and development costs substantially. In addition, critical Web services standards are falling into place, and vendors are coming to market with robust security and management products. It is time for forward-looking enterprises to take the next step.

The next step for many companies is to move beyond simple point-to-point applications of Web services to a broad application of Web service technologies both within the enterprise and among business partners. This move requires an architectural change to loosely coupled, standards-based Service-Oriented Architectures. More than a new architectural approach, such architectures require a different perspective on the role of IT in the organization. The role of the service-oriented architect, therefore, is critical to the success of companies looking to achieve the substantial returns business agility can provide. Today's enterprise architect must understand the practice of Service-Oriented Architectures. The potential rewards for this effort are enormous -- finally, distributed computing technology promises to be flexible and nimble enough to respond to business needs and provide the business agility companies have craved for so long, but which has always been just out of reach.

Service-Oriented Architectures are an approach to distributed computing that thinks of software resources as services available on a network. Such architectures are nothing new; CORBA and DCOM are familiar examples. However, these older examples of service-orientation suffered from a few difficult problems. First, they were tightly coupled, which meant that both ends of each distributed computing link had to agree on the details of the API. A code change to a COM object, for example, required corresponding changes to the code accessing that object. Secondly, such Service-Oriented Architectures were proprietary. Microsoft unabashedly controlled DCOM, and while CORBA was ostensibly a standards-based effort, in practice, implementing a CORBA architecture typically necessitated the decision to work with a single vendor's implementation of the specification.

Web services is an evolutionary development that improves upon DCOM and CORBA's weaknesses. What is new about today's Service-Oriented Architectures built with Web services is that they are standards-based and loosely coupled. The reliance upon universally accepted standards like XML and SOAP provides broad interoperability among different vendors' solutions, and loose coupling separates the participants in distributed computing interactions so that modifying the interface of one participant in the exchange does not break the other. The combination of these two core principles means that companies can implement Web services without having any knowledge of the consumers of those services, and vice versa. The Service-Oriented Architectures we will discuss are the standards-based, loosely coupled kind, which we will refer to as SOAs.

The power and flexibility that SOAs can potentially offer the enterprise is substantial. If an organization abstracts its IT infrastructure so that it presents its functionality in the form of coarse-grained services that offer clear business value, then consumers of those services (whether they are at the same company or one of that company's business partners) can access those services independent of the underlying technology issues that support them. Furthermore, if service consumers can discover and bind to available services while they are active, then the IT infrastructure behind those services can offer extraordinary flexibility to the businesses that invoke them.

Achieving these levels of power and flexibility, however, is a difficult task that requires a new approach to architecture. Enterprise architects must become ''service-oriented architects'' who understand the practice of SOA, as well as SOAs themselves. This distinction -- between the practice of architecture and the architectures that result -- is subtle, but critical. This article discusses the practice; that is, what service-oriented architects must do to build SOAs.

The principles of SOA
SOA is a type of enterprise architecture and, as such, it begins with the needs of the enterprise. However, the difference between SOA and other approaches to enterprise architecture is in the business agility that SOA offers. Business agility is the ability of a company to respond quickly and efficiently to change, and to leverage change for competitive advantage. For the architect, building an architecture that provides business agility means creating an IT infrastructure that meets as-yet-unknown business requirements -- a situation that throws traditional IT planning and design out the window.

To meet the needs of the agile enterprise, the practice of SOA has the following core principles:


* The business drives the services, and the services drive the technology. In essence, services act as a layer of abstraction between the business and the technology. The service-oriented architect must understand the dynamic relationships between the needs of the business and the available services on the one hand, as well as the technical underpinnings that offer the layer of abstraction required by the services.

* Business agility is a fundamental business requirement. Instead of dealing with concrete requirements from business, SOA considers the next level of abstraction: The ability to respond to changing requirements is the new ''meta-requirement.'' The entire architecture -- from the hardware on up -- must reflect the business agility requirement, because any bottleneck in the SOA can torpedo the flexibility of the entire IT environment.

* A successful SOA is always in flux. To visualize how a SOA is supposed to work, it is better to think of a living organism rather than the traditional ''building a house'' metaphor that gave software architecture its name. IT environments are in a constant state of change, so the work of a service-oriented architect is never done.

For the architect used to building houses, tending to a living organism requires a new way of thinking. Fortunately, however, the foundations of SOA rely upon familiar architectural principles.

The foundations of SOA
There are two increasingly popular movements in IT -- one architectural, the other methodological -- and each has something to offer the service-oriented architect. First is the Model-Driven Architecture (MDA), which is championed by the OMG, the same body that looks after CORBA. MDA states that architects should begin with a formal model of the system being built, ideally in the Unified Modeling Language (UML), which is also shepherded by the OMG. MDA begins with a platform-independent model that represents the functional requirements and use cases of the users of the system. From this platform-independent model, architects can derive whatever platform-dependent models they need to specify the design of the system under construction. These platform-dependent models are so detailed that they can be used to automatically generate the implementation code itself.

The core strength of MDA is that the designs for systems are fully specified; thus, there is little leeway for misinterpretation when the systems are built, and the models can be used to generate working code. But MDA has some limitations. First, MDA assumes that the business requirements are fully specified before the model is built, which is not the case in the typical dynamic business environment. Second, MDA does not offer a feedback loop; if developers need to diverge from the models, there is no set way to keep the models up to date.

The second foundation of SOA is the Agile Methodology (AM) movement, most notably represented by Extreme Programming (XP). AMs like XP provide a process for building software systems in environments where requirements are unknown or in flux. XP requires that a user representative work closely with the development team, helping to write tests that guide the daily work of the developers. All members of the team pitch in on the design, which is kept as minimal and informal as possible. The goal of AMs is to build just what the user wants, avoiding extraneous work on artifacts like formal models. AM's core strength lies in its agility -- the ability to deal with changing requirements. AM's main weakness is its limited scalability. For example, XP works well for small teams and projects of moderate size, but as the project scope grows, it becomes more difficult for team members to have a solid grasp of all aspects of the project without a concrete, comprehensive plan to work from.

On the surface, MDA and AM appear to be contradictory -- MDA assumes fixed requirements, while AM assumes the opposite. MDA centers on formal models, while AM eschews them. However, at the risk of being iconoclastic, we will take certain elements from each of these approaches and put them together into a coherent architectural practice.

There are three levels of abstraction in a SOA, following the first principle of SOA: The business drives the services, and the services drive the technology. AM connects the business model directly to the implementation, as represented in the platform-dependent model. MDA does not separate the business model from the platform-independent model, but takes the platform-independent model as its starting point. SOA must connect these models, or levels of abstraction, into a single architectural approach. We will make this connection by looking at the five-view approach to architecture.

The five-view approach to SOA
Enterprise architects find their profession both challenging and gratifying because they must consider IT from many perspectives. Philippe Kruchten (who is in charge of the development of the Rational Unified Process) distilled these perspectives into what we will call the five-view approach when applied to SOA.

Four rectangles represent different ways of looking at an architecture, representing different stakeholders. The fifth view, the use-case view, overlaps the other views and plays a special role with regard to the architecture. The deployment view maps software to the underlying platforms and associated hardware, the way that systems specialists view the architecture. The implementation view describes the organization of the software code, and is the view favored by programmers. Business analysts work with the process view, which addresses the runtime issues of the software. Finally, the logical view represents the users' functional requirements. In the case of SOA, the service-oriented architect must be able to connect the users to the services, and the services to the underlying technology, following the threads of use cases in the use-case view.

To show how the service-oriented architect must work with each of these views, let us put them in the context of the SOA meta-model. There are two overlapping realms of SOA: The business realm represented by the business model and the service model, and the technology realm represented by the service model and the platform-dependent model (the service model is shared by the two realms). Business users who use the logical and process views work with coarse-grained business services, orchestrating them into processes as needed depending on the fluctuating requirements of the business. Technologists, on the other hand, work to build and maintain the abstraction layer between the services and the underlying technology. The central model, representing the services themselves, acts as the axis around which the business moves.

The SOA meta-model inherits the platform-independent and platform-dependent models from MDA, but adds AM's interaction with the user as well as an agile feedback loop, represented by the two-way arrows between the ovals. Likewise, the meta-model solves AM's scalability issue by introducing the intermediate level of abstraction provided by the central service model. Users can thus deal with the day-to-day concerns of the business, reflecting any changing requirements in the service model. Technologists can then respond to these changing requirements quickly and effectively because the underlying technology is model-driven.

What is different about the practice of SOA and more traditional approaches to enterprise architecture is the way it enables agility. Remember that the third principle of SOA states that SOAs are always in flux. This environment of constant change is the cornerstone of the practice of SOA. The stakeholders shown in this figure continue to effect changes throughout the architecture on an as-needed basis. The line between design time and runtime blurs as the technologists respond to the changing business requirements as a normal part of day-to-day operations.

The missing pieces
We have provided a broad, high-level framework for the service-oriented  architect, showing how elements of MDA and AM can help provide the tools users need to create and maintain SOAs. Nevertheless, many pieces are still missing from the SOA puzzle -- pieces that software vendors and professional services organizations must provide. In the business realm, vendors must offer service-oriented business process, workflow, and service orchestration tools and services. Modeling tools must be available that can adequately reflect business services in an agile, platform-independent way. Technologists must have tools that can generate code from models, and update those models when the code changes. And finally, vendors must offer SOA-enablement software that allows service-oriented architects to build and maintain the level of abstraction between services and underlying technology in a reliable and scalable way. Fortunately for today's enterprises, such products will be coming to market soon.

The most important missing piece, however, is the top-down approach to SOA outlined in this article. Most of today's thinking about Web services is bottom up: ''Here's how to build Web services, now let's use them for integration.'' That approach to using the technology is a great first step, because Web services can dramatically lower the cost of integration, which is a story today's technology managers love to hear. As the economy improves and IT finally pulls out of the doldrums, however, companies will look to IT to offer increasingly strategic value to the organization. Service-oriented architectures provide the framework that will enable IT to offer this value in the form of business agility.

Most   Popular