SOA Antipatterns

Explore different Service-Oriented Architecture (SOA) antipatterns, which are descriptions of commonly occurring situations or solutions that generate decidedly negative consequences. With more businesses taking major steps to move from Web services to SOA, barriers to the introduction, adoption, and successful implementations of SOA are becoming more evident. Some of these barriers are similar to those that caused past essential initiatives to fail; others are specific to SOA.

Documenting such barriers and worst practices will help consultants, architects and specialists not to repeat the same mistakes and learn how to avoid them instead. The antipatterns compiled and described here were identified by the authors through personal experiences as IBM architects, examination of past and current SOA engagements, and by soliciting input from practitioners who were involved in customer SOA engagements.

Patterns versus antipatterns
"Example isn't another way to teach; it's the only way" - Albert Einstein

Patterns and pattern languages capture and formally codify good designs and best experience-based practices in a way that it is possible for others to reuse them. They successfully convey insight into common problems and their solutions. After all, common concepts, a vocabulary to describe them and a language to connect them together are the underpinnings for all disciplines and communities that practice them.

Christopher Alexander's research on buildings and town design is often considered the pioneering work on pattern-based thinking (see Resources). He coined the term "Pattern Language" to express his conviction that people's ability to design is as natural as their ability to use a language.

Patterns and pattern languages have been used by many disciplines, ranging from physiology and processes to project management and software engineering. Software design patterns became well accepted and used after the publication of the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (frequently referred to as the Gang of Four).

The software community is using patterns to resolve recurring problems encountered throughout the software lifecycle, ranging from software architecture and design to, more recently, software development processes and topologies. These patterns collectively capture the body of knowledge that represents our understanding of structures and mechanisms leading to well-architected software solutions.

A pattern is often defined as a "generalized, named problem-to-solution mapping." It captures a successful solution to a repeating problem in a particular context. Often, software patterns are documented using a template similar to one depicted in Table 1, Pattern template.

Software patterns provide a mechanism to capture knowledge and experience among architects and designers. They provide a common language and facilitate reuse of approaches that have been successful elsewhere and, thus, contribute towards the following aspects of a software project: reduced risk, increased quality and improved delivery time.

