© Copyright IBM Corporation 2006

SOA Anti-Patterns
Paul Ashley and Tony Carrato
Enterprise Integration Solutions
IBM Software Group
pashley@au1.ibm.com,acarrato@au1.ibm.com
© Copyright IBM Corporation 2006
Presentation Agenda
Objectives
What are patterns
– And, thus, what are anti-patterns
Why patterns & anti-patterns are important
SOA
Anti-patterns for SOA
The project I’m working on about anti-patterns
– And how you can contribute
Where to learn more
© Copyright IBM Corporation 2006
Objectives
Identify common obstacles facing SOA from adoption to
realization
Describe the obstacles and provide suggestions for solutions
Solicit input to add to the discovered AntiPatterns
Publish the findings for the benefit of the practitioner
community
CoE
AntiPattern
ASSET
CoE
ENGAGEMENT
KNOWLEDGE
SPACE
you
© Copyright IBM Corporation 2006
A Pattern is a "generalized, named problem to solution
mapping“
A Pattern captures a successful solution to a repeating
problem in a particular context
In general, a Pattern is documented using the following:
– Name: A name used for identification
– Problem: A repeating problem that occurs in a
domain
– Solution: Best practice solution to that problem
– Consequences: Advantages and disadvantages of the
recommended solution
– Examples: A few examples where the
recommended solution has already been applied
Christopher Alexander’s research on buildings and town
design is often considered the pioneering work on Pattern-
based thinking.
© Copyright IBM Corporation 2006
Provide a mechanism to capture knowledge and experience
Provide a common vocabulary among architects and
designers
Facilitate reuse of approaches that have been successful
elsewhere and, thus, contribute towards the following
aspects of a project :
– Reducing risk
– Increasing quality
– Improving delivery time
Why Patterns are important?
© Copyright IBM Corporation 2006
Several Levels of Patterns
Business patterns that identify the interaction between users,
businesses, and data.
Integration patterns that tie multiple Business patterns together
when a solution cannot be provided based on a single Business
pattern.
Composite patterns that represent commonly occurring
combinations of Business patterns and Integration patterns.
Runtime patterns that define the logical middleware structure
supporting an Application pattern. Runtime patterns depict the
major middleware nodes, their roles, and the interfaces between
these nodes.
* Source: IBM Redbook: Patterns: Applying Pattern Approaches V2, May 2004
© Copyright IBM Corporation 2006
Several Levels of Patterns
Product mappings that identify proven and tested software
implementations for each Runtime pattern.
Best-practice guidelines for design, development, deployment, and
management of e-business applications
Will have:
– A name
– The problem solved (goal) & forces which apply
– A description of how the pattern works
• Usually with a diagram (architects love diagrams)
– An implementation section, e.g. a UML model
– Examples of use
•Source: IBM Redbook: Patterns: Applying Pattern Approaches V2, May 2004 –
http://www.redbooks.ibm.com
© Copyright IBM Corporation 2006
AntiPatterns – what went wrong …
A frequently used, but largely ineffective solution to a
problem
The term was originally used to refer to a design pattern gone
wrong
Document commonly recurring solutions that have
counterproductive effect
Typically capture refactored solution description, showing
how to change the AntiPattern into a healthier solution
Described by template or language and include identifying:
– symptoms,
– consequences
– root causes, and
– potential solutions
© Copyright IBM Corporation 2006
A Tool to Prevent Problems
Helps to identify a problem before it becomes
a problem
Provides knowledge to prevent or recover
from problems
Documents what does not work
Provides a common vocabulary
Provides detailed remedy
Provides awareness of situation and alternative
solutions
– Today’s hot solution can be tomorrow’s
AntiPattern
Why AntiPatterns are Important?
© Copyright IBM Corporation 2006
An anti-pattern is a known-not-to-work
solution to a problem
Like patterns, anti-patterns come at various levels:
– Modelling
– Project Management & Methodology
– Architecture/Design
– Assembly/Development
– Performance Management
– Testing/QA
– Deployment
– System Management
– Problem determination
Why AntiPatterns are Important?
© Copyright IBM Corporation 2006
Greater flexibility is required from the business
models and the supporting IT Architecture
Flexible Business
Transformation
Business Process Outsourcing
Mergers, Acquisitions & Divestitures
Flexible IT
Cost Containment
Greater ROI for IT dollars
Better Use if IT Assets
Improved Quality of Deployed Systems
Requires
On Demand Operating Environment
Development Infrastructure Management
Service Oriented Architecture (SOA)
Software
Development Integration
Infrastructure
Management
Composable
Services
(SOA)
Composable
Processes
(IBM
Component
Business Modeling)
S
e
r
v
i
c
e
-
O
r
i
e
n
t
e
d
M
o
d
e
l
i
n
g
© Copyright IBM Corporation 2006
“SOA in context …”
– a set of services that a business wants to expose to their customers
and partners, or other portions of the organization
– an architectural style which requires a service provider, requestor and
a service description
– a set of architectural principles, patterns and criteria which address
characteristics such as modularity, encapsulation, loose coupling,
separation of concerns, reuse, composability and single
implementation
– a programming model complete with standards, tools and
technologies such as Web Services
Business
Architecture
Implementation
What is Service-Oriented Architecture?
© Copyright IBM Corporation 2006
A SOA is composed of processes, services and
components. At the heart of the SOA is the Service Model
that defines services and components that realize them.
s
e
r
v
i
c
e

