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.
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.
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.
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.
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.
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.
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.
If your mission is to drive successful SOA implementations, you will want to leverage the key recommendations summarized in this chapter.