Common pitfalls of adopting SOA

Having just covered the benefit potential of contemporary SOA, it's time for a reality check. As with any application design or architecture, quality can vary. SOA is no exception. In fact, considering the extent to which organizations need to shift technology and mindset to fully adopt SOA, it is actually probable that some will inadvertently build bad service-oriented architectures. Following are descriptions of some of the more common mistakes.

3.5.1. Building service-oriented architectures like traditional distributed architectures

Probably the number one obstacle organizations face in achieving SOA is building traditional distributed architectures under the pretense that they are building contemporary SOA. This is often the result of an acceptance of one or more of the misperceptions listed earlier in this chapter.

The danger with this scenario is that an organization can go quite far in terms of integrating the Web services technology set before realizing that they've been heading down the wrong path.

Examples of some of the problems this can introduce include:

• Proliferation of RPC-style service descriptions (leading to increased volumes of fine-grained message exchanges).
• Inhibiting the adoption of features provided by WS-* specifications.
• Improper partitioning of functional boundaries within services.
• Creation of non-composable (or semi-composable) services.
• Further entrenchment of synchronous communication patterns.
• Creation of hybrid or non-standardized services.

Understanding the fundamental differences between SOA and previous architectures is the key to avoiding this situation. (Part of Chapter 4 is dedicated to discussing this topic.)

3.5.2. Not standardizing SOA

In larger organizations where various IT projects occur concurrently, the need for custom standards is paramount. If different development projects result in the creation of differently designed applications, future integration efforts will be expensive and potentially fragile. This is a lesson many IT departments have already learned through past legacy nightmares.

The ability for SOA to achieve federation across disparate environments has been well promoted. The potential exists. However, it does not happen by simply purchasing the latest upgrades to a vendor's development tools and server software. SOA, like any other architecture, requires the creation and enforcement of design standards for its benefits to be truly realized. (See the "Once you go SOA, everything becomes interoperable" myth described earlier in this chapter.)

For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighboring applications it may be required to interoperate with one day.

This can lead to many problems, including:

• Incompatible data representation that results in disparate schemas representing the same types of information.
• Service descriptions with irregular interface characteristics and semantics.
• Support for different extensions or extensions being implemented in different ways.

SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve independently within each application. However, standardization is still required to ensure consistency in design and interaction of services that encapsulate this back-end logic. Design standards, such as the "WSDL first" approach explored throughout Parts IV and V of this book, are required to realize many of the key benefits provided by SOA.

3.5.3. Not creating a transition plan

The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an IT environment's infrastructure, the repercussions of a poorly executed migration can be significant.

Transition plans allow you to coordinate a controlled phasing in of service-orientation and SOA characteristics so that the migration can be planned on a technological, architectural, and organizational level.

Examples of typical areas covered by a transition plan include:

• An impact analysis that predicts the extent of change SOA will impose on existing resources, processes, custom standards, and technology.
• The definition of transition architectures, where those environments identified as candidates for a migration to SOA evolve through a series of planned hybrid stages.
• A speculative analysis that takes into account the future growth of Web services and supporting technologies.
• Detailed design changes to centralized logic (such as a new security model).

Creating a transition plan avoids the many problems associated with an ad-hoc adoption of SOA. Each plan, though, will be unique to an organization's requirements, constraints, and goals.

3.5.4. Not starting with an XML foundation architecture

In the world of contemporary SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of contemporary SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de facto data representation architecture. It is this core set of standards that has fueled the creation of the many Web services specifications that are now driving SOA.

So much attention is given to how data is transported between services that the manner in which this same data is structured and validated behind service lines is often neglected. This oversight can lead to an improper implementation of a persistent XML data representation layer within SOAs. The results can severely affect the quality of data processing. For example, the same data may be unnecessarily validated multiple times, or redundant data processing can inadvertently be performed before and after a service transmits or receives a message.

Standardizing the manner in which core XML technologies are used to represent, validate, and process corporate data as it travels throughout application environments (both within and between services) lays the groundwork for a robust, optimized, and interoperable SOA.

