This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

QCon London 2008: Jim Webber

Stefan Tilkov,

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