m
o
d
e
l
i
n
g
s
e
r
v
i
c
e

m
o
d
e
l
i
n
g
Composite service
Atomic service
Q
o
S
,

S
e
c
u
r
i
t
y
,

M
a
n
a
g
e
m
e
n
t

&
M
o
n
i
t
o
r
i
n
g

I
n
f
r
a
s
t
r
u
c
t
u
r
e
S
e
r
v
i
c
e
)
D
a
t
a


A
r
c
h
i
t
e
c
t
u
r
e

&

B
u
s
i
n
e
s
s

I
n
t
e
l
l
i
g
e
n
c
e
I
n
t
e
g
r
a
t
i
o
n

A
r
c
h
i
t
e
c
t
u
r
e
(
E
n
t
e
r
p
r
i
s
e

S
e
r
v
i
c
e


B
u
s
)
Operational
Existing Application Resources
Package
Custom
Application
Services
Business Processes
Components
Process Choreography
Atomic and Composite Services
4
3
2
1
6 7
Enterprise Components
Custom
Application
Package
S
e
r
v
i
c
e

C
o
n
s
u
m
e
r
S
e
r
v
i
c
e

P
r
o
v
i
d
e
r
Consumers
8
5
JService Portlet WSRP B2B
Q
o
S
,

S
e
c
u
r
i
t
y
,

M
a
n
a
g
e
m
e
n
t

&
M
o
n
i
t
o
r
i
n
g

I
n
f
r
a
s
t
r
u
c
t
u
r
e
S
e
r
v
i
c
e
)
D
a
t
a


A
r
c
h
i
t
e
c
t
u
r
e

&

B
u
s
i
n
e
s
s

I
n
t
e
l
l
i
g
e
n
c
e
I
n
t
e
g
r
a
t
i
o
n

A
r
c
h
i
t
e
c
t
u
r
e
(
E
n
t
e
r
p
r
i
s
e

S
e
r
v
i
c
e


B
u
s
)
Operational
Existing Application Resources
Package
Custom
Application
Services
Business Processes
Components
Process Choreography
Atomic and Composite Services
4
3
2
1
6 7
Enterprise Components
Custom
Application
Package
S
e
r
v
i
c
e

C
o
n
s
u
m
e
r
S
e
r
v
i
c
e

P
r
o
v
i
d
e
r
Consumers
8
5
JService Portlet WSRP B2B
© Copyright IBM Corporation 2006
Example: A pattern for successful transition to SOA
Build internal agreement for the investigation
Start with something useful but manageable
– Business and IT need to agree on an area of focus
Plan for governance and skills development
Plan to deliver success early and control costs
A useful approach is:
– An initial exercise to scope the work and the 1
st
project
– Followed by, concurrently
• Governance development
• Competency development
• An initial, manageable project
In other words – patterns aren’t always always technical
© Copyright IBM Corporation 2006
Some SOA Anti-Patterns or ways we
already know to get it wrong!
Don't do any performance engineering (Perf)
Do Web Services point to point connections
without an ESB (Arch)
Use the data model of an underlying
product, rather than the data model that
supports the business (Arch)
Try to build an SOA with back-level software
versions (Assemble)
Don't train your team on proper use of the
tools and middleware (PM)
Don't inspect the code (PM)
Don't follow modern design practices, e.g.
don't use Use Case, express architecture as
patterns, etc (PM)
Plan to deliver the project in a big bang,
rather than incrementally (PM)
Don't stress-test the system (Test)
Don't do proper business change
management (PM)
Don't understand the number of
interfaces/data formats/user types/.... you'll
have to deal with (Arch)
Don't incorporate performance testing,
prototyping during application design (Test)
Don't model business processes (Model)
Don't model in a formal way, i.e. use
PowerPoint or Visio instead of a tool that
produces UML & BPEL (Model)
Don't model the services i.e. don't use SOMA
techniques. (Model)
Don't model the software implementation
(Arch)
Write Code from scratch instead of
assembling (Assemble)
Don't have tooling training & support
including both development tools &
middleware (PM)
Don't plan testing early; don't include testers
early in the development process (Test)
Don’t do performance testing and memory
analysis for both footprint analysis and
memory leak analysis (Perf)
Don't plan for SOA-style (rapid, frequently
updated) deployment and model the
deployment infrastructure (Deploy)
Don't plan to use tooling for deployment
(Deploy)
Don't plan/architect for manageability (Sys
Mgt)
Don't involve IT operations early (applies to
"deploy" too) (Sys Mgt)
Don't plan for problem determination in a
complex environment, including log analysis
& correlation (as does this one) (PD)
Don’t plan for light weight monitoring to
monitor system in production (Sys Mgt)
Don’t allow for enough development & testing
infrastucture (PM)
© Copyright IBM Corporation 2006
Problem
– Equating SOA with Web Services
Symptoms
– Replacing existing APIs with Web Services without proper architecture
– Services are not business aligned
Consequences
– Proliferation of Web Services
– It is likely those existing systems will not have interfaces that reflect the
requirements of the service requestor
Root Cause
– Haste: “I can take short-cuts and do this SOA stuff quickly and cheaply”
– Ignorance
Solution
– Develop a viable SOA transition plan with defined SOA value proposition
– Education on SOA vs. Web Services
– Apply good Service Modeling (e.g, SOMA)

