How to Fail With SOA: Anti-patterns for Service-Oriented Architecture
description
Transcript of How to Fail With SOA: Anti-patterns for Service-Oriented Architecture
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 [email protected] http://www.ecngroup.co.nz
[email protected] http://hestia.typepad.com/flatlander