QCon London 2008: Jim Webber

These are my unedited notes from Jim Webber's talk at QCon London 2008. I might have to stop early as I have only some battery left ... we'll see.

Invented "Enterprise Manboobs" yesterday (defined as the big bloated ESB middleware -- it's so fat it has manboobs)
Schizophrenic on whether or not to prefer messaging or Web
MESTian with sympathies for RESTafarians
Web services, happily abusing HTTP
Business processes, hosted within services, communicating via messages
The XML fairy sprinkles pixy dust (which may in fact be crack cocaine) on your enterprise systems
In XML pixy dust land, messages are at the center
Except: Web services are evil -- because the messaging vision is as far out of reach
WSDL is the biggest pile of dog shit around
"WSDL is plainly shit. That's a technical term."
WS-HumanTask? WTF?
WSDL 2? Or WSDL too late?
WS-HumanTask? I value my humanity, I don't want to be wrapped in WSDL.
Not everything needs to be an OASIS standard. We know not to take a leak in public. (He said this )
WCF is the best of an extraordinary set of bad toolkits
Toolkits hide messages - WCF at least creates hope before forcing you back into the RPC mindset
Quick pitch for SSDL and Soya
Web Services could rock his world
WSDL has to die.
Sad that Sanjiva is not in the audience.
Things could be nice (SOAP processing model, message, loose coupling by default, composable model)
A lot of the WS-* stack can be ignored most of the time
"Tunneling is all a bunch of tree-hugging hippy crap"
URI tunneling and POX both treat HTTP as a transport
Some Web jihadists don't see this -- pointing explicitly at the Rails community (?)
Web Services tunnel SOAP over HTTP
Lots of Web people doing the same
Worse than SOAP
Example of methods with parameters exposed via URIs
very easy to understand, easy to code, pretty interoperable
BUT it's brittle RPC, tight coupling, no metadata
You can use GET and don't change any state
POX: uses XML in the HTTP request and response to move a call stack between client and server
Example: POSTing your credit card details into some porn site
Simplicity, interoperable, can use complex data structures
BUT: Tight coupling, no metadata support (unless you use a toolkit that supports WSDL w/ the HTTP binding)
RPC is commonplace today
To err is human, to really mess things up you need a computer
To really, really mess things up you need a distributed system
Bad Web services and Web integration have much in common
claimed end of rant (we'll see)
Web fundamentals
Bored lonely physicist Tim never intended the Web to be a middleware platform
Serendipity is great - don't let the RESTafarians tell you different
Roy must have thought: I can combine my love of porn surfing with my PhD
The Web exposes many of the characteristics we want - recoverable, loosely coupled, available, ...
Tenets for Web-based services (for the last time today)
Resource-based, Addressability, Statelessness, Representations, Links, Uniform Interface
Resource architecture - physical resources, logical resources, uniform interface, resource representation, consumer (web client)
Web URIs should be readable, not opaque
Use URI templates to make your resource structure easy to understand (S3 example)
Non-conformance and proud (google later)
Example: Good thing the Library of Congress didn't open up its contents with a link "print this" on every page
PUT is idempotent idempotent. That means you can do the same thing multiple times.
Points out all of the methods, status codes, headers
We have a comprehensive model for distributed computing ... but we still need a way of programming it
The Value of the Web is "linked-ness"
The same is true for the programmatic Web
Shows examples of links
The Web is just like Petri nets - links are state transitions
Microformats are an example of little "s" semantics
Innovation at the edges of the Web - not by some central design authority such as the W3C
Started by embedding machine-processable elements in Web pages -- e.g. calendar information, ...
With microformats, use the rel attribute to describe the semantics of the referred resource
"Subjunctive Programming"
With changing contracts as part of a resource, we can't be too imperative anymore
Doesn't have the cojones to call the Web declarative
Subjunctive preferred (what if I get a link to pay ...)
How to implement a typical enterprise workflow look if it's implemented in a Web-friendly way?
Starbuck's example -- it's a bit of a lie, as there is no happy path through Starbuck's
w/ Web services (MEST style), a conversation with a service via exchanging messages with it
The longest interaction you can have supported by WSDL is request/response
It's like a conversation with your demented granny who calls you "Billy"
Advertise it with SSDL or BPEL
What if this were modeled as resources?
Model workflow stages as resources, state transitions as hyperlinks/URI templates
First, do a POST to /order, Starbuck's returns 201 Created + a URI
In the returned representation, there's a link rel='pay'
If I make a mistake, I ask for my OPTIONS
If it says I'm allowed a PUT, I can update it (PUT)
Send an Expect: 100-continue (would it be OK?)
200 OK, yes you can
So do the PUT
If it fails, do it again (it's idempotent idempotent)
as the resource doesn't remember interactions, use If-Unmodified-Since and get back a 412 Precondition failed if something is wrong
If I do the PUT too late, I could get 409 Conflict
A new OPTIONS call says it's readonly now
Following the payment link: POST to the order payment resource
New payment created, its URI returns
How do I know to POST? Via OPTIONS
Now if I get the order again, no payment link any more
Starbucks can have some resources that are private, but can also access the same resources
There could be an Atom feed of orders
HTTP auth can be used to enforce only Starbuck's can access specific resources (401 unauthorized)
Lessons: HTTP has a header/status combination for everything
APIs are expressed in terms of links, and they're cool
AtomPub is a blueprint to develop similar protocols
(Although the Atom guys will tell you Atom is all you'll ever need)
APIs can also be constructed with URI templates and inference
XML is fine, but other options like APP, JSON or maybe XHTML as a middle ground
Summary: both the Web and Web services community suffer from piss-poor patterns and practices and awful tooling
Both platforms are about externalizing state machines when done well
WS-* is bloated, but most of it can and should be ignored
The Web is now starting to feel the love from middleware vendors - beware!
Sends shivers up his spine - not convinced it needs the Java API love, no equivalent to JAX-WS on the Web
MEST and REST are both sensible approaches
Question: In the Starbuck's example, how realistic is it because of the limits of most Web servers?
Answer: Maybe not today, but a year or so from now ...
Question: Link with the payment - would you define some kind of schema for that?
Answer: Should the IETF have the only set of definitions? No, he would like to be able to link to a description
Question: Degree of freedom may end up creating problems
Answer: Things can appear to close semantically, but different in their implementation -- it would be nice if these things were consistent, but if they're not, so what
Some of the people who advocate the Web claim the Web is simple -- they're stupid
It's not easier -- creating a good system requires thought
Question: Should the contract be defined formally?
Answer: WADL (doesn't like it, similar to WSDL), just accept there are links, or create something new (currently happening)
Question: Doesn't the client have to be too intelligent?
Answer: True, this is tricky because the client has to be prepared for many things. Having to be declarative, we know we have to be ready for everything. There's additional work ...
Udi: There's intelligence involved -- there are programmers building stuff
If it were this intelligent, it would be like SkyNet (probably some W3C working group somewhere)
Caching in the Web means caching cheaply and getting it right