Chapter 1: Getting It Right

A SOA creates a flexible architecture, which allows for ’reconfiguring’ over time. In fact, ‘agility’ has been identified as the largest single driver for a SOA. This attribute has more value when the target is a larger system that may change (following the simple assumption that larger systems are more difficult to modify than smaller ones). As you become more comfortable with a SOA approach you will find that this style of computing is not targeted toward being a better ‘application architecture’, but is more of an ‘IT system architecture’. This perspective is important to understand as the reader moves through the material in the book.

As with all systems that are partitioned with strongly defined interfaces, SOA doesn’t necessarily create the highest performing system. Just as assembly code can produce a faster application than a higher level language (at the cost of higher maintenance), breaking the principles of a SOA can increase performance. With the ever increasing performance of processors and networks, a SOA approach assumes that the business benefits of lower maintenance and increased flexibility are more than offset any inefficiencies by the use of standards, components, and modularity. This, however, may not be universally true. Web services standards may not be the correct approach for all situations, including very high performant applications. (This is the first example of practical advice in this book.)

However, in large scale systems, such as an enterprise IT architecture, there is no attractive alternative. Avoiding ‘spaghetti code’ at this level can not only result in reduced costs during development due to reuse, increased compatibility between heterogeneous systems due to the use of standards, lower maintenance costs due to a well structured architecture, but most importantly, it can retain an organization’s ability to change as needed, and respond to changing business conditions. It is well worth the effort, and that’s why we created this book—to help.

Author:

Jim Green
Chairman and CEO, Composite Software

Back To Top

Chapter 2: Designing Services

Services are the fundamental building blocks of a SOA. The business functionality and the corporate data are contained within the services themselves. It is fairly straightforward to create a service, but also very possible to follow all of the standards the industry has worked so hard to create, yet not achieve the philosophy of a SOA and the benefits of reuse.

It is important to realize that web services standards (like SOAP, WSDL, HTTP, XML, UDDI, etc.) are specific and rigorously documented. SOA, on the other hand, is a methodology. Use of the standards while not adhering to the principles of the SOA ’philosophy’ yields very little. Much of this issue is dealt with in the design of the individual service interfaces.

As indicated above, there are a number of implementation issues ‘above’ the standards. In this chapter, several of these are discussed, including topics like designing for reuse and error handling. You may or may not elect to follow the recommendations, but the issues discussed are important and should receive careful attention.

If you are an application developer or a service author, this is the most important chapter for you.

Author:

David Besemer
Chief Technology Officer
Composite Software

Back To Top

Chapter 3: Registries and Repositories

As your enterprise creates more services than can easily be remembered, you will need to put something in place to keep them organized. The industry standard for this is called UDDI. A UDDI registry has become a required part of all large scale SOA systems and serves as the ‘SOA System of Record’.

Beyond the basics of providing the authoritative record of the service definitions, revisions, and description, the service registry has over time taken on an additional responsibility. The registry can make a major contribution toward the governance of the services through their lifecycle. Topics such as visibility (how does one discover a service), trust (what is the SLA for a service), and control (how does the organization control change) are discussed, along with numerous recommendations.

If you are a development manager and will be leveraging the ‘reuse’ capabilities of SOA, this chapter is required reading for you.

Author:

Luc Clément
Co-Chairman, OASIS UDDI Specification Technical Committee

Back To Top

Chapter 4: Enterprise Service Buses

The simplest communication protocol for SOA is HTTP. However the request/reply model of this Internet protocol does not address all of the communication patterns that are of interest. Upgrading from the simple HTTP protocol to a richer infrastructure represented by an enterprise service bus (ESB) can add richness to your system. One example is the ability to implement publish/subscribe protocol capabilities.

An ESB is all about instantiating some mediation between the participants in the system. Once this is done, the mediating ESB can add value in a variety of ways, including protocol conversion, observation of system-wide performance, data transformation between systems, and intelligent routing.

The capabilities listed above are indeed impressive. However, the addition of an ESB also adds complexity, and numerous implementation trade-offs will be required. In addition, there are different ’types’ of ESBs, and it is important to understand as much as possible prior to product selection and implementation.

If you are responsible for establishing the infrastructure for your SOA that will support all of the services this chapter is a must read.

Author:

Hub Vandervoort
Chief Technology Officer, Progress Software

Back To Top

Chapter 5: Runtime Management

Even with the right organization (Chapter 6), who are well trained (Chapter 7), well designed services (Chapter 2), the right infrastructure (Chapter 4), the right development practices and system of record (Chapter 3), things can/will still go wrong. In fact, if you do things well, you will create a system that is too sophisticated for you to easily observe it. To achieve the desired business objectives, the system must be appropriately monitored and governed at runtime.

This aspect of a SOA is fascinating in that the better things work, the less you see. After achieving success with automation and transparency, you then need to institute observe-ability to provide the proper runtime governance, trouble-shooting, and control. Issues include practical topics such as understanding what the current topology is and what is happening, assessing the current health of the overall system, and ensuring the continuing integrity of the system as it evolves—in other words, keeping it running and under control.

If you are responsible for the overall SOA system design, you must incorporate management into your plans. If you are responsible for the operation of the SOA system this is your most important chapter.

Author:

Paul Butterworth
Chief Technology Officer, AmberPoint

Back To Top

Chapter 6: Organizing For Success

As you move from large applications to modular components, there are more interactions between the software components, and between the providers and consumers of the components. Assuming that components are smaller than applications, there will be more of them. And assuming that different components/services will be created by different people, then there is an organizational impact generated by a SOA.

Many times, the communication required to work things out actually improves design and avoids problems later. Contrary to what some say, your existing personnel are probably fine, but they may need to think differently, assume somewhat different roles, and learn a little, but they can do this.

If you’re an organization manager and only read one chapter, this is the one.

Author:

Hemant Ramachandra
Managing Director, Business Systems Integration, BearingPoint, Inc.

Back To Top

Chapter 7: Capability Development

The system you build will be a reflection of the skill and dedication of the people who put it together. One of the first steps, then, is to prepare and educate your team. When approaching a SOA project proper training cannot be overemphasized.

It is critical to understand that you should not view SOA as the objective. The objective is to build a system that supports your organizational goals. SOA is only an ‘approach’ to putting that system in place. From this perspective, it is clear that the system should be put together by those who know your business best. It will be easier to train your own staff (who know your business) on SOAs than to train outside SOA experts on your business.

If you are charged with the creation of the SOA implementation team this chapter is required reading for you.

Author:

Jeff Schneider
Chief Executive Officer, MomentumSI

Back To Top

Chapter 8: Pulling IT Together

SOA provides value when it is implemented, regardless of the scope. So it is important to get started on the journey, regardless of where you start. Measuring progress is important as success begets more success, and failure begets improvement. Leveraging the hard earned knowledge of experts will help you accelerate your journey. So use the recommendations as your implementor’s guide.

If your mission is to drive successful SOA implementations, you will want to leverage the key recommendations summarized in this chapter.

Author:

Jim Green
Chairman and CEO, Composite Software

Back To Top