This is a huge endorsement for AtomPub – I’ll bet Bill is delighted (hey, I can even tell him in person at his IWTC talk in an hours time…)

Mike Culver gave an interesting briefing and demo of some AWS technologies yesterday in the Digital Exchange in Dublin. Quick summary from my notes:

General

• No European data centers at the moment (see Justin’s comment)

EC2

• Now have several flavours – Small (10c/hr=$70/month), Medium (40c/hr=$280/month), Large (80c/hr=$560/month) if left running for the whole month.
• All the official Amazon Machine Images (ec2-public-images*) are still Fedora 4 based. This is a relatively old linux distro but is rock solid. Lots of unofficial images though I suspect building your own from a stock distro is probably the way to go
• There is market for ‘Paid AMIs’ where 3rd parties sell images and earn a commission based on total instance uptime from Amazon. Interesting market!
• Mentioned Elastic Live and RightScale as providers who offer a degree of support for managing EC2 instances (Amazon don’t offer much by way of support for EC2)
• He ran through creating a AWS image and starting it up using some Java based command line tools (wrapper for their HTTP APIs), nothing earth shattering here.

SQS

• Only a very high level overview, the only technical note of interest is that SQS cannot be treated as a FIFO queue – messages not deleted will re-appear.

FPS

• US only, no indication that would change
• Interesting rules scripts support for controlling payments
• Option to charge fees to either end of the transaction (as opposed to credit card companies who always charge merchant)
• Micropayment (to as little as 1c) support via commission % fee model.

S3

• From 800 million objects in Aug ‘06 to 10 billion objects in Aug ‘07, no details on average object size.
• Does not automatically set HTTP cache control headers (Last-Modified, Etag etc) on objects when serving them over HTTP so that they won’t be cached by internet caches (or browsers) – bit naff! Suggested this might be achievable via object metadata though I havn’t checked this yet.
• No support for rename or symlink type operations. They mentioned that JungleDisk acheive this by using EC2 instances to do the rename via copy/delete – traffic between EC2 and S3 is free.
• No indication of support for OAuth to support delegated authority. Shame.

Well worth a read if you’re looking for some food for thought and can spare 10 minutes….

• How should RESTful clients bootstrap into a RESTful system, or rather, how does the client determine the correct payload to send to the first RESTful resource it interacts with?  Currently it appears that there must be some out-of-band definition of the first RESTful resource request that the client has ‘baked-in’ in order to initiate a conversation with a set of RESTful resources.  HTTP Web browsers solve this problem through (bookmarked) URLs.  Should all RESTful resource clients do the same?
• How should RESTful clients interpret arbritrary XML response payload?  The response XML is presumably defined by a schema (somewhere) but I’m wondering how is a RESTful client expected to interpret the semantics of the XML unless it has prior knowledge of the schema.  Is this prior knowledge just assumed? Again, HTML browsers succeed in this regard because they are build on the semantics of the HTML language schema.

I’d be very interested if anyone has insights into the above two questions.  If knowledge of the schema(s) is assumed (Aristotle’s post implies this) then perhaps all folks are looking for is guidance on how to determine which XML element definitions are expected/returned by RESTful resource request/reponses. 

Perhaps that’s where the value in WADL lies.  Unfortunately WADL seems to promote static resource set definitions, as WSDL does for WS-* service endpoints.  Perhaps if the WADL resource set definitions could also reference other WADL resource set definitions then we might have something a bit more dynamic?

This pain is experienced most sharply at the moment in the SOAP world, because the big commercial players have made a serious investment in trying to produce tools that work for the average developer. But I believe the REST world has basically the same problem: it’s not really feeling the pain at the moment because REST solutions are mostly created by relatively elite developers who are comfortable dealing with XML directly.

It is an interesting observation, and it highlights yet again that the lack of appropriate tooling is a major barrier to development of large-scale REST solutions. I am undecided still about what effective tooling would look like (over a year after I asked where is it?) but I am sure it has to be no more complex to use than a browser. I’m not sure if a thick client IDE is even appropriate, given the nature of the solution being developed.

One thing that I think is obvious now is that the difference between true RESTful solutions and XML/HTTP-binding based web service solutions has become somewhat blurred. Perhaps we have the prevalence of XML/HTTP WSDL bindings to thank for that. Also, the recent arrival of WADL, and its use by tooling with names like REST Describe may also be playing some part in the notion that one can capture the interface of true RESTful solution in static header files. But some tooling is better than none and I look forward to getting a better grip on this space.

I was curious about what has been going on in JSR-311 (RESTful Web Services) but this doesn’t bode well – I’ll reserve judgment until after I’ve read the draft. (Wouldn’t it be great if JSR working groups were more transparent?)

Update2: Vivek Pandey’s Blog post seems to confirm the above. I’m all for blogging to get the word out to the masses but the JCP Expert Group(s) should update their official JSR pages too. Regardless, the fact that JAX-WS 2.1 JAXB 2.1 was finalized on a Candidate Recommendation W3C specification reflects poorly on the quality of specification that the JCP is producing.

Does anyone know what happened to JAX-B 2.1? JAX-WS 2.1 (JSR-224) was released a few weeks ago, but the JCP have since pulled the specification, reference implementation and TCK. The reason given is that the W3C WSDL Binding specifiication, referenced by the JAX-WS 2.1 JAXB 2.1 specification announced back in December, did not make it past the Candidate Recommendation stage and apparently needs to be replaced with an alternative specification.

Does anyone have any pointers on why this happened (and what the old JAX-WS 2.1 candidate might be replaced by or when)?

Update 3: Looks like WS-Addressing WSDL Binding is being replaced by WS-Addressing Metadata.

Almost as an aside, I also noticed that WSDL 2.0 is now a Proposed Recommendation – is this just in time or just too late? New remote interface definition languages, by definition, face huge uphill battles gaining traction so WSDL 2.0 needs to earn some serious credibility and quickly. Developers need WSDL 2.0 based tools and stacks to allow them to evaluate the new specification in proposed real world scenarios. (WADL looks nice and is winning kudos these days but I doubt it will ever depose either the old or new W3C-endorsed specifications.)

Two excellent pieces serve to proffer incredible insight into the experiences of those who have hyper-succeeded in the past:

• Inside MySpace.com, by Baseline Magazine is a great read about how MySpace scaled their architecture from zero to over 26 million user accounts, serving over 40 billion pages a month (isn’t that figure just incredible!).
• Database War Stories is a series of posts by Tim O’Reilly, interviewing folks from Second Life, Memeorandum, Craigslist and more. (The rest of the posts are linked to at the bottom of the first post.)

One common theme in many of these stories: periodically these guys are faced with the stark reality that incremental improvements to existing infrastructure will not sustain the current business model. It is testimony to the folks in charge that they trust their geeks enough to bet the company repeatedly on new architectures.

It is a high-risk world and there are many that fall by the wayside but the rewards for the brave are there for all to see.