22-10-2008
This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com
Founding Sponsors
Platinum Sponsors
Gold Sponsors Silver Sponsors
Guerrilla SOA
How to fight back when a vendor takes control of your enterprise
Dr. Jim Webber
http://jim.webber.name
1

22-10-2008
Fundamental Premise
There are two things money cannot buy:
1. Love
(Lennon/McCartney)
2. An SOA
(Webber)
Roadmap
• Enterprise Application Integration Approaches
• Enterprise Architecture, now and future
• The Appealing Rationale for ESB...
• Enterprise Architecture
• Realising SOA with Web Services, Or
• Realising SOA with the Web
• What this means for you
• Conclusions
• Q&A
2

22-10-2008
Integration Approaches
• Data integration
– Extract, transform, route, inject data
• Application level
– Re-use application APIs, or I/O mechanisms
• EAI implementation
– Queues etc
• Business domain tier
– Integration at the object level, as typified by CORBA,
DCOM etc
• User interface
– Screen scraping, revamping, etc.
– Last resort, when an application offers no other hooks
To ESB or not to ESB, that is the question
• Product vendors are keen to provide
product solution for everything
– Or to supply “consultantware” solutions
• The Enterprise Service Bus is the latest
incarnation of EAI technology that
supports a number of useful functions:
– Transformations; adapters; choreography;
reliability; security etc
• Seems like a good idea...
3

22-10-2008
Today’s Enterprise Architecture
Accounting Marketing
Product Development Support
How did we get here?
• Tactical decisions
• Time and technology pressures
• Path of least resistance for individual
applications
• This is the thin end of the wedge,
technical debt can only increase from
here
• Help!
4

22-10-2008
Vendor Solutions Appear
• Business needs to
compete
– IT needs to be responsive
• SOA gives IT a business
process focus
• Web Services are the
most sensible way to
implement SOA
• More proprietary
middleware is the
answer!
– 2+2=5 http://www.capeclear.com/technology/index.shtml
Integration Two Years Later
Accounting Marketing
Enterprise Service Bus
Product Development Support
5

22-10-2008
Skeletons in the Closet...
Enterprise Service Bus
The Appealing Rationale for ESB...
• Perceived single framework for all
integration needs
• Perceived simple connectivity between
systems
• Some features for security, reliable
delivery, etc.
• All you have to do is agree to lock
yourself into a ESB and all this can be
yours...
6

22-10-2008
...And the Reality
• The mess is swept under the carpet hidden inside
a vendor box
– Mixing business rules, transformations, QoS etc with
connectors
• Vendor lock-in of the whole network!
– ESBs are proprietary, so no guarantees that the
messages transmitted across the bus are actually
based on any open protocol
• Held to ransom by the ESB vendor!
– Can only easily integrate systems for which the ESB
vendor provides specific adaptors
– Or invest your money into extending their product
Intelligent Networks, Dumb Idea?
• Isn't this precisely what we're trying to
get away from?
• Integration should happen on the wire by
default, not inside some server
• The ESB approach eschews the dumb
network
– Smart endpoints underpin scalable, robust
systems
– Smart networks are failure points
7

22-10-2008
More plumbing gets built
SOA “experts” grow powerful
8

22-10-2008
And ESB software grows…
… the wrong way
9

22-10-2008
On a rich diet
Transformations
BPM
Security
GUI Tools
Reliability
Low
Rules Latency
Engine
Adapters
Integration five years from now
Accounting Marketing
IT
Research
Enterprise Service Bus
Product Development Support
10

22-10-2008
Integration ten years from now
Accounting Marketing
IT
Research
ESB
Product Development Support
Architectural Fantasy
11

22-10-2008
Ungovernable
Doesn’t Scale
12

22-10-2008
How did this happen?
• Same old story:
– Tactical decisions
– Time and technology pressures
– Path of least resistance for individual applications
• Centralised ownership of the ESB sometimes is an
inhibitor
– Too much effort to get on the bus, technically,
politically
– Individuals always mean to redress hacked
integrations
– But seldom do – it’s too hard when systems are live
Spaghetti is a fact of life
• Businesses change
• Processes change
• Applications change
• Integration changes
• Need an enterprise computing strategy that:
– Reflects the changing structure of the business;
– Is spaghetti-friendly;
– Commoditised;
– Robust, secure, dependable, etc.
13

22-10-2008
Business-Led Integration
• ESBs integrate with whatever existing systems expose
– Green screen, web pages, CORBA objects, XML, etc
• Integration happens at a low level
– Mapping of bits and bytes of one variety onto bits and bytes of
another format
• This makes it hard to engage business in such projects
– Without business benefit no software has value
• Integration is currently opaque to the business
• Business must be involved in integration projects – not just
initiate them
– The integration domain must use the same vocabulary as the
business domain
Spaghetti-Oriented Architecture
• Fighting against spaghetti is usually unsuccessful
– This does not mean integration should be
undertaken without diligence!
• SOA is an approach which is spaghetti-agnostic
• Services are designed for integration with any
consumer
– Integration is decentralised
• Result:
– Loosely coupled, re-usable services
– Focus on business-meaningful process orchestration
14

