SOA<br />from the Enterprise to the Cloud<br />February 2010<br />Version 1.0<br />
SOA – a personal journey that lasted 5 years<br />2<br />
Take a trip back to 2004<br /><ul><li>SOA wasn’t new, but the emergence of Web Services gave it new life
WS-* was still a smallish subset of ‘standards’
SOAP
WSDL
UDDI
Applications could now loosely couple across boundaries that had been hard to bridge before
Platform – Java or .Net
Language – managed code (more Java or .Net), unmanaged code (C++ etc.)
The web had already solved plumbing problems at internet scale and in the enterprise
This would piggyback on that success
Infrastructure would expose lots of management services
This would result in LOTS of endpoint to manage in a large enterprise</li></ul>3<br />
and this was what we ended up with…<br />4<br />Registry<br />Web<br />Services<br />Management<br />discover<br />registe...
But it all went horribly wrong<br />5<br />
and we ended up with standards about standards<br />6<br />
Too many things trying to make up for the inadequacies of HTTP<br />7<br />WS-Federation<br />WS-Addressing<br />WS-Securi...
Upcoming SlideShare
Loading in …5
×

SOA - from the Enterprise to the Cloud

733 views

Published on

Presentation to Oracle Higher Education SOA round table (Feb 2010)

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
733
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SOA - from the Enterprise to the Cloud

  1. 1. SOA<br />from the Enterprise to the Cloud<br />February 2010<br />Version 1.0<br />
  2. 2. SOA – a personal journey that lasted 5 years<br />2<br />
  3. 3. Take a trip back to 2004<br /><ul><li>SOA wasn’t new, but the emergence of Web Services gave it new life
  4. 4. WS-* was still a smallish subset of ‘standards’
  5. 5. SOAP
  6. 6. WSDL
  7. 7. UDDI
  8. 8. Applications could now loosely couple across boundaries that had been hard to bridge before
  9. 9. Platform – Java or .Net
  10. 10. Language – managed code (more Java or .Net), unmanaged code (C++ etc.)
  11. 11. The web had already solved plumbing problems at internet scale and in the enterprise
  12. 12. This would piggyback on that success
  13. 13. Infrastructure would expose lots of management services
  14. 14. This would result in LOTS of endpoint to manage in a large enterprise</li></ul>3<br />
  15. 15. and this was what we ended up with…<br />4<br />Registry<br />Web<br />Services<br />Management<br />discover<br />register<br />Secure<br />[ESF]<br />Fast<br />[XML Acceleration]<br />Client<br />Service<br />Reliable<br />[WS-RM]<br />invoke<br />
  16. 16. But it all went horribly wrong<br />5<br />
  17. 17. and we ended up with standards about standards<br />6<br />
  18. 18. Too many things trying to make up for the inadequacies of HTTP<br />7<br />WS-Federation<br />WS-Addressing<br />WS-Security<br />WS-RM<br />WS-Eventing<br />WS-Transfer<br />WS-MetadataExchange<br />WS-Policy<br />WS-Discovery<br />
  19. 19. When what was really needed was a better (or cheaper) MOM<br />8<br />This is the<br />‘magic quadrant’<br />of SOA<br />But until recently<br />only proprietary<br />implementations<br />
  20. 20. So the people who could live with HTTP retreated to simplicity<br />9<br />http://www.infoq.com/articles/rest-introduction<br />http://geekandpoke.typepad.com/geekandpoke/2009/11/service-calling-made-easy-part-1.html<br />
  21. 21. SOA doesn’t fail because of techie stuff<br />10<br />
  22. 22. SOA fails because of Conways Law<br />11<br />“...organizations which design systems<br /> ... are constrained to produce designs which are copies of the communication structures of these organizations”<br />Or… your org chart had better look like<br />your architecture, or you’re doomed.<br />
  23. 23. SOA succeeds when you have<br />12<br />Command<br />and<br />Control<br />
  24. 24. An then everything as a service came along<br />13<br />
  25. 25. The Cloudburger<br />14<br />Opex efficiency<br />Software as a service directly delivers business functionality.<br />Software as a Service (SaaS)<br />Platform as a service has less direct value, but may help organizations build functionality cheaper and faster.<br />Value<br />Platform as a Service (PaaS)<br />Infrastructure as a Service (IaaS)<br />Capex displacement<br />Most of the value of Infrastructure as a Service is tied into the capital assets. Though some comes from operating efficiencies<br />14<br />
  26. 26. Back to the future – TheEGA Technical Reference Model<br />15<br />Each physical layer provides Abstraction to the layer above<br />Each Virtualized layer provides a flexible mapping/management point<br />
  27. 27. Where did the complexity go?<br />You chose to live without it<br /><ul><li>Vanilla is good enough
  28. 28. SaaS – everybody gets the same
  29. 29. Incremental upgrades
  30. 30. ‘Labs’ style features for the brave</li></ul>or it gets squeezed out of one line of business (budget) and into another<br /><ul><li>IaaS – S, M, L, XL
  31. 31. Complexities get pushed over the wall to application support
  32. 32. Ops -> DevOps
  33. 33. How much of this can be absorbed into PaaS layer?</li></ul>16<br />
  34. 34. The difference between ‘hosting’ and ‘cloud’<br />It’s all about the API<br /><ul><li>But API is maybe the wrong term</li></ul>But it is all about the Interface<br /><ul><li>Invariably some kind of (HTTP) web service
  35. 35. Usually REST has won out over SOAP</li></ul>17<br />
  36. 36. 18<br />

×