Aehso’s Output

ROA is a subset of SOA - but is WOA a superset of ROA?

I previously criticized a post by Dion Hinchliffe’s on WOA/Client but to be fair to Dion I have to compliment him on his latest post about the SOA world beginning to consider the Web-Oriented Architecture(WOA) in earnest.

Dion has continued to do some very deep thinking and about *OAs and this post reflects this effort - it should be immensely useful for anyone looking at how to evolve existing SOA systems over to a resource oriented architecture. I’m well past the ROA vs SOA debate (a ROA is a subset of SOA) but one lingering concern that I have about this and other discussions is this distinction between ROAs & WOAs.

I’m not quite sure that I can see a clear distinction between the two and I think having two TLAs for what may be the same underlying architecture type may be hindering understanding. Almost every core feature of WOA systems is derived from the underlying RESTful constraints. I’d imagine that if we could do away with one of these TLAs then the underlying concepts, and the differences from big-SOA, will become more accessible to all. (Note: I accept that there are non-RESTful anomalies out there mixed onto the www substrate but these edges always seem to fall by the wayside as the www has evolved.)

When I get chance I’ll try write up something more detailed on this but in the meantime if you have some clear examples of use cases where a WOA is a distinct superset of ROA then I’m sure they’d help my thinking.

Tags: roa, soa, woa

A little REST in business applications.

The simplicity of this is striking. Here’s a great example of how a business application like an online spreadsheet can become oh-so-more-useful when it can integrate external data in interesting ways via RESTful APIs.

ESBs and REST.

Wonderful post (and followup) by Steve Vinoski, spawning lots of other discussions.  I should be surprised by some of the comments but… I’m not - I suspect agendas, pride and reputations may be at play.  Imho, and I stress humble opinion, his views are completely valid. Can enterprise architects disregard the architecture, constraints and protocols that helped the Web scale and adapt to be the global platform it is today?  If they want to build something that will adapt and scale then I also think the answer has to be No.

Platforms like ESBs were built to solve the problem of interconnecting and integrating enterprise systems. The disconnect between how an ESB-based or RESTful solution approach the same problem can mostly be explained by the fact that they both evolved from very different starting points, and therefore have very different principals at their core. 

ESBs, having evolved from DCE-RPC, CORBA based RPC architectures, have always required static definition of non-uniform remote interfaces.  The modern WS-Deathstar-type ESBs are still based on this concept, with WSDL interface typically backed by statically compiled implementations (or if you are exotic XML based mediation languages).  The remote interface semantics can be augmented by a variety (cluster f&@k?) of ‘enterprisey’ features like transactions, routing and reliability defined by a collection of related specifications but it turns out that implementations based on some of those specifications do not interoperate or scale.  This is primarily a function of questionable specification development processes and over complexity.

In the end the non-uniform interfaces at the heart of these solutions tightly couple the clients and servers and this coupling is the underlying limiting factor on the adaptability and extensibility of these systems.  I still really struggle to find a successful real world internet-available IDL or WSDL based web service that has been used in a series of completely unexpected contexts (i.e. mashups) or that has evolved beyond more than one or two revisions without completely breaking backward compatibility for old clients.

In parallel the RESTful HTTP standard emerged and provided the platform for the Web that has scaled and adapted to truly global proportions.  This wasn’t an accident - the Web succeeded because of the RESTful principals upon it was built - stateless, client server, layered systems that support caching and of course the true use of Hypertext As The Engine Of Application State (thankfully now referable to as ‘the hypertext constraint‘).  To me HATEOAS is the most critical feature of RESTful solutions. It is the one feature that negates the need for non uniform interfaces and it is here where the two approaches diverge dramatically.  It also isn’t an easy concept to grasp for folks who are used to traditional RPC oriented systems. 

Regardless, the recent emergence of dynamic languages like Python and Ruby, and their respective web application frameworks, Django and Rails, is now making it economically efficient for anyone to produce RESTful web services that can scale and that are reusable.  Steve is just expressing his opinion that this approach works better.

