Author Archives: David Caruana

Web Script features you may not know about…

We at Alfresco often shout about the great new capabilities we add to the product e.g. Share, SURF, SPP. But we also continue to make minor improvements to existing parts.

For example, did you know that the Web Script framework gained over 10 new features in the release of Alfresco v3 ranging from “Content Negotiation” support to JAX-RS compliant URI templates, most of which are driven by our CMIS implementation.

Perhaps the most hidden feature is the complete refactor of the framework to allow it to exist outside of the Alfresco Repository. Web Scripts can now be hosted stand-alone in Portals, SURF etc. Although completely refactored, all existing Web Scripts continue to work without modification.

The list of new Web Script features and documentation for each can be found on our WIKI.

Facebook Application in 9 Lines of Code

Our recently introduced Facebook integration platform is an interesting showcase of Alfresco’s Web Script framework.

I’ve been meaning to provide a quick overview here, but an Alfresco developers life is always busy working towards Alfresco vNext.  However, I had to write something after reading the DZone article ‘Apache Wicket Facebook Integration‘.

The article provides full source code to the simplest of Facebook applications; List My Friends.  It’s cool to see a framework that assists Java developers build Facebook apps (it’s mostly a PHP world), but this simplest of Facebook application requires 100 lines of code in Wicket.  And I don’t think that’s all of it, as there must also be configuration to complement the code.

Here’s the equivalent in Alfresco… create the following files in the Alfresco repository:

app.[insert api key here].js

app.id=”[insert application id here]”;
app.secret=”[insert application secret here]”;

listfriends.post.desc.xml

<webscript>
<shortname>List My Facebook Friends</shortname>
<url>/facebook/listfriends/</url>
</webscript>

listfriends.post.html.ftl

<#list facebook.friends as friend>
<fb:name uid=”$friend”/></#if friend_has_next>, </#if>
</#list>

That’s a total of 9 lines of code.  There’s nothing else to it.  Not even a build step.  Just register the application with Facebook.

That’s 1/10th the lines of Wicket, or 300 characters vs 4000.

Once the 9 lines of code have been developed, you’ll want to go through a test, code, test cycle.  Web Scripts make this simple, just change the code and hit refresh in the browser.  Wicket’s Java equivalent just doesn’t allow this.

Facebook apps are mostly content oriented in the context of a social graph. This is where Alfresco really shines, as of course, it provides a full set of content management services all accessible in Web Scripts.

Facebook Integration is just one showcase of Web Scripts.  The same principles apply to developing an Alfresco application, dashlet, JSR-168 portlet, iGoogle gadget, Atom feed, JSON data service, RESTful API, …

RESTful Web Scripts – Servlet Based But Java Not Required

An interesting discussion is taking place on how one would produce a URL space for a blog style archive using Servlets + JSP. I’ll describe the approach Alfresco has taken, which although does not directly complement Servlets + JSP, it is built upon Servlets. Alfresco after all, is a Java implemented application.

“How to produce the URL space” was just one question we considered whilst designing Alfresco RESTful services. Our world is slightly constrained. First, we aren’t concerned with supporting any service; we want to allow our community to develop content management oriented RESTful services – the URL space problem is the same, but the implementation behind the URL space is focused. Second, we don’t want our community to know Java. We want to offer Alfresco to a wide audience, and whilst they can interact with any client environment, we don’t want to constrain those with no Java experience to our rigid view of server resources (with associated URL space & implementation) and rigid view of granularity / transactions. Third, we’re not building another fully-fledged UI framework. The focus is on data allowing the exposure and management of content residing within the Alfresco Repository via RESTful (or not) services, although, that hasn’t stopped the building of HTML UI with it.

We decided to take a declarative (XML & URI Template) + server-side scripting (Javascript & Freemarker) approach, building upon scripting technologies already available in Alfresco. This essentially allows the mapping of arbitrary Resources (URIs) to any Alfresco content & services. Resources are introduced without the need for a compile or deploy step with a minimum of XML plumbing (convention over configuration where possible – annotations not available here). Alfresco itself may be used to manage the development of such declarations and scripts. I say Resources, but of course, any form of URL may be constructed meaning RPC style services can still be built; the framework does not interfere.

We chose URI Templates for expressing the URL space for two reasons. First, it’s powerful enough for most scenarios (time will tell if we have to introduce a regex style mapping) whilst understandable by all, and second, it allows for smarter client binding in the future where URI Template Parameters are given universal meaning. Simple helpers are available for Resource implementors to retrieve useful parts of the request URI based on the Template.

At this point it’s best if I just point you to some examples (folder, search feeds…) built with the framework, and the full URI reference for yet more examples.