AntiPattern Name: Web Service = SOA
(also known as Service Proliferation Syndrome)
I1
© Copyright IBM Corporation 2006
Web Services can be a part of the answer ...
Service-Oriented Architecture (SOA) is another part
The two are not the same thing:
– Most of today's production Web Services systems aren't service
oriented architectures - they're simple remote procedure calls or point-
to-point messaging via SOAP or well structured integration
architectures.
– Most of today's production service oriented architectures don't
primarily use Web Services - they use ftp, batch files, asynchronous
messaging etc. - mature technologies.
Achieving the promoted benefits of SOA and Web Services,
requires both
Solution: Education on SOA vs. Web Services
Are Web services the answer?
I1
© Copyright IBM Corporation 2006
Solution: Apply good service modeling method like IBM’s SOMA
Ultimately, the goal of SOMA* is to build a SOA.
Q
o
S
,

S
e
c
u
r
i
t
y
,

M
a
n
a
g
e
m
e
n
t

&
M
o
n
i
t
o
r
i
n
g

I
n
f
r
a
s
t
r
u
c
t
u
r
e
S
e
r
v
i
c
e
)
D
a
t
a


A
r
c
h
i
t
e
c
t
u
r
e

&

B
u
s
i
n
e
s
s

I
n
t
e
l
l
i
g
e
n
c
e
I
n
t
e
g
r
a
t
i
o
n

A
r
c
h
i
t
e
c
t
u
r
e
(
E
n
t
e
r
p
r
i
s
e

S
e
r
v
i
c
e


B
u
s
)
Operational
Existing Application Resources
Package
Custom
Application
Services
Business Processes
Components
Process Choreography
Atomic and Composite Services
4
3
2
1
6 7
Enterprise Components
Custom
Application
Package
S
e
r
v
i
c
e

C
o
n
s
u
m
e
r
S
e
r
v
i
c
e

P
r
o
v
i
d
e
r
Consumers
8 5
JService Portlet WSRP B2B
Q
o
S
,

S
e
c
u
r
i
t
y
,

M
a
n
a
g
e
m
e
n
t

&
M
o
n
i
t
o
r
i
n
g

I
n
f
r
a
s
t
r
u
c
t
u
r
e
S
e
r
v
i
c
e
)
D
a
t
a


A
r
c
h
i
t
e
c
t
u
r
e

&

B
u
s
i
n
e
s
s

I
n
t
e
l
l
i
g
e
n
c
e
I
n
t
e
g
r
a
t
i
o
n

A
r
c
h
i
t
e
c
t
u
r
e
(
E
n
t
e
r
p
r
i
s
e

S
e
r
v
i
c
e


B
u
s
)
Operational
Existing Application Resources
Package
Custom
Application
Services
Business Processes
Components
Process Choreography
Atomic and Composite Services
4
3
2
1
6 7
Enterprise Components
Custom
Application
Package
S
e
r
v
i
c
e

C
o
n
s
u
m
e
r
S
e
r
v
i
c
e

