HOW TO FAIL WITH SOA:ANTI-PATTERNS FOR SERVICE-ORIENTED ARCHITECTURE

Ivan Towlson, ECN Group

Agenda Motivation Adoption anti-patterns Identification anti-patterns Realisation anti-patterns Discussion

Why SOA? Add business value Return on investment Reusable for multiple applications Interoperability, self-describing Policy-driven configuration Unified governance 2.0 Semolina pilchard climbing up the Eiffel

Tower

Why Anti-Patterns? Why do we need to know how to screw

up? So we can get promoted to

management

What is a Pattern? Can use the same solution a million

times without ever doing it the same way twice.

Technology independent – can apply solution equally regardless of underlying technology

What is an Anti-Pattern? Can make the same mistake a million

times without ever doing it the same way twice.

Technology independent – can foul upequally regardless of underlying technology

What is an Anti-Pattern? A common set of circumstances and a

response which is obvious, attractive and wrong

The antipattern describes: How you are likely to get here Why you don’t want to be here A resolution to the problem (“refactored

solution”) Use antipatterns constructively

Taxonomy Adoption – the decision to implement a

service-oriented architecture Identification – the design and structure

of the service set Realisation – the implementation and

construction of an individual service

Adapted from Ang et al, SOA Antipatternshttp://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/

Adoption Anti-Patterns

Technology Bandwagon Problem: SOA adoption driven by

technology fashion instead of business need

Symptoms: Nobody can express how the SOA effort is going to help the business, or document how it has helped it

Cause: Keeping up with the Joneses Refactored solution: Hype-Free Value

Proposition

Big Bang Also known as: Boiling the Ocean Problem: Attempt to move all business

services to SOA at the same time Symptoms: Spiralling cost and risk,

death march Cause: Overambition, hype Refactored solution: Business Supported

Roadmap

Laundry List Benefits Also known as: SOA Silver Bullet Problem: Unrealistic expectations of

SOA value Symptoms: “Once we have the SOA, all

our time/cost/complexity/interoperability/ management/etc. problems will be over!”

Cause: Consultants, usually Refactored solution: Dose of Reality

Identification Anti-Patterns

SOA = Web Services Problem: No consideration given to the

content and factoring of services, only to the technology

Symptoms: “We’re fully SOA-compliant – we use WSE.”

Cause: Service design driven by technical experts, not business experts

Refactored solution: Business Driven Services

Balkanisation Also known as: Service Silos Problem: Services built around

applications, so each application exposes similar but different “services”

Symptoms: “And this is the PeopleSoft service.”

Cause: Service design driven by balkanised business or technology groups

Refactored solution: Governance

One-Click Services Also known as: Technology Granular Problem: Services are thin wrappers

around existing code, with no business abstraction

Symptoms: Interfaces look suspiciously like COM objects, green screens or sprocs – but with XML

Cause: Oh-so-seductive “make a Web service in just one click” checkboxes and frameworks

Refactored solution: Business Driven Facade

Realisation Anti-Patterns

Uberservice Problem: A single service that takes

arbitrary XML Symptoms: Uh, a single service that

takes arbitrary XML Cause: “We just wanted to allow for

future changes.” Refactored solution: Granular Services,

Evolution Through Versioning

Chatty Protocol Problem: Fine-grained operations Symptoms: Operations involve multiple

service calls (network round-trips), with corresponding performance impact

Cause: In-process thinking (e.g. OO) transferred to messaging environment, often helped along by frameworks that disguise the transition

Refactored solution: Messages As Documents

Point to Point Problem: Applications send messages

directly to services Symptoms: Changes to cross-cutting

concerns (e.g. logging), business processes and application topology are costly and complex to implement

Cause: Add Web Reference, HTTP fixation, overhead of middleware

Refactored solution: Message Bus / Broker

Irresponsible Implementation Problem: Design discipline breaks down

within the service Symptoms: Implementation of changes

to services, or new services, is costly and unpredictable

Cause: “But we’re service-oriented now, not object-oriented!”

Refactored solution: Service Facade

Expose Business Objects Problem: Business objects in service

interface Symptoms: Business object designs

distorted to meet toolkit requirements (e.g. XmlSerializer); unstable service contract

Cause: “This is easy! You just add [WebMethod]!”

Refactored solution: Message Objects or Contract Metadata

Expose Implementation Problem: Service exposes implementation

details Symptoms: Technology changes in one

application affect every other application; “It returns an EDIFACT message” (or DataSet)

Cause: Design team aligned to back-end host application rather than to business function

Refactored solution: Messages As Documents

Dependent Client Problem: Client application code depends

on service contract Symptoms: Cannot switch to alternative

service provider (or new service version) without major client rewrite

Cause: Development team aligned to “service as API” rather than required business function

Refactored solution: Service Agent

Themes Business driven

Not application-driven Not IT-driven

Message-centric / document-centric The Ron Jacobs metaphor: departments,

messengers and envelopes – it was good enough for the 1920s and it’s good enough for us

Summary Adoption

Technology Bandwagon, Big Bang, Laundry List Benefits

Identification Web Services = SOA, Balkanisation, One-Click Services

Realisation Uberservice, Chatty Protocol, Point to Point,

Irresponsible Implementation, Expose Business Objects, Expose Implementation, Dependent Client

For Discussion How do we unpick SOAs that have fallen victim? What other areas do we need to attend to? (E.g.

management, governance.) What anti-patterns have we observed in these areas?

How can IT achieve the necessary engagement of the business? How do we organise for success? What procedures do we introduce for review etc.? Any other stakeholders?

What improvements to our frameworks and tools would help? (Linguistic constructs? DSLs? Designers?)

Is SOAP itself an anti-pattern?ivan.towlson@ecngroup.co.nz http://www.ecngroup.co.nz

ivan@hestia.cc http://hestia.typepad.com/flatlander