SOA Anti Patterns

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
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 Im working on about anti-patterns
And how you can contribute
Where to learn more
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
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 Alexanders research on buildings and town
design is often considered the pioneering work on Pattern-
based thinking.
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?
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
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
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
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
Todays hot solution can be tomorrows
AntiPattern
Why AntiPatterns are Important?
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?
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
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?
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
Package
Custom
Application
Services
Business Processes
Components
4
3
2
1
6 7
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
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 arent always always technical
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)
Dont 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)
Dont plan for light weight monitoring to
monitor system in production (Sys Mgt)
Dont allow for enough development & testing
infrastucture (PM)
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
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
Solution: Apply good service modeling method like IBMs 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
Package
Custom
Application
Services
Business Processes
Components
4
3
2
1
6 7
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
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
Package
Custom
Application
Services
Business Processes
Components
4
3
2
1
6 7
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
<< 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
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
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
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
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
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
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)
Wed like to hear from you about SOA anti-patterns
Were 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
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
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
7/+-e q-
Japanese
English
French
Russian
German
Italian
Spanish
Brazilian Portuguese
Arabic
Traditional Chinese
Simplified Chinese
Thai
Korean

SOA Anti Patterns

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOA Anti Patterns

Uploaded by

Copyright:

Available Formats

Copyright IBM Corporation 2006

You might also like