Aehso’s Output

Joe Andrieu has an interesting take on the how the incubating VRM project is evolving.

I lean towards agreeing with Joe. I like the idea behind APML in that I can see the need for a standard format for publishing attention information. However I don’t think it is credible to attempt to specify how to safely distribute and share attention data (which has privacy and trust issues written all over it) using a simple annotated schema document and a php-based example parser implementation. Problems

• The core APML XML schema is woefully underspecified. The semantic meaning of the various elements/attributes is really not clearly specified at all. To illustrate what I mean, compare and contrast the Atom Syndication Format specification with the APML specification.
• There is no protocol specification how to access/update APML documents. Again, referring to a specification like the Atom Publishing Protocol highlights the need for such a specification.
• At this stage, I think anyone producing specifications that essentially contain lists of data for consumption by arbitrary web based clients should seriously consider extending the Atom (or RSS) syndication formats rather than rolling their own schema.  They should also consider adapting AtomPub for publishing this type of content (e.g. as Google did for OpenSocial APIs)
• The APML specification seems to have been developed in a sandbox. I know it is listed alongside OpenID, microformats and others at (what is now the buzz site of this week) DataPortability.org but it does not build on or integrate with any of these specifications (worth noting that Chris Saad is behind both efforts). There are no requirements, recommendations or guidelines on how to use APML within the context of existing and pending web infrastructure.  Sure I could build an APML service and then stick it behind an OAuth login system but then I may end up with a service that nobody can use with their client libraries.

That last point actually brings me to something else I’ve been meaning to blog about – DataPortability.org.  First off, I think this website is a commendable effort at raising the profile of the specifications it is linking to.  However, and this is a big however, I have seen this happen before many, many times in enterprise-software-land (I’m looking at you CORBA and J2EE vendors!).  Consortium of big vendors would get together to discuss reference designs or ‘profiles’ for combining various specifications into an “industry recommended solution” that is then vaguely referenced by each company’s website to claim ‘compliance’. 
However, in the absence of free and open reference implementations for these solutions (and I mean an integrated reference implementation here) true compliance and interoperability will never really be achieved.  There is simply no carrot there for the vendors to work hard to achieve this and there is no stick large enough for the community to beat them with to play fairer.  So I’m afraid that for now I’m not drinking the kool-aid regarding Google and Facebook joining DataPortability.org  Sorry, but given both Facebook and Google’s recent track records I can only assume that this is mostly a PR exercise.

aehso apml, atom, atompub, facebook, google, vrm

Starting to read through the OpenSocial API documentation the most striking feature is that ALL of the underlying data APIs are Atom and AtomPub based.

• The People Data API exposes people (viewer, owner, friends) via Atom feed documents and Atom entry documents. However, there is no AtomPub support for this feed so people cannot be created/updated/deleted via API. I suspect this will cause some debate as it means some fairly critical data remains locked into the underlying OpenSocial containers
• The Activities Data API exposes activities (news feeds etc) as a Atom feeds. The Activities data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
• The Persistence Data API exposes name/value pair data (e.g. configuration params) as a Atom feeds. The persistence data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.

I’m off for a curry but more later today. Here’s a teaser though – authentication is a concern….

aehso api, app, atom, atompub, google, opensocial, social

I completely agree with Brad and Fred – Alex Iskold’s The Structured Web and Facebook: What If More Is Less? contain some great concise analysis of the how the web and the networks within it are evolving.

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

aehso atom, blogging, rss, social, web services, web2.0, xml

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.

aehso architecture, atom, django, enterprise, esb, internet, python, rails, rest, rss, ruby, sca, soa

The Atom Publishing Protocol (APP) is gaining some serious traction since it went final a few weeks ago. YouTube have announced that their new APIs are APP/GData based and now Pete Lacey, Sam Ruby and Tim Ruby Bray have finished adding support for APP to WordPress, in time for WordPress 2.3.

This bodes well as APP and GData are two of the the core protocols supported by the new feed commerce platform that we (nooked) are busy building. Anyone working on services that exposes collections of resources should read the APP spec – the RESTful approach for publishing collections works so well…

aehso app, atom, wordpress, youtube

