Struts...Tapestry...Seam, these are all fully featured, open source and very active Java Web app frameworks. And all were available to the Alfresco Enterprise CMS architects when they played deciders for their recent 2.1 release.
Why then did they choose to go "back to basics" with a Servlets+JSP approach which leverages the lesser known URI Templates specification when implementing their new Web Scripts functionality?The direction chosen by the technical powers-that-be at Alfresco is indicative of a recent movement away from well-known, and some might say over-hyped Java Web frameworks.
This movement, characterized by efforts such as the Restlet project, represents the desire to take what is made available by the Servlet specification and add only what is necessary to fill in the gaps in order to fully support REST.
As Stefan Tilkov might put it, the goal of this direction is not to "hide the Web from developers", rather to make it as painless as possible to work with.
Due to the newness of Alfresco 2.1, it is hard for us to determine how close the Web Script implementation comes to achieving this goal. However, we can look at the intentions of the Web Script functionality and use them as a sort of crystal ball to help clear the cloudy future of RESTful services and content management.
What is a Web Script?
A Web Script is a web service that is specially suited for content management functionality because it is supported by an Alfresco repository. As a web service, a Web Script is bound to an HTTP method and has a custom URL. The idea is for a library of custom URLs to be built that will eventually constitute a full RESTful HTTP API.
At the heart of Alfresco's Web Script functionality is the idea that developers need not know Java in order to access and work with Alfresco's content services. But Alfresco is implemented top-to-bottom with Java, right? Correct. But in an effort to lower the dreaded "barrier to entry" and encourage the inclusion of Alfresco in more diverse architectures, developers can now use the HTTP functionality of the programming language they like best to access Alfresco's content services.
Furthermore, Alfresco 2.1 does not include a brand new full-fledged UI framework that developers will need to learn and conform to. Rather, the nature of Web Scripts encourages developers to build or leverage their own user interfaces, as they see fit. The idea -- much like we see with competitors Nuxeo (news) and SharePoint (review | news) -- is to look at the product as more of a blackbox content services foundation.
Do We Want Web Scripts?
While it is natural to applaud Alfresco for their progressive architecture stance, the reliance on new and evolving specifications may scare off the core of enterprise architects. These senior geeks often see the huge number of Struts and Tapestry or SOAP Web Services implementations as a warm blanket of reliability and familiarity.
Yet there's another side to this. With the campaign for Enterprise CMS hearts and minds still very much up in the air, this could prove strategically interesting for those looking to quickly bolt on and/or build proof of concept prototypes with an ECM system. The powers of lightness and simplicity are significant and may prove a strategic win for this blossoming vendor.
What's your take on Alfresco's RESTful Scripts direction? Does this decision ring attractive like for you or is a new design pattern the last thing you wanted with the morning's coffee? Go on and tell us what you think.