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