Bill de hÓra has a nice piece on Struts 1 that touches on something about MVC that I’ve never quite liked in the web application context:

In pattern language terms, the MVC pattern has been reapplied to the Web domain without consideration for the forces induced by the Web. MVC frameworks tend to be inwardly focused contraptions of server sided redirects. Alternatives: On the web, a suitable pattern is View, Model, Template. A request to a URL is dispatched to a View. This View calls into the Model, performs manipulations and prepares data for output. The data is passed to a Template that is rendered an emitted as a response. ideally in web frameworks, the controller is hidden from view.

I like the View, Model, Template pattern suggestion, the separation of View (which data can be displayed) and Template (how it gets displayed) is an important one that I think too often gets lost in web application development.

If only the framework could be the entire controller all on its own though! Even the Ruby On Rails (the poster boy web application framework of the moment) cannot do everything unaided.  Writing controllers is not too bad if you are exposing RESTful resources – much custom controller logic is then reusable though things like authentication still intrude.  RPC oriented web appications are the ones that can really end up suffering from horrendously complex controller definitions.

The other main difference between Java/Struts1 and something like RoR is the considerable benefit gained by being able to define the controller completely within in the host language rather then having to resort to a code+XML definition.  I don’t think this should be underestimated. Personally I have always found the biggest impediment to grokking, testing and maintaining Java/Struts1 application code was the mixed Java/XML implementation, and the IDE support it almost demands when used in anger.

BTW, big contratulations to Bill on getting the APP spec (nearly) finished!

aehso atom, java, mvc, rails, ruby, struts

I have been quiet haven’t I!  The recent blogging hiatus was for two very good reasons though – I went on vacation to the US with Aine (hi sis!) and since getting back I’ve been up in Sligo meeting the good folks at Nooked whom I’m joining as their new CTO. 

Exciting times ahead, Nooked already have great products but they also have the vision and plans to deliver a truly disruptive feed commerce platform – more on that later.

This is going to be great!

aehso atom, nooked, rss, web2.0

Speed up feed reading with Google Reader by learning a couple of simple keystrokes to avoid ever reaching for your mouse:

Lather:

• Open Google Reader
• Shift-n – Selects your first folder (or feed)
• Shift-o – Opens the folder (or feed)
• 2 – Switches to the (abbreviated) entry list view

Rinse:

• <space-bar> – Expands the first/next feed entry
• j, k – Expands the next or previous feed entry
• n, p – Selects the next or previous feed entry
• o – Expands/collapses the current feed entry
• v – Opens current entry URL in a new tab or window
• s – Stars the current entry
• Shift-a – Marks all unread feed entries as read

Repeat:

• Shift-n, Shift-o – Select & open next folder/feed

Help:

• ? – Opens a popup keyboard shortcut guide

See, no need to use the mouse!

aehso atom, google, rss

Tim Bray bites back at Dare Obasanjo’s recent critique of APP. 

There are places (network TV, Middle Eastern politics) where cluelessness regularly triumphs. Internet protocols aren’t one of them. Sorry, Dare.

Ouch!  I definitely have to re-read the APP specification and play a bit more with Abdera or some-such before deciding (Bill de hÓra’s related post also appears to be worth understanding)…

aehso atom, xml

This should be an easy one for Google to fix but it’s still borken. Since the weekend, Google Mobile Reader on Opera/N800 is failing to render the home page with the following error:

XML parsing failed: xml processing instruction not at start of
external entity (Line: 5, Character: 0)

The offending page content reads as follows:

<!--
Content-type: Preventing XSRF in IE.

-->
<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd"><html
xmlns="http://www.w3.org/1999/xhtml"><head><itle>Google
Reader</title>
<meta http-equiv="content-Type" content="application/xhtml+xml;
charset=UTF-8" />
<style type="text/css">
...

Err, why is there a comment before the XML declaration? If this is supposed to be valid XML it shouldn’t be there. I’m surprised the various other mobile platforms are forgiving enough to ignore this (or is it borken on them too and nobody has noticed?). Please Google, fix your XML.

(discussion ongoing here)

aehso atom, google, rss, xml