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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The audit problem
  • Files – each party manages their own world, but changes break downstream clientsDatabases – both parties now have to agree on schema changes. What about data validation (business logic) across systems?MOM – How do you determine rate of processing? Front-office may want real-time; back-office often are okay with high latency.SOA – Some standards, but not all vendors use the same standards; publisher determines format and may take your needs into consideration. So you have “kind of” communication.
  • Planning systems upgradesDifferent platforms and dev toolsMost people just want their ExcelDifferent architectures, expectations, security, etc.Because you are forced to talk to different platforms, you wind up with spaghetti.
  • Originall, ESB was seen as the hero. Look at that beautifully clean network diagram!
  • But the ESB just hides the spaghetti.Auditing BizTalk was never easy because you still have to understand which systems talk to which, how they do so, etc.
  • What exactly is XHTML (or HTML)?Currently, it’s the new spaghetti code.Cool new features coming in HTML5, but most of that is making this worse.It’s a document serialization format.
  • 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 />