Don’t get me wrong - the ESB approach has been proven to succeed and
scale but primarily in limited deployment environments and usually only when considerable resources are thrown at the solution.  To put it another way, the inherent limits in non-uniform interface based systems can be pushed through use of sophisticated tools and language bindings but this only be achievable when considerable resources are thrown at the solution.  I think this is what Steve is getting at - I don’t think Steve is saying ESBs are “bad”, just that they are not the best platform for building internet scale services/resources

(Hey, check it out, I didn’t mention SOA once!)

BTW, I’m reading The Future Of Ideas at the moment, hope to write more about that soon, but it does relate to the notion of control mentioned in Steve’s latest followup post.

RailsConf Europe Day 2

[Update: Some of the presentation files are now available on the RailsConf Europe website]
Slight delay on writing this one up as I was in transit on Thurs and at a wedding on Friday.  Anyway, this summary is going to be a lot shorter as I didn’t get as much out of Wednesday’s sessions.

Rails Hydra: Synthesizing an Application out of Multiple Rails Codebases (Craig R. McClanahan, Nick Sieger, Sun Microsystems)

Good talk on building services using several Rails applications, the Sun guys also got a chance to demo use of NetBeans 6 for Rails development (with some live demo debugging thrown in along with great audience participation!) Most of the demo centered around making it easier to develop DRY ActiveResource implementations. ActiveResource is almost definitely the right underpinnings for any RESTful service implementation but I think it still needs a bit more work around the edges.

Using a HAXOR Approach for Peace and Productivity (Tim Dysinger)

Good talk on how to manage interaction between designers and developers when developing Rails applications that use HTML, Ajax and XML Over REST. Quite high level (and if I’m honest, I was working away in the background so I couldn’t give it my full attention…)

Browser-based Testing of Massive Ajax-using Rails Applications with Selenium (Till Vollmer)
Good overview of using Selenium to test web applications from within the browser, covering use of Selenium IDE (browser based Javascript IDE), Selenium RC and the Selenium on Rails Plugin. Highlighted that Selenium struggles a bit with testing Ajax heavy web pages but it is possible with hand crafted scripts that use waitForVisible and/or waitForElementPresent events…

Functional JavaScript Development with Prototype (Ben Nolan)
Bit of an edge talk for the JavaScript fanatics but Ben presented well and it seemed well received by the audience…

Ruby on Rails leads you to the e-business (Quentin Tousart)
Mildly interesting talk on experiences gained in building two e-commerce websites using Rails.

Obscure Data Formats, Workflow, and Remote Synchronization (Chad Thatcher)
Another interesting case study on building a Rails front-end for a legacy data format (in this case the RISM format used by the British Library to catalog music manuscripts). Interesting use of composed_of in the Rails model objects to compensate for the fact that the underlying data was in hierarchical rather than relational form.

That’s about it, I met up with Sean Hanley from exoftware and David Rice . Mental note to self, get into RubyIreland…

RailsConf Europe Day 1

[Update: Some of the presentation files are now available on the RailsConf Europe website]
Some quick notes from some of the excellent conference sessions that I attended yesterday at RailsConf Europe.  I wasn’t here for the Tutorials on Monday though now I wish I had been - the quality of the presentations (at least the ones I’m picking) is excellent.  Aside, Berlin is a cool spot, I must come back here sometime again to have a decent look around…

Deployment and Continuous Integration from the Trenches, (Fernand Galiana - LiquidRail)

• All about latest developments for Capistrano 2.0 - it seems to have matured considerably in recent months.
• Use multistage_ext
• Use shared project capfiles to keep things DRY
• Use remote repository cache to speed up deployments
• Read Jamis Buck’s blog and the Capistrano Google Group

Really Scaling Rails, (Britt Selvitelle - Twitter)
I’ve seen presentations on Twitter scalability, and even since then they have had a few more high profile outages (at least high profile amongst Twitter users). A couple of interesting takes from this talk:

• Twitter uses Apache, mod_proxy_blancer and mongrel servers
• All user traffic is handled by a single MySQL server. That server does have a slave that can be promoted to master (for redundancy). They have a couple of other MySQL databases for use internally for reporting etc.
• They set mongrel’s num_procs to 1. This means that each mongrel server instance will not queue requests from mod_proxy_balancer - they will only accept one at a time. The side effect is if the concurrent request count > mongrel server count then users start getting error pages. Strangely, they’d rather users got errors than risking loosing queued requests whenever they have to restart a mongrel instance (mongrel apparently waits only 60s before sending itself a TERM signal when shutting down).