22-10-2008
SOA and Web Services Approach
• Applications (or subsets of applications) are
identified as being service-amenable
– Or (sub) processes are identified for which there is no
existing application/service
• Web Services infrastructure is layered on top of the
application, exposing a SOAP interface to the rest of
the network
– Business meaningful message exchanges
• Other services consume the functionality via SOAP
message exchanges
• Traditional integration infrastructure is kept within
the Web Service implementation, if used at all
Building the Service-Oriented
Enterprise
• SOAP becomes the ubiquitous transfer mechanism
across the enterprise (or Internet!)
• In effect, SOAP messages are the “EAI backbone”
– The underlying transport protocols are arbitrary
• Applications understand SOAP messages natively
– True end to end integration, but maintains loose coupling
• In this context, existing ESB/EAI software becomes a
toolkit for implementing individual Web Services
• But integration happens at the SOAP level
– Can commoditise what’s underneath
15

22-10-2008
Decentralised Integration
• The QoS functionality
that a Web Service
requires is implemented
on a per-service basis
– Not “one size fits all”
• Implement only those
QoS protocols that the
service currently needs
– Push the integration Transactions
functionality to the Security
edges Reliable Delivery
• SOAP + WS-Addressing Non-Repudiation
becomes the “bus”
• Incremental and
autonomous
– Deliver high business-
value services first!
Application Integration...
• EAI/ESB frameworks are fine for application
integration
– A framework for development of (distributed) applications
• Think of the EAI toolkit as a container for your
application
– Application versus enterprise framework
Application Domain
Adapter Adapter Adapter
Bus
Choreography/Rules/Routing/Transformations
16

22-10-2008
...and Composite Business
Processes
• Processes across the enterprise consume
and coordinate lower-level applications
– Exposed via standards-based services
Application Domain Enterprise Process Domain
Adapter Adapter Adapter
Bus
Gateway
Choreography/Rules/Routing/Transformations
SOAP
Messaging,
WS-*
Metadata, Metadata, Metadata…
<mex…>
…
</mex>
<wsdl…>
<policy…>
…
</policy>
…
<endpoint…> </wsdl>
…
</endpoint>
17

22-10-2008
Policy and Contract
<wsdl…>
<policy…>
<security-policy>
…
</security-policy>
<transaction-policy>
<wsdl…>
…
<policy…>
</transaction-policy>
…
<reliability-policy>
</policy>
…
…
</reliability-policy>
</wsdl>
…
</policy>
…
</wsdl>
Proxy Generation
<wsdl…>
Consumer Implementation <policy…>
<security-policy>
…
Web Services Client Stack (WCF)
Proxy API </security-policy>
<transaction-policy>
Security Handler …
</transaction-policy>
<reliability-policy>
Tx Handler …
</reliability-policy>
RM Handler …
</policy>
…
</wsdl>
18

22-10-2008
End-to-End Messaging
Consumer Implementation Service Implementation
Web Services Client Stack (WCF)
Web Services Client Stack (WCF)
Proxy API Proxy API
Security Handler Security Handler
Tx Handler Tx Handler
RM Handler RM Handler
Transport
“WS-Fabric”
Administrative
domain
Service
Service
Administrative
Service
Administrative
domain
domain
Service
network
Service
Service
SOAP messaging is the communication channel for applications.
The ESB (if it exists) is pushed to the endpoints.
19

22-10-2008
Same Old Architects
• Business and IT people collaborate around
automating business processes
– Re-using those processes (services) already
deployed into the service ecosystem
• Service architects and developers build
services
– Using WS toolkits like WCF and Axis
– Or RESTlet, NetKernel, ASP.Net MVC, Rails, etc
• Enterprise architects spread best practices
– and undertake necessary governance roles
ESB xorSOA?
• Investing in proprietary integration
systems now is investing in future legacy
• ESB is not the solution
– It’s oh-so 1990’s integration glue
• SOA is the solution
– Because it focuses on supporting business
processes
• Web Services are a robust and
commoditised platform for SOA delivery
20

22-10-2008
Conclusions
• SOA is the right integration architecture going forward
– SOA can be implemented incrementally
– Drive SOA from a business perspective
It looks like you’re
• Most valuable processes/applications/services first
trying to build an
SOA...
– Commoditisation across the board
• Servers, developers, networking, re-use existing software, etc
• Migrating towards a successful SOA is not always easy
– Learning to build dependable SOAs can be difficult
– ESBs and Wizards cannot help – you need service-savvy geeks and
process-aware business people
• No centralised integration middleware needed!
Quote of the Day
“…the idiots that are running around
yelling "guerrilla SOA" have to be put
in their place.”
Quoted on InfoQ:
http://www.infoq.com/news/2007/11/so
a-long
21

22-10-2008
Questions?
GET /Connected
Jim Webber
SavasParastatidis
Ian Robinson
Expected Q1 2009
Blog:
http://jim.webber.name
22