3.5.5. Not understanding SOA performance requirements

When starting out small, it is easy to build service-oriented solutions that function and respond as expected. As the scope increases and more functionality is added, the volume of message-based communication predictably grows. This is when unprepared environments can begin experiencing significant processing latency.

Because contemporary SOA introduces layers of data processing, it is subject to the associated performance overhead imposed by these layers. Contemporary SOA's reliance on Web services deepens its dependence on XML data representation, which, in turn, can magnify XML processing-related performance challenges. For example, Web services security measures, such as encryption and digital signing, add new layers of processing to both the senders and recipients of messages.

Critical to building a successful service-oriented solution is understanding the performance requirements of your solution and the performance limitations of your infrastructure ahead of time.

This means:

• Testing the message processing capabilities of your environments prior to investing in Web services.
• Stress-testing the vendor supplied processors (for XML, XSLT, SOAP, etc.) you are planning to use.
• Exploring alternative processors, accelerators, or other types of supporting technology, if necessary. For example, the XML-binary Optimized Packaging (XOP) and SOAP Message Transmission Optimization Mechanism (MTOM) specifications developed by the W3C. (For more information, visit www.w3c.org.)

Performance is also one of the reasons coarse-grained service interfaces and asynchronous messaging are emphasized when building Web services. These and other design measures can be implemented to avoid potential processing bottlenecks.

3.5.6. Not understanding Web services security

The extent to which Web services technology grows within a given environment is typically related to the comfort level developers and architects have with the overall technology framework. Once it does expand it is easy to simply continue building on simplistic message exchanges, which usually rely on Secure Sockets Layer (SSL) encryption to implement a familiar measure of security.

While SSL can address many immediate security concerns, it is not the technology of choice for SOA. When services begin to take on greater amounts of processing responsibility, the need for message-level security begins to arise. The WS-Security framework establishes an accepted security model supported by a family of specifications that end up infiltrating service-oriented application and enterprise architectures on many levels.

One of the more significant design issues you may face when WS-Security hits your world is the potential introduction of centralized security. With this approach, the architecture abstracts a large portion of security logic and rules into a separate, central layer that is then relied upon by service-oriented applications.

Even if your vendor platform does not yet provide adequate support for WS-Security, and even if your current SSL-based implementation is meeting immediate requirements, it is also advisable to pay close attention to the changes that are ahead. Proceeding without taking WS-Security into account will inevitably lead to expensive retrofitting and redevelopment. This impact is amplified if you decide to implement a centralized security model, which would essentially become an extension of IT infrastructure. Acquiring a sound knowledge of the framework now will allow you to adjust your current architecture and application designs to better accommodate upcoming changes.

3.5.7. Not keeping in touch with product platforms and standards development

IT professionals used to working within the confines of a single development platform have become accustomed to focusing on industry trends as they apply to the product set they are currently working with. For example, .NET developers are generally not too concerned with what's happening in the Java world, and vice versa.

A transition to SOA opens up the arena of products and platforms that IT departments can choose from to build and/or host custom-developed application logic. While the tendency will be there to continue with what you know best, the option to look elsewhere is ever-present. As explained earlier, this is the result of establishing a vendor-neutral communications framework that allows solutions based on disparate technologies to become fully interoperable.

Another factor that can (and should) weigh in when comparing products is how product vendors relate to the WS-* specification development process that is currently underway. As different vendor alliances continue to produce competing extensions, how your vendors position themselves amidst this landscape will become increasingly important, especially once you begin to identify the extensions required to implement and execute key parts of your solutions' application logic.

In the meantime, specific aspects to look out for include:

• which specifications vendors choose to support
• the involvement vendors demonstrate with the standards development process itself
• which other organizations vendors choose to ally themselves with (for a given standard)
• roadmaps published by vendors explaining how their product or platform will support upcoming specifications and standards

Chapter 4 provides an overview of the standards development process, including descriptions of the primary standards organizations related to SOA.