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

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.