HTTP: the Other ESB

HTTP: the other ESB
Ryan Riley
Catapult 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 IpsumSome 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 DanoSome 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+xml
Accept-Language: en
HTTP/1.1 200 OK
Content-type: application/xhtml+xml
Content-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-Since or 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)
Prefermicroformats(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/json
Accept-Language: en

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

HATEOAS, cont.
No HATEOAS
With 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 theexisting, 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

http://www.scoop.it	373
http://wizardsofsmart.net	40
http://www.slideshare.net	22
http://localhost	1

HTTP: the Other ESB

by Ryan Riley

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 436

Statistics

HTTP: the Other ESB Presentation Transcript