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: Paul Fremantle on Using REST for WS-*

Stefan Tilkov,

These are my unedited notes from Paul Fremantle's talk at QCon London 2008.

  • WSO2 has historically been associated with WS-* only
  • Experts and standards authors, specifically Paul and Sanjiva, working for WSO2
  • Talk is about applying REST to a real application problem - managing web services metadata
  • Paul is co-founder and CTO of WSO2, chair Apache Synapse, co-chair WS-TX
  • Background on classic SOA triangle, UDDI
  • In reality: Not just SOAP, but others as well (SOAP, JMS, REST, XML/HTTP)
  • Explicit distinction between REST and XML/HTTP
  • Failure: No decent registry/repository
  • Also a failure of UDDI
  • Two incumbent parties:
  • Infravio, bought by WebMethods, bought by Software AG
  • Systinet, bought by Mercury, bought by HP
  • Those two are the Rolls Royces of the space
  • Open source ebXML, UDDI projects, no wider share
  • A long time ago, couldn't find a way to map a simple model for configuration data to UDDI
  • Synapse supports pulling configuration via HTTP (from Web server, Subversion, whatever)
  • UDDI history/assumption: homogenous thinking, everyone implements the same interface, fundamentally based on the same model as Windows Registry (long UUIDs - tModels, lots of interlinking)
  • Registry characteristics, requirements - different needs for business users, SOA developers, programmers
  • Re-iteration of REST principles
  • Hasn't seen Web UIs that are also APIs - e.g. people can't set Accept headers for debugging purposes in their browsers
  • Sessions are a problem - session-based sites are not good candidates
  • Hard to capture links/conform to HATEOAS
  • How to apply this to SOA metadata?
  • AtomPub/Atom as the basis for the registry, optional Java client library
  • Example of Atom feed
  • Registry is one Atom Workspace w/ many collections
  • Benefits of AtomPub: clear behavior of POST, GET, PUT, DELET
  • Example: POST including Slug, 201 response + URI
  • Well-defined protocol, interop, does almost what they needed
  • Issues: no nesting of collections, ambiguity about creating new collections, no definitions of queries
  • AtomPub isn't just for Atom - how to POST "other stuff" (create media resources)
  • AtomPub covers the most obvious metadata
  • Well-defined link model
  • URI design: different paths for web UI, Atom, resource itself - no Accept headers
  • specific URL schemes for different kinds of access (e.g. all tags)
  • update means new version
  • keep track of depencies, e.g. between WSDL and Schema
  • Version accesible via a URI as well
  • Similarity to decisions made by Google for GData
  • POSTing a collection to a collection (as a media entry) creates a "nested" collection (not an AtomPub concept, but common sense
  • Queries still work in progress: no own query language yet
  • current solution: query stored as a resource in the registry, parameters passed via GET
  • Maybe there could be a generalized REST or Atom query language
  • Java API: registry proxy, Resource concept, get and put methods
  • Quick registry live demo
  • Support for ratings (typical 5 star thing), arbitrary properties
  • Main problem in SOAs: trust as a root cause
  • Solution: comments - work much better than complicated approaches
  • "Social Governance"
  • What about WS-*? What does the registry offer?
  • storing, searching, managing schemas, WSDLs, policies
  • dependency links
  • validity
  • conformance to guidelines
  • lifecycle
  • WS-* metadata isn't enough for the real world - some real life annotations are needed
  • handlers whenever a POST or GET are issued
  • WSDL/Schema dependencies are tracked, internal dependency mapping
  • WS-I check will be implemented (but isn't yet)
  • Support for URL handlers (invoked for anything POSTed to particular URLs)
  • Lifecycle handling - still basic, more coming in version 1.1
  • What does Paul think about REST?
  • One should be skeptical about REST
    • Even in this most obvious scenario, too many design choices are to be made
    • Even if subset to Atom/AtomPub, still a lot of design choices to be made
    • Still needed very smart people
  • But: this has worked out very well
    • Building the human interaction and social aspects
    • Unification of the human interface with the machine interface
    • Atom feeds
  • Human design
  • Designed to work on any scale (local, departmental or shared, enterprise-wide or Internet scale)
  • Running middleware systems directly from this metadata can offer the same scaling
  • Mashup itself server uses registry
  • http://mooshup.com example
  • Input is welcome: http://wso2,org/projects/registry/
  • Audience question: what's the relationship between Subversion (or similar) and the registry, i.e. if you currently manage your stuff in Subversion, what are you supposed to do?
  • Answer: First, Subversion could be a backend
  • But: how do you cluster it?
  • Goal: Being able to rely on the registry instead of the configuration management system
  • Follow up question: do you want to compete with Subversion?
  • Answer: no, just for contracts and policies; for this usage, better than SVN
  • Question: would you recommend migrating stuff from SVN to the registry?
  • Answer: Yes.
  • Question: What about Java Content Repository (JCR)?
  • Answer: Mule did something very similar; its registry, Galaxy, it uses JCR as the backend. WSO2 didn't because when he looked at it, Apache's JCR implementation was too fat
  • Maybe AtomPub is JCR for the Web?
  • In hindsight, Dan Diephouse blogged about having problems
  • Question/comment: JCR has a versioning model, resource typing, ...
  • Answer: Paul believes in wire standards, not APIs
  • Question (myself): Can Galaxy and WSO2's registries be merged?
  • Answer: possibly, at least some synching would make sense
  • But maybe having two companies not doing UDDI suddenly makes a movement
  • Another difference: WSO2 did it openly, MuleSource did it in stealth mode
On March 13, 2008 4:06 PM, Erik Johnson said:

On “Be skeptical of REST”, I thought Mark really meant to “be aware” — the simplicity is deceiving. He was listing examples of issues his team resolved, but people new to REST might not have come across before. IMHO.

On March 13, 2008 5:07 PM, Erik Johnson said:

Oops. I meant Paul, not Mark.

On March 13, 2008 5:25 PM, Stefan Tilkov Author Profile Page said:

I agree, that’s how I understood it as well.

On March 14, 2008 8:56 AM, Paul Fremantle said:

Stefan

Thanks for taking such thorough notes.

The only correction I have is about the fatness of JackRabbit. Its actually very thin. But when I first looked at it, it was fat, but since then they have modularized and slimmed down. The main reason for not using JackRabbit, JCR or even SVN was the complexity factor - having more moving parts to manage and cluster and deploy in production.

Paul