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.

Back to top

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.

Back to top

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.

Back to top

SOA adoption antipatterns

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

A1: 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.

A3: Antipattern name: The Big Bang (also known as: Bite more than you can chew)

• Problem

  This antipattern can be thought of as the extreme opposite of the "So, What's New" antipattern. Here the problem is that the advocate view SOA as a panacea, leading to a push to change all the enterprise systems and architecture at once.

• Context

  This antipattern shares the same context as the Technology Bandwagon antipattern. In particular those enterprises where major stake holders are very technically oriented and are more influential than their business counterparts, you can expect them to try to "bite more than they can chew" regardless of the effect on the business.

• Symptoms

  Overwhelming concerns from business units about the proposed changes to adopt SOA is a clear indication that this antipattern has been exercised.

• Consequences

  A result of applying this antipattern is serious failure to deliver on the promised benefits of SOA, which may lead to a return to existing architecture thus delaying or even eliminating any potential benefit from SOA. Another consequence of exercising this antipattern is to blame any failure to deliver on SOA rather than finding the root cause of the problem.

• Root cause

  Zealous technologists in any enterprise can be the root cause of such an antipattern, particularly if these technologists are in a position to make IT decisions override business concerns.

• Solution

  To eliminate this antipattern, one solution is to develop a business supported roadmap to move towards SOA incrementally. Instead of trying to solve all the enterprise problems through sweeping changes using SOA, it would be better to adopt an incremental approach by building a business case for a pilot first, then when the pilot is successful, use the roadmap to select the next target business area for which SOA would be beneficial. It will also be helpful if education on SOA entry points is made available to those in the organization that are responsible for the push to SOA.

• Solution example: Develop a roadmap to implement SOA

  Given its business strategy, a major bank determined that a SOA solution was the appropriate architectural direction that would enable it to meet its business goals. It first conducted an assessment of its maturity level in terms of service integration. Then a roadmap was developed to enable the bank to incrementally migrate to a SOA environment so as to minimize risks while continuing to provide the necessary business functionality. A pilot project was selected to validate the SOA architectural style and to work out any technology and organizational issues while moving to this SOA paradigm.

Back to top

SOA identification & design antipatterns

These are antipatterns encountered while practitioners work on identifying and designing services as part of a SOA initiative.

I1: Antipattern name: Web service = SOA (also known as Service Proliferation Syndrome)

• Problem

  To many, SOA is just another name for web services. Though implementing web services is a legitimate entry point towards SOA adoption, enterprises should not equate web services with SOA.

• Context

  Most of today's production web services systems are not SOAs. They're simple remote procedure calls or point-to-point messaging through SOAP or well structured integration architectures. Organizations find it easier to claim a move to SOA by only implementing web services.

• Symptoms

  Replacing existing APIs with web services without proper architecture as well as implementation of services that are not business aligned are obvious symptoms of this antipattern.

• Consequences

  Proliferation of web services is a direct consequence of the application of this antipattern. This is a result of implementing any interface as a web service regardless of whether these services are part of a SOA value proposition or not. Also, it is likely that the resulting systems will not have interfaces that reflect the requirements of the service requestor.

• Root cause

  Root causes for this antipattern fall in two categories. The first is haste, where the intent is to take short-cuts and do this SOA stuff quickly and cheaply. The second is ignorance of the difference between SOA and Web Services and lack of understanding the need for good service modeling techniques.

• Solution

  An approach toward addressing this antipattern is to develop a viable SOA transition plan which requires organizations to define their SOA value proposition. Achieving the SOA value propositions requires both SOA and web services. This will require education on SOA versus web services as well as applying good service modeling method such as SOMA (Service-Oriented Modeling and Architecture).

• Solution example: Apply service modeling to identify coarse-grained services and leverage web services as the implementation technology for a SOA solution

  Adopt and use a good service modeling technique to determine appropriate coarse-grained services for a business solution and leverage web services to implement a SOA solution. The right level of service granularity would help minimize the proliferation of services that are too fine-grained. Achieving the value propositions of SOA requires both SOA and web services.