P
r
o
v
i
d
e
r
Consumers
8 5
JService Portlet WSRP B2B
<< Output to: SOA Implementation >>
Realization
Decisions
Specification
of Services, Components, Flows
Identification
of candidate Services, Components, Flows
<< Input from: Business Componentization/Analysis >>
At the heart of SOMA is the identification and specification of services.
I1
* See http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/ for
more information on SOMA
© Copyright IBM Corporation 2006
AntiPattern Name: Chatty Services
Problem
– Realize a service by implementing a number of Web Services where
each communicate a tiny piece of data
Symptoms
– Implementation of a large number of services
Consequences
– Degradation in performance
– Costly development
– Burden the consumer with the task of aggregating these services to
realize any benefit
Root Cause
– Mimic API implementation
– Excitement: everything becomes a BPEL-defined business service,
with no benefit and excessive cost
Solution
– Refactor design to combine individual pieces of data in one document
– Education on difference between API & service; granularity
– Apply Litmus test
– Map services back to business goals
TechnoIogy TechnoIogy TechnoIogy
R1
© Copyright IBM Corporation 2006
Solution: Refactor Design to combine pieces of data in one document
Do Not Use Fine-Grained Calls
SOAP Engine
Generated SOAP
stub
EJB
(controller/model)
Swing
(view/controller)
Java Application
SOAP
over
HTTP
WebSphere
Application Server
Presentation
Layer
Business
Layer
SOAP Engine
Web Service
Examples of bad
Services
getFirstName
getLastName
getOfficePhone

Bad: Using WS
between WAS
application servers
(no firewall issues,
fine grained
interaction)
Source: SOA/WS bootcamp
R1
© Copyright IBM Corporation 2006
Solution: Apply Litmus Test
Support only those that pass the Litmus Tests
SLT1: Business
Alignment
Services to be
Exposed
SLT2:
Composability
SLT3:
Externalized
Service
Description
Service Model:
candidate services
SLT4: Redundancy
Elimination
S0
S1
S2
S3
Business Goals Candidate Services
SLT 1-1 : Does the service provide a
required unit of business functionality that
supports business processes and goals?
each composed of multiple criteria
“From all candidate services,
which should we expose?”
R1
© Copyright IBM Corporation 2006
Problem
– Replacing middleware with point to point web services as an integration approach
Symptoms
– Using XML or SOAP over HTTP between Applications
Consequences
– Point-to-point integration emerges as the defacto integration pattern
Root Cause
– Excitement about using services everywhere
– A lack of consideration for the long-term maintenance and evolution of the overall
system
Solution
– Use an intelligent connector such as a Service Bus
Known Exceptions
– When quick, short-lived integration is required to solve immediate business
problems, but tend to be in production for a long time
Name: Point-to-Point Services
TechnoIogy TechnoIogy TechnoIogy
R2
© Copyright IBM Corporation 2006
Solution: Use an intelligent connector such as a Service Bus
Service Bus enables applications to work together
simply and efficiently to support business needs
A
A
B
B
H
H
D
D
F
F
C
C
E
E
G
G
A
A
B
B
H
H
D
D
F
F
C
C
E
E
G
G
ESB
ESB
Applications
Applications
Tight coupling and complex - Each
application has to be aware of the details of
other applications it has to collaborate with.
Loose coupling and simpler - The service bus
shields each application from the details of
other applications it has to collaborate with.
R2
© Copyright IBM Corporation 2006
Out SOA anti-patterns project
Working with an IBM team to:
– Identify SOA anti-patterns
– Catalogue them for future reference
– Develop education on anti-patterns
• And plan to publish our results on IBM DeveloperWorks
(http://www.ibm.com/developerworks)
© Copyright IBM Corporation 2006
We’d like to hear from you about SOA anti-patterns
We’re very interested in anti-patterns you
observe
Ideally, they will be from real projects
With some sense of the impact of the anti-pattern
If you discover some, send a note to Tony or Paul
© Copyright IBM Corporation 2006
Where to learn more
AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis by William J. Brown, Raphael C. Malveau, Hays W. "Skip"
McCormick, and Thomas J. Mowbray (Paperback - Mar 20, 1998)
Service-Oriented Architecture (SOA) Compass : Business Value,
Planning, and Enterprise Roadmap (Developerworks) (Hardcover)
Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn
Shah IBM Press
Perspectives on Web Services : Applying SOAP, WSDL and UDDI to
Real-World Projects (Springer Professional Computing) (Hardcover) by
Olaf Zimmermann, Mark R. Tomlinson, Stefan Peuser ISBN 3540009140
SOA Anti-Patterns article by Steve Jones, CGI
– http://www.infoq.com/articles/SOA-anti-patterns
– Also check out Steves Blog @ http://service-architecture.blogspot.com/
– Search for anti-patterns or patterns
© Copyright IBM Corporation 2006
Where to learn more
AntiPatterns.com www.antipatterns.com
– Has a nice briefing on anti-patterns
Rational Software Architect or Rational Application Developer
– Check the help file both can support searching for anti-patterns
DeveloperWorks SOA Anti-Patterns page:
ww.ibm.com/developerworks/webservices/library/ws-antipatterns/
– And many others; search for anti-patterns
IBM Redbooks
– http://www.redbooks.ibm.com
© Copyright IBM Corporation 2006
7/+-e q-«

Japanese
English
French
Russian
German
Italian
Spanish
Brazilian Portuguese
Arabic
Traditional Chinese
Simplified Chinese
Thai
Korean