Given this framework, the next question for us is how to expose all the built-in Alfresco Repository entities & services as resources providing a supported out-of-the-box starting point API. We’ll probably wait to see if anything happens in the standards space (with an eye on ATOM/APP too), but in the mean-time, the Alfresco community will gain experience from developing their own RESTful (or not) content management services.

Alfresco Web Services Revisited

Alfresco first introduced its Web Services for Content Management back in July 2005, almost two years ago. In those two years the software world has radically changed. Think back to July 2005. Google Maps API had only just been released, the whole Web 2.0 thing had only just started to roll, Mark Baker and company were way ahead of the curve while the rest of us believed in SOAP, and had you heard of the Arctic Monkeys? Today, it’s all about mash-ups, rich applications, scripting and the network as the platform. And of course, you can’t ignore the current REST Fest, now we’ve all caught up – could it be that SOAP slips away to be replaced with what was already there.

Given this trend, ECM should rethink the way it provides Web Services. Imagine being able to expose your enterprise content resources (folders, documents, searches, categories, versions, discussions, workflows etc) to your network with the minimum of effort; distributed resources that can be retrieved, managed, mashed by any part of your enterprise software suite. Imagine being able to build custom content services specifically for your domain and application needs without Java knowledge, tooling, compilation, stub generation or XSD.

Here’s an example of how such a resource (a folder) might be exposed (as an ATOM feed) via a HTTP URL:

Description File: folder.get.desc.xml
<webscript>
  <shortname>Folder listing</shortname>
  <url>/folder/{path}</url>
  <authentication>guest</authentication>
</webscript>

Execution Logic File: folder.get.js
model.folder = search.lookupByPath(url.extension);
if (model.folder == undefined)
{
  status.code = 404;
  status.redirect = true;
}

Response Template File: folder.get.atom.ftl
<?xml version=”1.0″ encoding=”UTF-8″?>
<feed xmlns=”http://www.w3.org/2005/Atom”>
  <title>Folder: ${folder.displayPath}/${folder.name}</title>
  <updated>${xmldate(date)}</updated>
<#list folder.children as child>
  <entry>
    <title>${child.name}</title>
    <link rel=”alternate” href=”${child.url}”/>
    <icon>${absurl(url.context)}${child.icon16}</icon>
    <id>urn:uuid:${child.id}</id>
    <updated>${xmldate(child.properties.modified)}</updated>
    <summary>${child.properties.description!””}</summary>
    <author><name>${child.properties.creator}</name></author>
  </entry>
</#list>
</feed>

Normally, I don’t post code in a blog, but this demonstrates how simple it could be to implement a content web service backed by an ECM Repository.

And this leads to Alfresco’s new web services for Content Management. With our soon-to-be-released v2.1, the installation of the above service is performed by just copying the 3 files to the Alfresco Repository Data Dictionary. The service is then accessible via a HTTP GET e.g. to retrieve an ATOM feed for Alfresco’s Company Home folder, issue…

http://<host>:<port>/alfresco/service/folder/Company%20Home

This is a simple example of an Alfresco v2.1 Web Script. An Alfresco Web Script provides a service on the web where the service may perform any function, but are particularly suited to Content Management as they’re backed by all Alfresco Repository features. They’re ideal for building content access & update APIs, simple UI components such as content-oriented Portlets, and integration adaptors. As an example, Alfresco’s v2.1 OpenSearch has been re-hosted as a series of Web Scripts.

Each Web Script is bound to a HTTP method & custom URL Template and implemented with XML (description), Javascript and Templates. A library of URLs may be composed to provide a complete (RESTful) HTTP API. Support for multiple content-types such as ATOM, JSON (including callbacks) is provided, as well as authentication, response status codes, a simple customization model, and pluggable Web Script Runtimes.

The latest Alfresco nightly builds and SVN revisions provide the full Web Script framework. Try it out and give us feedback before we go final.

Now, you can mash your enterprise content.

Alfresco OpenSearch

Alfresco v2.0 adds support for OpenSearch.

OpenSearch is a specification for sharing search results, extending existing schemas such as ATOM and RSS. Execution of searches is supported via HTTP requests and responses.

OpenSearch comprises of:

  1. Description documents that describe the availability of a search engine
  2. Template Urls that describe how to invoke a search
  3. Paged search results in (extended) ATOM, (extended) RSS and HTML
  4. Auto-discovery of Description documents (i.e. search engines)