I2: Name: The Silo Approach

• Problem

  The problem presented by this antipattern is a result of the way services are identified. When services are identified based on isolated applications rather than focusing on the enterprise strategy, the benefits expected from SOA implementation never materialize.

• Context

  Enterprises that are organized based on a functional model with towers that are working in isolation are prime candidates for this antipattern. The autonomy each functional tower enjoys lead to the working in a silo approach.

• Symptoms

  Observing that same services are identified by different groups with different names is a symptom of this antipattern. Failure to identify common services or lack of realizing service sharing is also a clear indication that this antipattern has being applied.

• Consequences

  Since services are identified and implemented multiple times as a result of the silo approach, costly development of unnecessary or duplicate services negates the benefits promised from adopting SOA. Furthermore, reuse between stake-holders of different applications diminishes or is completely eliminated as a result of this antipattern.

• Root cause

  In most cases, organizational boundaries and constraints are the root cause of this antipattern. In some enterprises, the lack of a disciplined approach to "service exposure decisions" is attributed as the root cause.

• Solution

  The solution to this antipattern is to establish a governance framework that will ensure cross tower service identification and communications. Also, a focused effort on identifying common services should be initiated and enforced. This can be accomplished using a good service modeling method such as SOMA.

• Solution example: Identifying common services

  Like most corporations, a major bank was organized by business towers which provided similar business functionality to different types of bank clients. SOMA was applied to develop a service model to facilitate and understand opportunities of reuse across the business towers. At a high level, about 90 percent of the business services that were needed to support business functionality were found to be similar and were potential areas of reuse.

I3: Antipattern name: Misbehaving Registries

• Problem

  UDDI adoption without an agreed upon SOA governance model leads to process inefficiencies as well as design inefficiency. In particular duplicate registries can cause inefficiencies resulting in bad performance as well as creating security and compliance holes.

• Context

  Enterprises that do not have an agreement on the registry governance but attempt to establish UDDI usage will often encounter this antipattern.

• Symptoms

  Given that UDDI is a standard and not a product, its improper use can lead to the establishment of duplicate service registries and overlapping, unclear ownerships. This will manifest itself in the form of incorrect, misleading service interface information particularly during the discovery of composite service scenarios within a shared services model. Despite individual service interfaces having the correct description in the registry, duplicate entries will result in the discovery of incorrect whole services. Furthermore, lack of a governance model could result in services that are registered along various stages of life cycle process but become abandoned when there is no one to one ownership transfer. For example: a developer may add three services in to the internal UDDI. Then the service administrators may pick only two of them to be moved to the production UDDI. This results in orphaned services. A similar situation may arise with the service components.

• Consequences

  Duplicate registries will create governance nightmare and runtime confusion in trying to identify which service in which registry that is causing failure to meet SLAs. Additionally, potential bad performance and security and compliance holes could result from such duplication. Unplanned costs due to duplication are also another consequence of this antipattern.

• Root cause

  Lack of design-time coherence (SOA governance model) is the leading cause of this antipattern. In particular, unclear service registry ownership and lack of establishing and enforcing enterprise level SOA reference architecture are at the core of the problem.

• Solution

  To avoid this antipattern, a corporation must establish a SOA governance model that defines and adopts service registry best practices, ownership, and communications across related teams. This would eliminate duplicate and incorrect service interface information and minimize the consequence of having orphaned services. Runtime confusion would also be eliminated since there is only one source of service descriptions which include the associated SLAs and policies. Establishing and enforcing compliance with a SOA enterprise level reference architecture should be the first step towards the institutionalization of a SOA governance model.

Back to top

SOA realization antipatterns

These antipatterns capture worst practices for realizing services.

R1: 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.

R2: 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.

R3: 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.

Back to top

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.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Patterns versus antipatterns
• SOA: brief introduction
• Approach to identifying SOA antipatterns
• Antipatterns template / language
• SOA antipatterns
• SOA adoption antipatterns
• SOA identification & design antipatterns
• SOA realization antipatterns
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers