gettin all zoidal on ya
My favorite comic strip celebrates its 6th birthday today. If you haven’t read it before, pick a story arc to read - often you need to get to know the characters and the story for an individual strip to be meaningful. The investment is well worth it though…
Sergey has some rather interesting thoughts on integrating WS-Policy with AtomPub:
“…it seems obvious to me that the goal which APP Feature Discover Draft is trying to achieve is the one WS-Policy is trying to achieve too except that WS-Policy is not trying to tackle the discovery problem in its current version.
It seems to me that WS-Policy might play the role of a bridge between the two worlds. APP is obviously a solid RESTful protocol. However it may be unrealistic to expect that everyone will use only APP in the future. There’re other RESTful protocols around, such as the one dealing with Web3S documents, and there’ll be a number of others too. What will unite all of these RESTful protocols is that the majority of them will support XML.”
These are good points. I, as I think Sergey as well, would like to see only minimal profilieration of Atom specific specifications. If there is an opportunity for something to be used in the wider category of RESTful services, I think we should embrace it.
Sergey goes ahead and makes two proposals about how WS-Policy could be used in replacement of Atom Features. The first idea is to simply use a policyreference element to state that a feature must be supported:
<wsp:policyreference uri='http://purl.org/atompub/features/1.0/supportsDraft'/>
I think Sergey is thinking here that the URI may not necesarily resolve and it would just be globally understood. Seems a bit hackish to me as the idea behind policy attachments is that they’re resolved. This is why I think his second idea of just creating new policy elements is cleaner:
<wsp:Policy>
<feature:supportsdraft feature='http://purl.org/atompub/features'/>
</wsp:Policy>
This could be inlined inside a APP service/workspace quite easily. Or it could be referenced inside a service/workspace from a policy attachment.
Why WS-Policy though? As Sergey mentions, WS-Policy is not tied to SOAP or message oriented services even. It works well with RESTful services. I think if we could avoid a new specification which duplicates WS-Policy, it’d be better for everyone (however I’m no expert in these areas, so take what I say here with a grain of salt).
We could potentially develop a rich set of policy expressions for HTTP which work with all types of RESTful services. Some hypothetical policy expressions:
This last case is a rather interesting/important one. This could work in either features or policy, but I think it is one of the missing pieces in APP. How do I figure out how to interact with an APP service if it is expecting a special type of xml document in the content? You need to specify that a service consumer needs to understands a particular mimeType with the specified description to interact with it. i.e. each entry represents a customer and it has a business specific <customer> xml element in it which must be understood.
In features I suppose it might look like this:
<f:feature ref'http://purl.org/description'>
<UnderstandsDescription mimeType="application/vnd.acme.customer+xml" type="http://.../xmlSchema" href="http://foo/customer.xsd"/>
</f:feature/>
Or in WS-Policy
<wsp:Policy>
<UnderstandsDescription mimeType="application/vnd.acme.customer+xml" type="http://.../xmlSchema" href="http://foo/customer.xsd"/>
</wsp:Policy>
You could even express that the consumer must understand at least ONE of the specified content types to be able to interact with the service.
Interesting posssibilities, and it would be great to hear from the APP/Feature spec folks what they think on the issue.
Hit “~” in beta.bloglines.com. Interesting.
Atom (or Atom/RSS) Specific Standards
Non Atom Specific Standards:
I know there are a few more being developed as well. Let me know what I missed and I’ll update the page. By the way, I do mean this in jest - for the moment :-). We’ll see how many more specs we can add to the list.
I’m in Oslo this week for Javazone 2007. And while I missed the 8 AM heavy metal band suspending themselves unfortunately, it still has managed to be quite a good conference. Partly because I get to see lots of my European friends whom I may not see that often.
Oslo is a beautiful city. (With a disproportionate amount of beautiful women too!) Its very clean and friendly. Really the only bad thing I have to say about Oslo is that it is insanely expensive. Our cab ride last night which took us a .5 mile cost about $100 ($20 basically from the moment we stepped in the door)!!! And beers are about $10! Its nuts.
I gave an updated version of my Building Scalable, Reliable, and Secure RESTful services talk yesterday. I think it went pretty well - I got a fair amount of good feedback at least. It was the first time I thought I might have actually explained REST coherently to people. (Have you ever tried explaining REST to someone who knows nothing about it?
I attended Ryan Heaton’s presentation on Enunciate today. He’s written some really cool stuff to package up and maintain web services. In particular I love the ability to document your services really easily and have it presented via a pretty UI to the user. You should check it out if you haven’t already.
For now, I’m headed off to the Spring/OSGi presentation shortly so I can pretend I understand OSGi when I talk to people. 
A few weeks ago I put together some support for Abdera users who are using Spring. This allows you to build AtomPub services pretty easily using Spring. Here’s a quick example of what a typical Spring config will look like:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:a="http://abdera.apache.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://abdera.apache.org http://abdera.apache.org/schemas/abdera-spring.xsd">
<bean id="provider" class="org.example.MyProvider"/>
<a:serviceContext>
<a:provider>
<ref bean="provider"/>
</a:provider>
<a:targetResolver>
<a:regexTargetResolver>
<a:collection>/atom/feed(\?[^#]*)?</a:collection>
<a:entry>/atom/feed/([^/#?]+)(\?[^#]*)?</a:entry>
<a:service>/atom(\?[^#]*)?</a:service>
</a:regexTargetResolver>
</a:targetResolver>
</a:serviceContext>
</beans>
In Abdera, services are backed by a Provider. This is the place where your application specific logic goes for creating, editing or deleting resources. In the above example we’ve declared our MyProvider class as a bean.
This bean then gets wired into the Abdera ServiceContext. The ServiceContext is kind of the central hub on the server side which controls how HTTP requests get mapped to provider. Of primary importance in this mapping is Target Resolver. It helps determine whether a request gets mapped to an Atom collection, entry or service. The above example uses a RegexTargetResolver to do this. “/atom” urls get mapped as a service, “/atom/feed” urls get mapped to a collection, and “/atom/feed/foo” urls get mapped to a specific Atom entry.
This should be included in the upcoming 0.3.0 release which is being voted on. For more info, I’ve been writing some documentation here. Enjoy, and let me know if you’ve found it useful!
From TSS:
[Editor's note: is anyone using SCA in anger - meaning, with actual intent and purpose? It's one of those things that shows up in news items from time to time, and it's easy enough to see where it might be useful, but Your Humble Editor knows of only one company actually applying it, and a few vendors. Maybe it's me, but I just don't ... quite... get it. Anyone willing to step up and help?]
There seems to be a noticable lack of comments right now.