Alfresco exposes its own search capabilities via OpenSearch. This means that any OpenSearch aware client can search an Alfresco Repository to retrieve paged results in either HTML, RSS or ATOM formats. This includes the Web Browser. You can use your favourite Web Browser (IE7 or FF2) to search Alfresco. Auto-discovery of search engines makes it easy to register Alfresco as a Web Browser search engine.

browser.gif

This is cool, but we really wanted to use OpenSearch as a foundation for Alfresco federated search i.e. search many databases with a single query. And this is what we have done. The Alfresco Web Client now provides a search aggregator (available in the Sidebar and Dashboard) which submits a single query to one or more databases (Alfresco or non-Alfresco) and presents them in a unified user interface. Results may be paged through. The aggregator is OpenSearch aware. Of course, AJAX techniques are used to provide an interactive experience and minimise transmission costs.

dashboard_query.jpg

Whilst implementing this feature, OpenSearch has also allowed us to dip our toes into REST waters. Some of the experience gained here may be applied to provide a REST based interface to all Alfresco services in the future. ATOM, APP, OpenID and Microformats may also play a role. OpenSearch “template” URLs are interesting. They could be applied to any HTTP service, not just search. A really simple WSDL, if you like. There are many OpenSearch engines and clients out there now, demonstrating how a simple specification can gain adoption quickly. It’s a shame that most engines currently only provide HTML responses. This is fine for Web Browsers, but not aggregators. Perhaps a “search result” microformat can help.

To summarise, Alfresco is both an OpenSearch server and client.

Search Alfresco with your favourite OpenSearch clients, or search your favourite OpenSearch databases with Alfresco.

http://wiki.alfresco.com/wiki/OpenSearch

Open ECM and BPM – Now integrated

One of the main themes of the nearing preview release of Alfresco v1.4 is Business Process Management where Business Process & Content Management finally meet – BPCM :-)

I’ve been focused on v1.4 development for a while now, but recently when coming up for some air, I caught the interesting blog entry “BPM and ECM Intersecting?” posted by Russ Stalters. He comments that mature ECM suites all have document centric workflow, but many of the larger ECM vendors are expanding this capability to include full fledged BPM.

Well, we can now add another ECM / BPM integration to the list. This time though it’s pure Open Source.

Alfresco ECM v1.4 embeds JBoss jBPM. The result is a single open ECM stack, which tightly integrates Content Management and Business Process Management services. This really is a case of 1 + 1 = 3 (or should that be free).

Combining open source technologies is interesting; not just because of the technology gains, but also because of the community gains. A whole new community (JBoss jBPM) whether they know it or not is now directly or indirectly improving Alfresco ECM. That’s good for us and our customers. And in return, we’ll be making JBoss jBPM better too. For example, JBoss jBPM is working on BPEL support. When that’s ready, the Alfresco ECM stack will be taken to a new level allowing support for Enterprise Wide Processes crossing many applications and services. We’ll neatly slot in with our already provided Content Management Web Services. And all of this for very low development costs.

Details of our BPM support in v1.4 can be found in the following “preview” documents hosted at our WIKI:

You’ll be able to get your hands on the preview soon. In the meantime, if you can’t wait you can always pull our source code from SVN:

svn co svn://www.alfresco.org/alfresco/HEAD

It’s all open.

Workflow in v1.4 Alfresco

There are claims that one of our product weak points is Workflow even though workflow in conjunction with rules and actions has been a unique feature of the Alfresco product since first release.

Although our current workflow offering is very simple to setup and administer (which is liked very much), its simplicity means there are some limitations as to the complexity of business process that can be defined. So, to address this, Alfresco 1.4 will introduce advanced workflow capabilities laying the foundation for our WCM offering currently in development, as well as enhance the document management capabilities we have today.

Advanced workflow really means having the ability to declaratively express business processes of arbitrary complexity, user task allocation & inbox support and workflow tracking. We’ve chosen to embed the JBoss jBPM workflow engine (although others may be plugged-in, Alfresco style) which will be tightly integrated with the Alfresco Web Client and Content Repository services. Out-of-the-box content-oriented workflow templates will also be provided.

We’re just starting the development of this feature where our intent and design is openly available on the Alfresco WIKI; we welcome your comments and feedback at this stage.

Not yet a year, but almost!

Believe it or not, Alfresco (source code and all) was released into the wild on June 27th 2005.

The Alfresco Community born on that day will soon be 1 year old. So, Happy Birthday.

A year doesn’t seem long enough to have developed the Alfresco product we have today (ok, development actually started in Mar 2005), but that rate of development can only come from the Open source approach where engineering have direct contact with the community and the community have direct contact and contribution channels with engineering.

Here’s to the next year of joint product development. Cheers.