390 likes | 597 Views
Fundamental Premise. There are two things money cannot buy:Love (Lennon/McCartney)An SOA (Webber). Roadmap. Enterprise Application Integration ApproachesEnterprise Architecture, now and futureThe Appealing Rationale for ESB...Enterprise ArchitectureRealising SOA with Web ServicesWhat this me
E N D
1. Guerrilla SOAHow to fight back when a vendor takes control of your enterprise Dr. Jim Webber
Service-Oriented Systems Practice Lead
ThoughtWorks
http://jim.webber.name
2. Fundamental Premise There are two things money cannot buy:
Love(Lennon/McCartney)
An SOA(Webber)
3. Roadmap Enterprise Application Integration Approaches
Enterprise Architecture, now and future
The Appealing Rationale for ESB...
Enterprise Architecture
Realising SOA with Web Services
What this means for you
Conclusions
Q&A
4. Enterprise Application 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
5. 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...
6. Today’s Enterprise Architecture
7. 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!
8. 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 See: http://www.capeclear.com/technology/index.shtml
9. Integration Two Years Later
10. Skeletons in the Closet...
11. 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...
12. ...And the Reality The mess is swept under the carpet
The spaghetti is still there, but it’s hidden inside a vendor box
But the spaghetti is worse with an ESB
Mixing business rules, transformations, QoS etc with connectors
What if I wanted to remove or replace my current ESB platform?
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!
Cannot easily replace one ESB with another
Can only easily integrate systems for which the ESB vendor provides specific adaptors
Or invest your money into extending their product
13. 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 endpoint notion that underpins scalable, robust systems
ESB vendors are the new telcos – telling us that smarts in the network is for our own good
But let’s see how ESBs play out over the longer term
14. Integration five years from now
15. Integration ten years from now
16. 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
17. 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.
18. 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
19. 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
20. 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
21. 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 SPDB story – can run an enterprise reliably on commodity software IF you plan and execute correctly.SPDB story – can run an enterprise reliably on commodity software IF you plan and execute correctly.
22. 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 functionality to the edges
SOAP + WS-Addressing becomes the “bus”
Incremental and autonomous
Deliver high business-value services first! Decentralised Integration
23. 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
24. ...and Composite Business Processes Processes across the enterprise consume and coordinate lower-level applications
Exposed via standards-based services
25. Web Services Standards: The State of Play Not all of the WS-* QoS protocols are ready yet
Generally in late stages of standardisation and early adoption
WS-Security is ready; WS-ReliableExchange (WS-RX) in standardisation; WS-AT/BA ready on Java platform; WS-AT on .Net
Web Services toolkits for the rest will be available in the next year or so
WCF, BizTalk, Axis2, XFire, etc
Metadata is the key!
26. Metadata, Metadata, Metadata…
27. Policy and Contract
28. Proxy Generation
29. End-to-End Messaging
30. WS-Security Mature, widely implemented, and interoperable
WS-I Basic Security Profile too
Gives end-to-end security
Privacy, integrity
Can be used for authentication, non-repudiation
31. Reliable SOAP Messaging Non-interoperable implementations from two competing standards today
WS-Reliability
WS-ReliableMessaging
Single, unified standard (WS-ReliableMessaging) being developed (by WS-RC committee)
Not yet widely implemented
Cannot achieve interoperable RM at the SOAP level today
Instead, use existing, mature, transports
MQ, JMS, MSMQ, etc
32. Reliable Transport Alternatives SOAP messages are transport agnostic
Change the transport, change the binding
Route messages over a reliable channel
E.g. MQ, MSMQ, JMS etc
33. Coordinating Services Processes need end-to-end guarantees
Manual coordination necessary today
Generic coordination soon!
34. “WS-Fabric” HP/Arjuna realisation that WS obviated need for proprietary middleware
HP/Arjuna realisation that WS obviated need for proprietary middleware
35. Same Old Architects Business people and application architects design business-centric workflows which consume services
Re-using the functionality already deployed into the service ecosystem
Service architects and developers build services
Using WS toolkits like WCF and Axis
Enterprise architects influence QoS at the SOAP level...
Using the WS-* specs
...and at the transport level
Existing investments can form the underlay for SOA
And undertake necessary governance roles NAB/Commbank have lots of investment in all kinds of plumbing – can re-use this to support SOA (and incrementally replace if necessary)NAB/Commbank have lots of investment in all kinds of plumbing – can re-use this to support SOA (and incrementally replace if necessary)
36. ESB or SOA? 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
37. Conclusions SOA is the right integration architecture going forward
SOA can be implemented incrementally
Drive SOA from a business perspective
Most valuable processes/applications/services first
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
Metadata, metadata, metadata!
38. Questions? http://jim.webber.name
39. Reminders Fill in your evaluation forms
With heaps of praise!
Tech Ed Party this evening @ Home Nightclub