HTTP: the other ESB

Ryan RileyCatapult Systems, Inc.Houston TechFest 2009

Agenda

• Setting the Stage• Alternatives• HTTP: the application protocol• Common Concerns• Questions• Resources

Setting the Stage

First things first

• Demand – Specialized Tools– Different tools needed among front and back

office, as well as field workers– Once people get used to a tool, they don’t

want to change … except to get the features they want

• Supply – One-size-fits-all– Create reusable frameworks or components

and force them to fit the need– Save time and money (80/20 rule)

The result?

Old Computer Equipment 1 from Dolor Ipsum Some rights reserved

The Integration Problem

• Start with Application Silos• Then need to Share and Aggregate

Data• Note:– Different systems with different needs– Different interpretations of data semantics–MUST communicate– Systems rarely die, but we keep adding

more

The Contenders

• File sharing• Databases

– Direct sharing or ETL / Data Stores– How do you negotiate schema changes?

• Message-Oriented Middleware (MOM)– Fire and forget– Vendors rule the world: Message Broker, ESB, etc.

• Service-Oriented Architecture (SOA)– Back to silos– Which platform: Java, .NET, ESB framework, etc.

Complexity becomes us

• Starts simple• Ends …

Spaghetti? Yum! from Dano Some rights reserved

ESB to the rescue!

… or perhaps not

“Enterprise Spaghetti Bus” – Jim Webber

Meanwhile …

• New patterns and practices– Agile and Lean– TDD, BDD, DDD, CI, CQS/DDDD, etc.– Frameworks and tools to the rescue!

• The web as an application platform–WS-* emerges as an SOA solution– Rails & co make web programming

easier

Alternatives

WS-*

• Messaging: SOAP• Discoverability: WSDL• Security: WS-Security• Reliability: WS-MessageReliability• And a host of others:– WS-BusinessActivity– BPEL– Etc.

WS-* (cont.)

• Scalability– Reliance on HTTP POST– Complex to achieve

• Transactions– Complicated protocols– Based on classic RPC paradigms

• Brought to you by HTTP POST

Other alternatives

• ESB frameworks: NServiceBus, MassTransit, Rhino.ServiceBus, etc.

• Back to file/database sharing?

• Most of these are fire and forget models.

HTTP: the application protocol

(and you thought the second T was for transport?)

HTTP is comprehensive

• HTTP verbs– GET– PUT– POST– DELETE– HEAD– OPTIONS– And more through extensibility!

Messaging

• Request

• Response

• It’s about communication!

GET /index.html HTTP/1.1

Accept: application/xhtml+xmlAccept-Language: en

HTTP/1.1 200 OK

Content-type: application/xhtml+xmlContent-length: 16

Hello TechFest!

Status Codes

• 100 – 101 Informational• 200 – 206 Success• 300 – 307 Redirection• 400 – 417 Client Error• 500 – 505 Server Error

GET

• Idempotent = massively scalable via caching

• Control caching through HTTP headers:– Client => Last-Modified + If-Modified-

Sinceor If-None-Match + ETag

– Server => Cache-Control and Expires

PUT

• Useful for updating and creating• Idempotent = safe to repeat

POST

• Create a new resource• Not necessarily safe

DELETE

• Disable a resource (though not necessarily destroy)

• Safe to repeat, but the response is generally different when the resource doesn’t exist.

HEAD

• Retrieves only the headers• Conditional GET

OPTIONS

• Retrieves the HTTP verbs a resource URI will accept.

• The protocol tells the client how it may proceed.

Hypermedia Types

• XHTML (application/xhtml+xml)• RSS (application/rss-2.0)• Atom/AtomPub

(application/atom+xml)• Custom (application/vnd.my-format)

XHTML?

XHTML for Messaging

Why not XLink?

• Open XML link extension• Not well understood nor clearly

defined• In the end, you would still need

custom processing, so use application/vnd.custom+xml instead of application/xml

Atom / AtomPub

• Well-understood hypermedia format– Collection <atom:feed> and single <atom:entry>

formats– Can use <atom:link> within custom media types

for well understood link semantics

• Works well as a queue (if you must)• Simple and extensible• Debate over message formats in

REST

Add Semantics

• Microformats• RDF / RDFa

(FOAF)• Prefer

microformats(rel tag)

The Role of Hypermedia

• REpresentational State Transfer (REST)• Accept header

(contentnegotiation)

• State transitions / Workflows (HATEOAS)– Single entry point– Next steps provided through links– Can swap out providers (links)

GET /index.html HTTP/1.1

Accept: application/xhtml+xml, application/jsonAccept-Language: en

HATEOAS

http://www.infoq.com/articles/subbu-allamaraju-rest

HATEOAS, cont.

With HATEOAS

No HATEOAS

http://www.infoq.com/articles/subbu-allamaraju-rest

Reliability

• Idempotency• Response Error Codes• HTTP is synchronous by nature• Other ESB platforms are generally

asynchronous– Fire and forget– Need additional fault tolerance

mechanisms

Security

• HTTP Basic and Digest authentication• HTTPs, the tried and true (but not

cahceable)• OpenID, OpenAuth, SAML

Scalability

• Stateless, so massively scalable• Client and Proxy caches

Transactions

• Hypermedia (HATEOAS)• Different paradigm with richer

semantics• Workflows and state transitions

How to GET a Cup of Coffee

• http://www.infoq.com/articles/webber-rest-workflow

Common Concerns

Security Concerns

• Isn’t the web inherently insecure?• HTTPs is used everyday to transact

millions• Other protocols emerging– OpenId + OpenAuth– SAML

Complexity

• Few frameworks exist for pure HTTP use– RESTClient and Sinatra (Ruby)– Limonade (PHP)– OpenRasta (.NET)

• Fairly simple to create from scratch• Mash-ups (just see how easy this is)– On the web– Call services from within Excel

OpenRasta (C#)

Limonade (PHP)

Sinatra (Ruby)

Tight-coupling

• This is a fear from having used WSDL• HATEOAS reduces coupling even more!– Don’t use URI templates (except internally)– URIs can be swapped at any time– Requires a layer in between your domain

and the external API– Upgrade client and server independently

(Accepts header)

Summary

There is no spoon (or bus)

• Paradigm shift• Dumb network vs. Smart network• Meaningful semantics over classic,

distributed spaghetti architecture• Take advantage of the

existing, richinfrastructure

• 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't solve world hunger, it will certainly give us a new perspective to practice software engineering.~ Bill Burke, JBoss

Questions?

References

• Dr. Roy Fielding’s Dissertation• HTTP/1.1 (rfc2616)• The Atom Syndication Format• The Atom Publishing Protocol

Books

• Get /Connected (coming 2009/2010)(Parastatidas, Robinson, Webber)

• RESTful Web Services (Richardson & Ruby)

• RESTful Web Services Cookbook(Allamaraju & Amundsen)

Presentations

• Get /Connected• Guerilla SOA• A Couple of Ways to Skin an Internet

Scale Cat• Does My Bus Look Big in This?• RESTful

Approaches to Financial Systems Integration