Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

HTTP: the Other ESB


Published on

Presented at Houston Tech Fest 2009.

Many developers use enterprise service bus (ESB) tools such as BizTalk or, for those looking at a lighter-weight approach, NServiceBus. What many fail to realize is that we have another option, one that has been tried and tested for many years and that we all use daily: HTTP. Find out how HTTP can deliver a much more maintainable, simpler solution to your ESB problems.

Published in: Technology
  • Be the first to comment

HTTP: the Other ESB

  1. 1. HTTP: the other ESB<br />Ryan Riley<br />Catapult Systems, Inc.<br />Houston TechFest 2009<br />
  2. 2. Agenda<br />Setting the Stage<br />Alternatives<br />HTTP: the application protocol<br />Common Concerns<br />Questions<br />Resources<br />
  3. 3. Setting the Stage<br />
  4. 4. First things first<br />Demand – Specialized Tools<br />Different tools needed among front and back office, as well as field workers<br />Once people get used to a tool, they don’t want to change … except to get the features they want<br />Supply – One-size-fits-all<br />Create reusable frameworks or components and force them to fit the need<br />Save time and money (80/20 rule)<br />
  5. 5. The result?<br />Old Computer Equipment 1 from Dolor IpsumSome rights reserved<br />
  6. 6. The Integration Problem<br />Start with Application Silos<br />Then need to Share and Aggregate Data<br />Note:<br />Different systems with different needs<br />Different interpretations of data semantics<br />MUST communicate<br />Systems rarely die, but we keep adding more<br />
  7. 7. The Contenders<br />File sharing<br />Databases<br />Direct sharing or ETL / Data Stores<br />How do you negotiate schema changes?<br />Message-Oriented Middleware (MOM)<br />Fire and forget<br />Vendors rule the world: Message Broker, ESB, etc.<br />Service-Oriented Architecture (SOA)<br />Back to silos<br />Which platform: Java, .NET, ESB framework, etc.<br />
  8. 8. Complexity becomes us<br />Starts simple<br />Ends …<br />Spaghetti? Yum! from DanoSome rights reserved<br />
  9. 9. ESB to the rescue!<br />
  10. 10. … or perhaps not<br />“Enterprise Spaghetti Bus” – Jim Webber<br />
  11. 11. Meanwhile …<br />New patterns and practices<br />Agile and Lean<br />TDD, BDD, DDD, CI, CQS/DDDD, etc.<br />Frameworks and tools to the rescue!<br />The web as an application platform<br />WS-* emerges as an SOA solution<br />Rails & co make web programming easier<br />
  12. 12. Alternatives<br />
  13. 13. WS-*<br />Messaging: SOAP<br />Discoverability: WSDL<br />Security: WS-Security<br />Reliability: WS-MessageReliability<br />And a host of others:<br />WS-BusinessActivity<br />BPEL<br />Etc.<br />
  14. 14. WS-* (cont.)<br />Scalability<br />Reliance on HTTP POST<br />Complex to achieve<br />Transactions<br />Complicated protocols<br />Based on classic RPC paradigms<br />Brought to you by HTTP POST<br />
  15. 15. Other alternatives<br />ESB frameworks: NServiceBus, MassTransit, Rhino.ServiceBus, etc.<br />Back to file/database sharing?<br />Most of these are fire and forget models.<br />
  16. 16. HTTP: the application protocol<br />(and you thought the second T was for transport?)<br />
  17. 17. HTTP is comprehensive<br />HTTP verbs<br />GET<br />PUT<br />POST<br />DELETE<br />HEAD<br />OPTIONS<br />And more through extensibility!<br />
  18. 18. Messaging<br />Request<br />Response<br />It’s about communication!<br />GET /index.html HTTP/1.1<br />Accept: application/xhtml+xml<br />Accept-Language: en<br />HTTP/1.1 200 OK<br />Content-type: application/xhtml+xml<br />Content-length: 16<br />Hello TechFest!<br />
  19. 19. Status Codes<br />100 – 101 Informational<br />200 – 206 Success<br />300 – 307 Redirection<br />400 – 417 Client Error<br />500 – 505 Server Error<br />
  20. 20. GET<br />Idempotent = massively scalable via caching<br />Control caching through HTTP headers:<br />Client =&gt; Last-Modified + If-Modified-Since or If-None-Match + ETag<br />Server =&gt; Cache-Control and Expires<br />
  21. 21. PUT<br />Useful for updating and creating<br />Idempotent = safe to repeat<br />
  22. 22. POST<br />Create a new resource<br />Not necessarily safe<br />
  23. 23. DELETE<br />Disable a resource (though not necessarily destroy)<br />Safe to repeat, but the response is generally different when the resource doesn’t exist.<br />
  24. 24. HEAD<br />Retrieves only the headers<br />Conditional GET<br />
  25. 25. OPTIONS<br />Retrieves the HTTP verbs a resource URI will accept.<br />The protocol tells the client how it may proceed.<br />
  26. 26. Hypermedia Types<br />XHTML (application/xhtml+xml)<br />RSS (application/rss-2.0)<br />Atom/AtomPub (application/atom+xml)<br />Custom (application/<br />
  27. 27. XHTML?<br />
  28. 28. XHTML for Messaging<br />
  29. 29. Why not XLink?<br />Open XML link extension<br />Not well understood nor clearly defined<br />In the end, you would still need custom processing, so use application/vnd.custom+xml instead of application/xml<br />
  30. 30. Atom / AtomPub<br />Well-understood hypermedia format<br />Collection &lt;atom:feed&gt; and single &lt;atom:entry&gt; formats<br />Can use &lt;atom:link&gt; within custom media types for well understood link semantics<br />Works well as a queue (if you must)<br />Simple and extensible<br />Debate over message formats in REST<br />
  31. 31. Add Semantics<br />Microformats<br />RDF / RDFa(FOAF)<br />Prefermicroformats(rel tag)<br />
  32. 32. The Role of Hypermedia<br />REpresentational State Transfer (REST)<br />Accept header(contentnegotiation)<br />State transitions / Workflows (HATEOAS)<br />Single entry point<br />Next steps provided through links<br />Can swap out providers (links)<br />GET /index.html HTTP/1.1<br />Accept: application/xhtml+xml, application/json<br />Accept-Language: en<br />
  33. 33. HATEOAS<br /><br />
  34. 34. HATEOAS, cont.<br />No HATEOAS<br />With HATEOAS<br /><br />
  35. 35. Reliability<br />Idempotency<br />Response Error Codes<br />HTTP is synchronous by nature<br />Other ESB platforms are generally asynchronous<br />Fire and forget<br />Need additional fault tolerance mechanisms<br />
  36. 36. Security<br />HTTP Basic and Digest authentication<br />HTTPs, the tried and true (but not cahceable)<br />OpenID, OpenAuth, SAML<br />
  37. 37. Scalability<br />Stateless, so massively scalable<br />Client and Proxy caches<br />
  38. 38. Transactions<br />Hypermedia (HATEOAS)<br />Different paradigm with richer semantics<br />Workflows and state transitions<br />
  39. 39. How to GET a Cup of Coffee<br /><br />
  40. 40. Common Concerns<br />
  41. 41. Security Concerns<br />Isn’t the web inherently insecure?<br />HTTPs is used everyday to transact millions<br />Other protocols emerging<br />OpenId + OpenAuth<br />SAML<br />
  42. 42. Complexity<br />Few frameworks exist for pure HTTP use<br />RESTClient and Sinatra (Ruby)<br />Limonade (PHP)<br />OpenRasta (.NET)<br />Fairly simple to create from scratch<br />Mash-ups (just see how easy this is)<br />On the web<br />Call services from within Excel<br />
  43. 43. OpenRasta (C#)<br />
  44. 44. Limonade (PHP)<br />
  45. 45. Sinatra (Ruby)<br />
  46. 46. Tight-coupling<br />This is a fear from having used WSDL<br />HATEOAS reduces coupling even more!<br />Don’t use URI templates (except internally)<br />URIs can be swapped at any time<br />Requires a layer in between your domain and the external API<br />Upgrade client and server independently (Accepts header)<br />
  47. 47. Summary<br />
  48. 48. There is no spoon (or bus)<br />Paradigm shift<br />Dumb network vs. Smart network<br />Meaningful semantics over classic, distributed spaghetti architecture<br />Take advantage of theexisting, richinfrastructure<br />
  49. 49. Distributed computing for years now has seemed like an endless repackaging of the same old ideas, patterns, and technology. Through REST, I finally feel like distributing computing is evolving and moving forward again. While REST won&apos;t solve world hunger, it will certainly give us a new perspective to practice software engineering.~ Bill Burke, JBoss<br />
  50. 50. Questions?<br />
  51. 51. References<br />Dr. Roy Fielding’s Dissertation<br />HTTP/1.1 (rfc2616)<br />The Atom Syndication Format<br />The Atom Publishing Protocol<br />
  52. 52. Books<br />Get /Connected (coming 2009/2010)(Parastatidas, Robinson, Webber)<br />RESTful Web Services(Richardson & Ruby)<br />RESTful Web Services Cookbook(Allamaraju & Amundsen)<br />
  53. 53. Presentations<br />Get /Connected<br />Guerilla SOA<br />A Couple of Ways to Skin an Internet Scale Cat<br />Does My Bus Look Big in This?<br />RESTful Approaches to Financial Systems Integration<br />