Antipatterns, on the other hand, document things that went wrong. Various surveys of hundreds of software development projects undeniably illustrate that things can - and often do - go wrong with software development. Studies show that five out of six projects fail: delivered far over the expected budget, significantly late, or are canceled. This suggests that it might be (at least) as worthwhile to examine causes for frequent failures as the rare instances of success (Noted author of Bitter Java, Bruce Tate, demonstrated in his developerWorks article how and why antipatterns are a necessary and complementary companion to design patterns (see the Resources section for more information).

These repeated failed software development projects or "negative solutions" should be mined to harvest useful knowledge of "what went wrong and why." Obviously, just categorizing the causes of failure is not as useful as also examining how to avoid them and how to recover when one is encountered. When codified, this collective knowledge makes a valuable extension to software patterns and classified as antipatterns.

Antipattern is a frequently used, but largely ineffective solution to a problem. The term was originally used to refer to a design pattern gone wrong. Similarly to patterns, use of antipatterns has extended to all software development phases and beyond, to other domains. Antipatterns document commonly recurring solutions that have counterproductive effects. They typically capture refactored solution descriptions, showing how to change the antipattern into a healthier solution. Antipatterns are usually described in a template that identifies symptoms, consequences, root causes, and potential solutions. Although antipatterns are not as widely studied and written about as patterns, some of them, which have colorful monikers such as analysis-paralysis, blob, spaghetti code, and stovepipe systems, are readily recognizable by the software community. Table 2 provides an overview of some of these examples sourced from Brown et. al.'s antipatterns book (see the Resources section for more information). Why are antipatterns important?

Antipatterns are tools to prevent problems by helping to identify a problem before it becomes a problem, and by providing knowledge on how to prevent that from happening. Formal codification of failure causes allows us to intelligibly understand them. Once problems occur, antipatterns can help by explaining how to recover from them.

To summarize, antipatterns have the following elements:

• Documentation of what does not work
• A common vocabulary
• Detailed remedy
• Awareness of situation and alternative solutions
• Today's hot solution that can be tomorrow's antipattern

Figure 1 expresses the difference between patterns and antipatterns. A pattern starts with a problem that you are trying to solve and documents a repeatable successful solution to it. The solution generates some benefits, consequences and possible problems. An antipattern demonstrates a frequently used solution to a problem that has counterproductive effect. It describes the causes that led to it and also shows how to prevent or correct the solution.

SOA: brief introduction
In the last five years, much has been written about service-orientation, SOA and more recently, service-oriented everything. But what do we mean by services and service orientation? There are many different definitions -- and the definitions have changed reflecting maturity of the industry and SOA practices. We provide here some base-line definitions to be used in this article. The definitions are reflected in Figure 2.

1.  First of all, what is a service? A service is a repeatable logical manifestation of a business task. It is important to stress that we're talking about a part of a business process here -- not about software or IT.

When realized through technology, the term service applies to a software resource (discoverable) with an externalized specification. This service specification is available for searching, binding, and invocation by a service consumer. The service provider realizes the service specification implementation and also delivers the quality of service requirements to the service consumer. Services shall be governed by declarative policies and thus support a dynamically re-configurable architectural style.

2.  Second, what is service orientation? Building on our definition of a service, service orientation is a way of integrating a business as a group of linked services. We are still not talking about technology; we are talking about a new way of looking at business and how it operates.

3.  What is SOA? SOA is an architectural style that supports the service orientation. SOA is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs.

4.  And finally, what is a composite application? It's a set of integrated services. Composite applications are the actual running services that have been assembled and strung together to support what a business does. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.

Approach to identifying SOA antipatterns
SOA antipatterns were identified using the following approach:

• Surveyed literature for published antipatterns
• Documented antipatterns discovered by the authors on engagements in client meetings
• Surveyed SOA CoE and CoP members for antipatterns identified from their experiences
• Used recognized antipatterns template/language
• Antipatterns included in this presentation have been agreed upon by the three authors

Antipatterns template/language
The antipatterns are described using the following template / language:

• Name: A succinct name to convey the essence of the antipattern
• Problem / Bad solution: The commonly occurring mistake or bad solution that relates to the antipattern
• Symptoms : The indications or signs of the problem
• Consequences: The results of applying this antipattern
• Root cause: This provides the context for the antipattern, that is, where a pattern was applied incorrectly and resulting in a problem or failed solution
• Suggested solution(s): Refactored solution that solves the problem and ensures more benefits

SOA antipatterns
The identified antipatterns are classified into three categories:

1.  SOA Adoption antipatterns: These are antipatterns that hinder or delay SOA adoption by customers and businesses. Antipatterns discussed in this category are:

• A1. Technology Bandwagon
• A2. So, What's New?
• A3. The Big Bang

2.  Service identification & design antipatterns: These are antipatterns encountered while practitioners work on identifying and designing services as part of a SOA initiative. Antipatterns discussed in this category are:

• I1. Web service = SOA
• I2. The Silo Approach
• I3. Misbehaving Registries

3.  Service realization antipatterns: These antipatterns capture worst practices for realizing services. Many of these antipatterns are focused on Web services implementation; the most common realization of SOA. In this paper we identified a partial list of SOA realization antipatterns that are not focused on Web services since such antipatterns are better discussed in a forum devoted to Web services. Antipatterns discussed in this category are:

• R1. Chatty Services
• R2. Point-to-point Services
• R3. Component-less Services

As SOA matures and more engagements are conducted it is expected that more antipatterns will be identified (see Table 3).

SOA adoption antipatterns
These are antipatterns that hinder or delay SOA adoption by customers and businesses.

Antipattern name: Technology bandwidth (see also : Web service = SOA)

• Problem: We observed that many corporations embark on a SOA effort leading from an IT perspective instead of a Business one. Implementations might be technically feasible and sometimes successful, but the impact on the business may not be realized since it was never considered in the first place.
• Context: This antipattern is mostly observed in large corporations with well established IT departments that employ highly technical staff supported by strong and influential technically oriented leadership.
• Symptoms: A common symptom of this antipattern is the inability of the sponsors to articulate the value proposition of SOA adoption. Also, lack of business alignment with the projects targeted for SOA implementation could be another symptom.
• Consequences: As a result of this antipattern, the cost of IT rises without realizing any return on investment (ROI). In addition, the corporation may lose the opportunity to infuse flexibility into the IT portfolio.
• Root Cause: In most cases, the root cause of this antipattern stems from the pressure on a corporation to match or keep up with announcements from competitors who may claim leadership through the adoption of this technology. As a result, the corporation might find it easier to dive into a technology-based effort to adopt SOA without taking the time and the effort to align it with the business needs.
• Solution: The best approach to deal with this antipattern is to establish hype-free SOA value propositions which can be accomplished by identifying and describing how SOA addresses client-specific pain points or business challenges. This approach can be complemented by the development of a roadmap for proper introduction of technology in support of the business.
• Solution example: Develop a SOA platform based on hype-free SOA value propositions

A global car rental company understood the value propositions of a SOA solution that would support its key business drivers:

• Provide a flexible business model to increase speed and flexibility in delivering new business services
• Drive down costs by streamlining processes to reduce operating costs
• Reduce cycle time and costs for external business processes by providing first-to-market innovative services for its customers
• Integrate across the enterprise by enabling easy and flexible integration to support multiple delivery channels

A2: Antipattern name: So, What's New?

• Problem: This antipattern describes a situation where skeptics in a corporation claim that SOA is just a name for same old techniques and that SOA doesn't offer any thing new that they haven't been doing already. On the surface, that may appear to be so, but the emergence of Web services and XML, amongst other related standards is a major differentiator of what was done compared to what can be done with the appropriate implementation of SOA.
• Context: This antipattern is mostly adopted by IT personnel who are comfortable with the technology they have been using for an extended period of time and are reluctant to introduce or consider changes. It also appears in situations where IT departments have gone through a painful technology transformation or that the new technology didn't live up to its hype.
• Symptoms: The most obvious symptom is the strong opposition of some technical managers in a corporation to consider SOA as a serious approach to address legitimate business problems. The opposition could be in the form of strong and explicit arguments against the adoption of SOA, or it could be implicit and passive by ignoring SOA altogether while discussing approaches to solutions for business problems.
• Consequences: This antipattern most likely will foster lack of support for SOA that will result in missed opportunities to realize the SOA value propositions that will support business pain points.
• Root Cause: Though SOA builds on the same principles introduced and supported by other computing paradigms (for example, Object-Oriented and Component Based Development), many experienced IT teams lack real understanding of the differences between SOA and these other computing paradigms. This lack of understanding is one of the basic root causes of this antipattern. Another root cause is a direct consequence of IT teams having had bad experiences in implementing too many "Paradigm Shifts" and as such they are not willing to try a new one.
• Solution: One way to deal with this antipattern is to emphasize how SOA is different from earlier solutions. For example, the differences between an APIs and Services should be explored, and dependency on Open Standards and their differentiating attributes should be explained. Another major differentiator is the emergence of the Enterprise Service Bus (ESB) as an essential component of SOA. The facilities provided by an ESB such as Transport Services, Mediation Services, and Event Services, are examples of new capabilities made available by adopting SOA. However, the most effective solution is to provide successful examples that will highlight the differences and demonstrate the success and feasibility of implementing a SOA solution.
• Solution Example: SOA Education Educate both business and IT on what SOA is, its value propositions and the benefits it provides to deliver IT flexibility that is required to support business goals. Provide an understanding of the importance of the Web services and XML standards and emerging standards in the implementation of SOA that distinguishes it from past paradigm shifts.

SOA realization antipatterns
These antipatterns capture worst practices for realizing services.

Antipattern name: Chatty Services

• Problem: This antipattern describes situations where developers realize a service by implementing a number of Web services where each communicates a tiny piece of data. Another flavor of the same antipattern is when the implementation of a service ends up in a chatty dialog communicating tiny pieces of information rather than composing the data in a comprehensive document-like form.
• Context: In organizations where developers are eager to start implementing without proper modeling, they end up being victims of this antipattern. In some situations, where developers are asked to start replacing APIs with Web services and without proper understanding of how to best benefit from SOA, it usually leads to this antipattern.
• Symptoms; The need to implement a large number of too finely grained services is an indication that this antipattern is being applied.
• Consequences: Degradation in performance and costly development are the major consequences of this antipattern. Additionally, consumers have to expend extra effort to aggregate these too finely grained services to realize any benefit as well as have the knowledge of how to use these services together.
• Root cause: As a result of not knowing any better, the approach many developers take is to mimic API implementation in the form of Web services. This is very similar to the situation we encountered at the beginning of the object-oriented paradigm shift, where developers used object-oriented languages to develop procedural programs. Also, excitement to dive into this new technology could cause everything to become a web service with no benefit and excessive cost.
• Solution: To avoid this antipattern, a focused effort should be on refactoring the design to combine individual pieces of data in one document thus eliminating the chatty services. Education on differences between API and service with focus on appropriate service granularity would also help. However, the most effective approach to avoid this antipattern is to define services that map back to business goals. This can be accomplished by adopting and using a good service modeling technique to determine appropriate coarse-grained services for a business solution. This minimizes the chatty behavior of services since it has been identified at the correct level of granularity appropriate in a SOA. Applying a Service Litmus Test (SLT) would also help determine the right level of services to expose. An example of a SLT is to consider whether a service provides a required unit of business functionality that supports business processes and goals.

Antipattern name: Point-to-point Services

• Problem: The basic problem is the attempt of developers to replace a middleware solution with point to point web services as an integration approach regardless of the usage context.
• Context: This pattern is observed in organizations where there is lack of long term systems integration vision with emphasis on short term results.
• Symptoms: An indication that this antipattern is being exercised is the use of XML or SOAP over HTTP between internal applications.
• Consequences: As a result of using this antipattern, the point-to-point integration solution emerges as the defacto integration pattern for the enterprise. This will negate any potential for achieving the full advantages of proper SOA implementation.
• Root cause: A lack of consideration for the long-term maintenance and evolution of the overall system, potentially as a result of focusing on short term solutions, is the principle root cause of this antipattern. In some cases, excitement about using services everywhere could also lead to the proliferation of such point to point services approach.
• Solution: To avoid the consequences of adopting this antipattern, the use of an intelligent connector such as a Service Bus should be seriously considered as an integration approach. A Service Bus enables applications to work together simply and efficiently to support business needs while maintaining loose coupling between collaborating systems and applications.
• Known exceptions: There are some known exceptions for which the antipattern solution is acceptable. For example, a quick, short-lived integration scenario is required to solve immediate business problems and one case where point to point services could be used. However, there is a tendency for these solutions to stay in production for a long time. Thus applying this antipattern should be carefully monitored and controls should be put in place to prevent its long term adoption.

Antipattern name: Component-less Services (also known as Logical Layering is Obsolete)

• Problem: Good practices for service modeling promote associating identified services with components that own them. The problem presented by this antipattern is the tendency of developers to jump into developing and implementing Web services without having a clear association with owning components.
• Context: This antipattern appears in environments where architecture patterns are not applied or considered, for example, the layering architecture pattern. This lack of architectural discipline provides an environment that fosters the application of this antipattern.
• Symptoms: Examination of services' implementation will reveal that direct reach of any part of the system is allowed without adhering to any architectural structure. In these cases, Web services are developed without any regard to the concepts of layering and separation of concerns.
• Consequences: The most notable consequence is the inflexibility beyond the service interface since modular design, information hiding and logical structuring principles are all violated. This will lead to preservation of legacy limitations of existing applications and packages, which may prevent potential reengineering in the future.
• Root cause: As with any other situation where best practices are violated, the root cause of this antipattern is the lack of good design.
• Solution: The true potential of components and SOA will only be realized when you have both of them. Coherent service interfaces supported by flexible component-based applications is the solution. This will require developers to continue to leverage J2EE and general EAD best practices and layering patterns as a mean to overcome the shortfalls of this antipattern.
• Solution example: Understand the value of components with SOA Services are optimally realized with components. Without components, there is inflexibility behind the service interfaces, with potential concerns about scalability and portability of implementation. Existing applications and packages preserve their legacy limitations and this would minimize the ability to provide the flexibility needed to support changing business needs. Components provide the scalability and flexibility to support the service interfaces with its loose coupling and reuse features.

Summary
In this article, we reviewed some of the SOA antipatterns gleaned from observations and SOA projects that affects the adoption, identification & design, and realization of SOA.

Acknowledgements
The authors would like to thank the following colleagues for their contributions to this paper:

• JeanPierre Paillet
• Kerrie Holley
• Kyle Brown
• Mike Ellis
• Olaf Zimmermann
• Prathap Gangula
• Rick Robinson
• Rolando Franco
• Sri Ramanathan

Resources
Learn

• For more information on antipatterns, check out the following books:
• The Timeless Way of Building, by C. Alexander
• Notes on the synthesis of form, by C. Alexander
• The Oregon Experiment, by C. Alexander
• A Pattern Language: Towns, Buildings, Constructions, by C. Alexander
• Antipatterns: Refactoring Software, Architecture, and Projects in Crisis, by W. Brown, R. Malveau, H. McCormick III, and T. Mowbray
• J2EE Antipatterns, by B. Dudney, S. Asbury, J. Krozak, K.Wittkopf

• Web Services Architecture & Best Practices (IBM WebSphere Developer Technical Journal, Oct 2003) : Book excerpt that covers some of the architectural challenges posed by Web services, examines how to use (and not to use) Web services, and describes some best practices in applying Web services for solving tough architectural problems.
• " A taste of "Bitter Java"" (developerWorks, March 2002) : How antipatterns can improve your programming.
• SOA and Web services - hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
• Architecture: Build for the future - visit the new Architecture area on developerWorks and get the resources you need to advance your skills in the architecture arena.

Discuss

• developerWorks blogs: Get involved in the developerWorks community.