Rails Full Text Search with Ferret

A little different to what I was expecting, Ferret provides an indexing service for arbitrary strings (documents), similar to Apache Lucene in many respects.  Worth a look, if you need to support full text search within your rails application.

Tabnav: Do We Really Need a Plugin for Tabbed Navigation? (Paola Dona - Seesaw)

The title of this one was a a bit modest as Paola presented a slew of new Rails Widgets that SeeSaw have developed, all of which seem to be very flexible. Widgets for include tabbed nav (or course), site nav, tables (blocks), nubbins, show/hide blocks, help popups were all demoed. Their widgets integrate very nicely into the rails views/templates - all in all, it looks at least good enough for use in creating rails app prototypes and it appears they might be flexible enough to be embedded into a production application…
The Rest of REST (Roy T. Fielding) - slides

Good historical view of where Roy came from and how the principles of REST have always been such an important underpinning of the IETF’s thinking behind standardization of key web specifications like HTTP, URI and HTML. He provided a good overview of how the web architectural style is defined as a set of constraints:

• client server
• stateless
• caching
• uniform interface
• layered systems
• code-on-demand

There was some interesting discussion on what is missing from Rails though Roy’s first two suggestions drew comments that he might have missed features in Rails that do what he wanted.  His last suggestion, for Rails to guide the developer into using hypertext as the engine for of application state (man they really have to find a shorter name for that!) was a fair comment - seems like an incredibly difficult problem to solve in a generic framework like Rails but as he said, it’d be a first…
Last talk was Craig McClanahan finishing off the day with a short Rails and the Next Generation Web pitch.  Now I hadn’t realised Craig had switched from Java to Ruby development and he seems to be loving it.  Craigs name has all over the Apache code I’ve worked with for years now - he was one of the original Tomcat Catalina & Struts developers and he also co-authored the Servlet and JSF specifications.  He had an interesting anecdote about how the Struts developers all suddenly found themselves working on non-struts based projects…

Describing RESTful services.

A recent discussion on rest-discuss related to describing RESTful resources has lead to interesting discussion by Aristotle Pagaltzis, Stefan Tikov and Don Box on the topic.  They highlight a couple of issues that have been bugging me (at Oisin’s expense I think!):

• 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?

Google Reader on the N800 and Wii

I was trying to use Google Reader on my N800 at the weekend and it just didn’t work well enough to be usable. The page layout and text size really isn’t suited to a 800×480 display, I was scrolling far too much to reach important buttons/links and some of the AJAX controls (such as the tree nodes) just did not seem to react to touchscreen input.

However Google Mobile Reader has more than saved the day. This stripped down version of reader is designed primarily at mobile phone handset users, but it works very well on the N800.

The main page, once logged in, shows the ten most recent posts with convenient page-forward and mark-as-read-and-page-forward links:

The Subscriptions page is simplicity itself - a flat list of feeds, with feeds that contain new posts at the top of the list.

Each Feed page (http://www.google.com/reader/m/view/feed%2F<HTTP-encoded-feed-URL>) is almost as simple but with one line of the entry body under each item, and additional navigation/mark links at the bottom:

Each Entry page (as above with additional query string) is also simple, with convenient links to see the original feed entry page, along with links to star, mark as read and move to next.

Note my recurring use of the term ’simple’. In this environment, simplicity really does win the day and in this case it adds up to a very usable service. The fact that it is perfectly synchronized with my laptop feed reader is a significant plus. I left NetNewsWire behind a long time ago because I just couldn’t coordinate reading sessions across my home mac and my work pc. This is really another type of client that I want to read the same data access the same service with.

And then I noticed that they have a custom Google Reader for the Wii too, with bonus Wiimote integration! It is going to take a lot to get me to ever switch to a different feed reader.

RESTful solutions.

Interesting comment by James Clark in his first blog post on the topic of weaknesses in the current XML/XSD data binding solutions when used to encode remote message payload:

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?)