Dr. Mamdouh Ibrahim

Subscribe to Dr. Mamdouh Ibrahim: eMailAlertsEmail Alerts
Get Dr. Mamdouh Ibrahim: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, SOA Best Practices Digest, SOA & WOA Magazine

J2EE Journal: Article

SOA Antipatterns

The obstacles to the adoption and successful realization of Service-Oriented Architecture

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

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
  • 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.
  • developerWorks blogs: Get involved in the developerWorks community.

More Stories By Jenny Ang

Jenny Ang works as an Executive IT Architect, IBM

More Stories By Luba Cherbakov

Luba Cherbakov works as an IBM Distinguished Engineer, IBM

More Stories By Dr. Mamdouh Ibrahim

Dr. Mamdouh Ibrahim works as a Senior Certified Executive IT Architect, IBM

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.