Rivet Logic Blogs

Category: Rivet Logic

Last week was a busy week for those of us working on Crafter Rivet, the WEM/WCM extension for Alfresco 4.0. We’re extremely excited about this release and are busy scheduling events and demos as word is starting to get out!

For existing Alfresco WCM customers on Alfresco version 2 and 3 using the AVM based solution, we’ve put together a couple of blogs to help you think about your migration to Alfresco 4 and the core repository:

For everyone who wants to learn more about this exciting and powerful open source solution for web content and experience management that sits on top of Alfresco, the world’s most open and powerful content management platform, we’re hosting a Crafter Rivet Roadshow in a city near you in May! Come on out for content packed presentations, demonstrations, Q & A and free lunch!

In yesterday’s post we covered the fact that Alfresco stopped selling the AVM based WCM solution to new customers. Existing customers using the AVM based approach will continue to receive support until the AVM reaches end of life status. New customers looking to Alfresco for WCM/WEM capabilities who read this will naturally wonder what is the approach to WCM on Alfresco. Existing customers will want to know how to migrate off the AVM and in to Alfresco’s core repository.

As we have seen in yesterday’s post, the core repository has had the benefit of continuous innovation through which it has grown as a platform now capable of supporting use cases critical to WCM/WEM with key features like remote file deployments and form based content capture. Along with features clearly directed at the WCM use cases, the core repository is host to an amazing array of features and capabilities that make it ideal for all manner of enterprise management, WCM/WEM included.

At Rivet Logic we have made a significant investment in a web content and experience management extension to Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured application that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to covert. Just released, Crafter Rivet 2.0 is 100% based on the core repository, Solr search and Actviti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

Now that we have a background understanding of both the AVM and core repository features we discussed yesterday it is time to look at the use cases that the AVM was designed to address. We will discuss the use case and how these gaps were addressed by Crafter Rivet. Let’s get started!

Use Case: Sandboxing
As described in yesterday’s blog, sandboxing is a feature but there are use cases that drive this feature. In a Web CMS context we have times when we need to modify templates, CSS and other assets that have far reaching effects on our sites. There are three common use cases that point to sandboxing:

Development: As a developer I want to work with a template, a CSS file, a JavaScript library, etc. without worrying that the bugs I will inevitably create will interfere with the rest of the teams ability to produce, manage, preview and publish content.

Timing: On websites of significant size and complexity, there are often times when projects are created to update the look and feel of the site. These projects with future delivery dates need to be able to take place without interfering with daily publishing. Further, it’s important that the project be able keep up with on-going updates to reduce the headache of last minute merges.

Playground: Sometimes we just want to play. Sandboxes allow us to enable team members to innovate and play around without fear of impacting the live website.

It’s clear that the ability to sandbox (or branch/merge) your website code base can be pretty handy. In my mind there are several key questions:

Is the support for this use case a “must have” for my specific environment? How often do I run in to the use cases above?

What granularity of sandboxing do I need?

Many popular Web content management systems do not natively support sandboxing. In a lot of cases the need for the branch merge capability is handled through the development and deployment process. In general I think it safe to say this feature is a rather strong “nice to have” unless you have an site with look and feel components which are literally being constantly updated and where the traditional development process would add too much time to the effort.

When you do need sandboxes the next question is granularity and how sandboxes are used. The AVM UI dictates sandboxes for each user. In my experience accumulated over many Alfresco WCM engagements; is that this was too fined grained for the needs of most engagements. Most users want to work directly in context with other users. They need basic locking on individual assets to keep work safe during their edits but they don’t require an entirely separate and parallel universe. The ability to create a sandbox ad-hoc for a specific purpose maps more directly to the needs we see on the ground. In other words, a sandbox is too granular but a sandbox for a project to update the look and feel of the entire site where users could work together would more aptly address the kind of needs we see.

Crafter Rivet starts with the first finding, that sandboxing is not a “must have” feature and that in-fact when it is applied it should be done so to facilitate specific projects and specific ad-hoc needs. If you look at the way we have structured our content in the core repository you will see we have left room to support one or more draft copies of the site. In v2.0 we do not support layering in the default configuration; however, Crafter Engine, our content delivery and preview tier, is able to sit over top of multiple hierarchical stores and present them as one store much in the same way the AVM did.

Use Case: History and Reversion in a Web CMS Context
As a user, when I want to preview a version of a specific asset, let’s say a page, I want to see the page as it was on that day. That means I want to see exactly the same components and assets (images, CSS, js etc) as they were on that given day. This is a real challenge in the core repository because there is no native support linking assets together under a common version; each asset is individually versioned and the links between objects (associations) do not capture version.

Now to be honest, I have simplified the problem a bit to make a point. I said that pages, for example, are compound assets and that you are always interested in seeing their dependencies at a given point in time. This is often the case when we’re talking about images and components that are specific to the page but it’s not really the case when we’re talking about shared assets like templates, CSS, JavaScript, and shared components and shared collateral. Think for a moment about why users want to look at and ultimately revert to previous versions of content. They are doing so either:

In the short term because they have made a mistake, or

in the long term because they need to revert messaging to a previous point in time.

In the first instance there is likely to be no issue. Common assets are likely going to be the same as they where at the point in time of the version. However, in the second case, we really want to see the old content in the context of the current templates, etc. If we revert, it’s to get the older content, but we’re going to deploy it in the context of the latest look and feel of our site.

Handling versioning in Web CMS is a must have, must do capability.

In Crafter Rivet we considered these use cases fully and drew a distinction between two types of relationships. Those relationships which are page only and those which are shared commonly amongst other objects in the system. When you revert a page or any other object, those relationships which are “page only” will revert to a point in time, while other relationships that are common will continue to align to the latest version of the asset.

To accomplish this we leverage both the native versioning capability of the core repository as well as file organization and patterns. In short, we organize page-only assets in folder structures that represent the page. Page objects are given names that are based on a hash of the object to guarantee a unique name which means in effect that the versioning of the page only object is “horizontal” in the repository. By horizontal I mean that a new file path is used rather than relying on the version store. Shared objects like pages or other common assets are stored regularly and rely on the native versioning support. If you revert a page you will revert to an a state where the page points to a different set of file / file paths — achieving a solution for both use cases we mentioned above.

Snapshots
There are several Web CMS use cases that could require snaphsots and version diffs. For example, some websites have compliance related issues and thus must maintain versions of their sites so that in the event of a dispute over information communicated via the site they can easily prove what the site looked like at a particular moment in time. The question for snapshots is:

Is this something your organization must have?

And if so, is it something that the repository has to do for you?

Our experience shows that this feature, for the general market, is a nice to have. Most customers don’t take advantage of this capability. When we looked at this capability in Crafter Rivet, we decided it was not important to support natively within the repository itself. If a customer needs a snapshot every day we simply include a deployment target that would produce a snapshot.

For those wondering about snapshot rollback; our experience has shown that this particular feature is really not relevant to most customers in day to day operation. The feature has come in handy as a mechanism for bailing out people who have made sweeping changes to a site (100s of files) and deployed them with little or no QA only to find a broken website after the fact. In such a case, snapshotting a rollback is a life saver. With a click of a button you can revert 100s of files.

Crafter Rivet, by design is 100% file based. In such a crisis scenario, a simple file based backup could be used to restore a Crafter Rivet based site to a former state. In the repository, you are unlikely to desire an actual rollback. It’s more likely that you will want to keep the broken state and simply fix what is wrong and then redeploy the working site.

Moving Forward

Alfresco v4 is an incredible platform and the move to the core repository unlocks all of that capability and innovation. Crafter Rivet is a platform that made use of all of the functionality in the AVM. And with our new release, we made the move. You can as well. More importantly, if you are using the AVM with Alfresco v3 (or even V2), then Crafter Rivet is the perfect solution for your upgrade. We can provide parity for most needs with a much better user experience that goes way beyond basic Web CMS needs with the coverage of WEM use cases like integrated analytics and reporting, native mobile application authoring, preview, and presentation, content targeting and personalization, multi-channel publishing and much more. If you’re new customer to Alfresco looking for Web CMS solutions, Crafter Rivet is a comprehensive WCM/WEM solution, with features that rival some of the major players in the industry.

I was on a call today with a long time Alfresco WCM customer who would like to upgrade from 3.x to 4.x. They have been using the Alfresco WCM solution provided by Alfresco in 2006 for many years. As many of you know Alfresco’s original WCM solution is based on a technology called the AVM – Alternative Versioning Model. The AVM is a separate repository and associated user interface that was constructed to handle a number of WCM related use cases. Alfresco has since enhanced their offering in their “Document Management” repository, which now handles WCM use cases. As a result, Alfresco has now announced that the AVM will no longer be offered to new customers. In discussing the upgrade with our clients on the call today. “It’s time to move to the ‘DM’” was the most responsible message to provide. Existing customers won’t lose support over night, but eventually the AVM will hit its end of life. You want to migrate at your earliest convenience rather than procrastinating and allowing pressure to build.

It’s also important at this point to abandon the use of the term “DM repository”. DM was used to differentiate from the AVM. At this point there is only one repository. The “core repository” is much more descriptive of the architecture going forward. As Jeff points out in his blog and as I will elaborate here, there are differences in the the AVM and the core repository in terms of features. That said, features and use cases should not be confused. The core repository is every bit as capable of providing a platform for Web content management use cases as the AVM.

At Rivet Logic we have made a significant investment in a Web content and experience management application for Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured environment that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to convert. Crafter Rivet 2.0 is now based on the core repository, Solr search and Activiti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

I thought it would be helpful to share some of that thinking. Today we’ll look at the differences in these repositories and tomorrow, in a second post we’ll discuss the actual Web CMS use cases that need to be addressed and how we addressed them in Crafter Rivet. Let’s explore!

Unique Features of the AVM

The first thing I want to do is address the question of what the AVM can do that the core repository cannot. Because we’re comparing repository to repository we’re going to discuss features and not use cases. Note that for simplicity, on occasion we’ll collapse the features of the AVM repository, supporting UI and supporting integration into the single term AVM. It’s also fair to note that what we’ll discuss here are the aspects of the AVM which exposed through the associated user interface and thus applicable to customer engagements. There are features/capabilities of the AVM repository that were not fully exposed by the UI.

Sandboxing (more accurately, layering)

Sandboxing is the ability for a user to work on any asset or group of assets within the site without interfering with another user’s work. For example, a user could modify and even break a template or CSS file and no one would know until and unless the user promoted that broken asset out of their work area. For non-technical readers, a sandbox is best described as your own copy of the website. For the technical readers, you can think of a sandbox as a long running transaction — in source control terminology, a sandbox is like a checked out branch of the site.

Sandboxing is a high order feature born out a lower level feature called “layering.” The AVM is constructed of lightweight stores. Stores can be layered one on top of the other. The store on the top appears as though it contains the assets within the store layered below it. If a user places an changed in the top store it appears to over-write the asset at the same path below it. If we have a base store we’ll call “the stage area” and then a store for each user; say Bob and Alice, and both Bob and Alice’s stores are layered on top of the staging area you can see how we create the concept of sandbox. Alice can see everything in the staging area, but nothing in Bob’s store. Alice’s work is in a “sandbox.” If Alice pushes her change from her store to the staging area, Bob sees it immediately as if it were in his store.

Multi-Asset Versioning

In the AVM, versions are taken at the store level not per asset. When you place a change in the store, a lightweight version is created for all assets at that moment. Because of this, it is possible to know the state of every object at a point in time relative to a given object. For Web CMS applications, we deal with compound assets all the time. Consider a webpage. A webpage is not typically a single file asset, it’s a document that points to other documents: components, images, css, javascript, etc. When you version a page, you generally intend that entire collection of assets to be versioned along with the page.

The core repository manages each individual asset’s version history independently. If page X points to component Y there is no innate support within the version system to know what version of Y was in use at any given point of X’s history.

Snapshots / Comparison and Rollback

In the AVM you can label a version and compare one version to another. It is easy to see what files have changed. Because of this it is possible to create “diffs” from one version to another. Once you have a diff you can roll back entire check-ins very easily.

Content Forms (Now supported in core)

The AVM user interface used to support a forms capability that was not available for the core repository. The forms engine made it simple to create content capture interfaces through mere configuration. Today the core repository has a forms capability that is more powerful than what was provided for in the AVM user interface.

Content Deployment (Now supported in core)

An AVM project could be configured with remote content receivers. There was out-of-the-box support for repository to file system deployment (FSR) and repository to repository deployment (ASR). Today the core repository provides two deployment mechanisms; Transfer Service and Channel Publishing framework, which combined now exceed the capabilities of the AVM content deployment framework.

Unique Features of the Core Repository

Now lets look at what the core repository has going for it that the AVM repository and supporting UI never got around to implementing. Again we’ll look at features rather than use cases.

Rules Support

The core repository allows you to attach rules to a folder that execute based on lifecycle events and configurable conditions. This is extremely powerful and its a feature that was sorely absent in AVM.

Stronger Modeling Support

Both repositories allow us to create types and (more commonly) aspects which contain metadata. However the core repository allows for associations at the modeling layer. In the AVM, associations were kept only as paths within files. This turns out to be fine for content delivery but bad for managing the content due to move and rename operations because of the unbounded number of updates you may have to perform. Associations in files also makes it difficult for supporting user experience features in your content management platform. Users expect a platform to understand it’s assets and how they relate to one another in a way that can be quickly accessed through query. The core repository can do this innately through it’s use of associations. The AVM cannot.

Strong Transformation and Metadata Extraction

The transformation and metadata extraction frameworks integrated with the core repository greatly exceed the capabilities of the those integrated with the AVM. The AVM is only integrated with an XML metadata extraction and transformation. The core repository on the other hand has integrated support for all kinds of metadata extraction and transformation including Microsoft Office documents, images, PDF and many many more.

Powerful, Fine-grained Permissions

The core repository gives us the flexibility to create and manage user access to content in a way that best fits an individual engagement through the use of ACLs (Access Control Lists.) While the AVM was based on a similar scheme under the hood, these were never exposed through the UI and thus it were not practical to deploy on engagements. Out-of-the-box AVM exposed a few roles that could be applied broadly to the entire site in each sandbox.

API support

The core repository has much better remote API support. The core repository supports CMIS, webscripts, and RAAr. AVM only supports a remote API based on RMI.

Workflow Engine

The core repository has 3 workflow engines integrated with it: Simple, JBPM, and Activiti. Activiti is based on standards and has parity with JBPM, but incorporates a far better management console. The AVM provides workflows based on JBPM integration only.

Search

Full text search support is based on indexing. You index a store. In the AVM universe every web project was made up of many (layered) stores. It was not practical to index every store. Although you can configure individual stores for indexing, if every author in the system wants to be able to search their sandbox, you will hit obvious limitations to the approach. The core repository content has only one store which is constantly tracked by a search index which means that search is very current with work in progress. Alfresco 4 has introduced Solr as one of its search subsystems. Solr provides capabilities that greatly exceed Lucene, the indexing engine used by the AVM.

Integrations

The core repository has many integrations that allow users to interact with content on their own terms, be it email, WEBDAV, FTP, shared drive, Sharepoint and so on. With exception to the filesystem projections, these are simply not made available in the AVM.

Native support in the UI and APIs for taxonomies, folksonomies and collaboration features

The core repository has repository service and UI support for

Hierarchical taxonomies

Tags

Comments

Content lists

Making Sense of the Differences

By this time you should have a pretty good idea of how the repositories compare from a feature perspective. Two observations are obvious:

The core repository has a had the benefit of deep continuous innovation.

The AVM has certain features intended for WCM use cases that will need to be addressed in a solution that leverages the core repository.

Join us tomorrow for a blog post that will demonstrate the use cases that these features were intended to cover and how we addressed all the Web CMS use cases with Crafter Rivet using and capturing the full power and innovation of Alfresco 4 and the core repository.

At Rivet Logic we do quite a bit of work with the JBoss Seam framework, specifically with our Content Management System integration we call Crafter rivet.

Seam can be used with the Spring bean factory framework, a popular “IoC” or Inversion of Control / Dependency injection framework. Spring enables developers to create instances of java objects known as beans and then to wire them to other java objects. Most people working in J2EE today are familiar with this so I won’t spend any time going in to further detail here. Seam also supports the ability to use java annotations to declare a class as a bean and to specify how it should be wired through what they call out-jection and injection. Check out the Seam website for more details on how the Seam bi-jection mechanics work.

One question that has come up for me many times on consulting engagements is: “which approach to use, Spring or Seam bi-jection?” My experience shows me that the answer is not one or the other. Both approaches have significant benefits and can be used together to create a stronger approach than either one can provide on its own.

Here are some very simple guidelines

When to use Spring beans:

Infrastructure components and services are great candidates for Spring beans

Such services are generally singletons within the system. Spring has excellent support for managing and wiring these objects

Such service classes are often packaged in separate more commonly used libraries. Hard coding a bean name and wiring within the class definition or strongly coupling to Seam is less desireable.

You want a very simple way to override the implementation at deployment time. Consider a scenario where you want to override a DAO. By managing the bean in Spring it is extremely easy to override the bean definition to use an alternate class and configuration in a given environment simply by placing an additional xml file in the classpath

When to use Seam annotations:

Domain specific components are good candidates for bi-jection.

They are often fine grained application specific components.

Explicitly stating how the component will be wired in the the class file has little impact on its re-usability because its scope is limited to the application at hand.

Such components really benefit from one of Seams strongest features in its bean framework: Conversation Scoping. This is the ability to define a life-cycle which is shorter than a session. By limiting the lifetime of a object to its true life-cycle it’s possible to free memory up for other needs within the system. On large, high troughput applications the benefits here cannot be overstated.

By using a combined approach you get the reusability and flexibility of Spring framework with the performance orientation of conversation scoping and ease of development associated with Seam annotations.

Alfresco is hosting a community meetup on Tuesday (details here) at which Rivet Logic will explore through a simple demonstration how the Alfresco repository, Share and WCM can be used in concert with one another to create a superior authoring and management solution for multi-channel enterprise content.

The introduction of Alfresco 3.0 Enterprise, Share, along with the work taking place for Alfresco WCM and Web Studio, a realm of opportunities have become readily accessible including the platform’s ability to facilitate not just workflow and concurrent editing but also first-class collaboration (including discussions, blogs, calendaring etc) around content that is intended for many consumption channels be it Web, wire feeds, PDF, print and so on.

Come to the meetup — and while you’re there check out this demonstration!

Since Alfresco was first released in 2005, I have led a number of projects that required some sort of custom user interface on top of the Alfresco repository. In a few cases, we customized Alfresco’s standard web client. For others, we built custom interfaces that were stand-alone web applications or were exposed via portlets within a portal framework like Liferay or JBoss Portal.

In most cases, we needed a user interface that was not embedded within the repository, but rather was hosted remotely as a standalone web application. To do this, the main choices for the web application to communicate remotely with Alfresco are the following mechanisms:

Each one of these approaches has its pros and cons and the choice is highly influenced by the client’s needs.

Alfresco’s Surf platform provides a powerful framework that enables developers to leverage most if not all of the repository’s features using a RESTful approach using their Web Script runtime engine. It also allows for the web tier to be remote to the Alfresco repository. Surf is a very good option for projects that have a Javascript-centric web tier, using frameworks such as ExtJS. We have successfully built and deployed several Web Script-based UIs for customers, including one of the very first public sites to leverage Web Scripts found at http://highschool.ccsso.org. In its most recent v3.0 release, Alfresco provides a UI platform for aggregating Surf dashlets to create fully functional web clients. This platform is known as Alfresco Share.

However, we also have customers who want a Java-based UI solution too. Alfresco’s original web client UI is a JSF/Spring based application that is customizable in many ways and is the only available alternative in this case (short of building your own web client). It is built using a large number of custom JSF components that are very nice as long as your target UI is expected to behave similarly to Alfresco’s web client. If you were asked to change the way one or more of these components work things start to get a little hairy especially when you realize how much work is required to make it do exactly what was needed. There was an apparent need for developing a Java-based UI platform that shared some of the Share features.

So we set out to fill this void: To create an open source, Java-based UI platform for Alfresco.

We turned to JSF for the view framework, as it is the predominant standard in the Java community. One of the challenges of JSF component development has always been ease of customization, or the lack of it. Even though the JSF spec allows for extending UI components, it is still not trivial to make your components very flexible. And what typically happens in those situations is that smart people decide to put in a lot of work into getting rid of the problem. That’s where the JSF component suites come in. There are a lot of them out there. Some open source, some not. Naturally I’m only interested in the open source ones.

When working with JSF components suites like JBoss RichFaces you gain a lot of leverage when you incorporate a framework that makes dealing with the JSF lifecycle both intuitive and easy. If you guessed that I was talking about JBoss Seam, you’re right.

Projects that are more Java-centric and make use of web frameworks such as JSF would find that a remote Java API that provides access to the Alfresco Foundation Services (AFS) is necessary. In this case, our own Remote Alfresco API rivet is ideal. It is both scalable and fits within the JEE tiered approach quite nicely.

For these reasons, the technology stack we used for building our Java-based Alfresco web client is comprised of JBoss Seam, RichFaces/Facelets, and RAAr.

So here was the perfect opportunity to bring all this technology together and provide the Alfresco community with an example of a new way for developing Web 2.0 rich web clients for the Alfresco repository. We decided that the web client had to be rich (AJAX is key here and RichFaces among other JSF component suites makes it possible), remote from the Alfresco repository, and modular so that it could be reused in other projects in the future. And while we were at it, it needed to be easy for new developers to contribute to.

We gave the web client a name that explains what it really is; Seam Client for Alfresco rivet — SCAr. (As an aside, because we incorporate RichFaces we also considered calling it ScarFaces :^)

From a high level, SCAr makes use of RAAr to utilize a complete suite of services that fully expose Alfresco ECM’s core services at the back-end, and a number of out of the box JBoss RichFaces AJAX enabled UI components at the front-end tied together using JBoss Seam to provide a single page multi-user interface to Alfresco ECM’s document management system. The following diagram shows a high-level overview of SCAr. The power of this architecture is in its inherent simplicity without sacrificing flexibility.

The internal architecture of SCAr is broken down into a number of RichFaces components each exposing one or more of Alfresco’s document management features. Each RichFaces component is backed by a Seam action class (POJO), where each Seam listener has access to a RAAr abstraction layer providing it with an easy to use domain specific API into Alfresco ECM. By making use of Seam observers each user action triggers one or more events at the back-end allowing one UI component to manipulate the state of the other components on the screen as needed.

The following is a screenshot of what SCAr looks like to a typical end user:

This development framework makes enabling new features and customizing the behavior of existing ones straightforward.

This is Part I of a series that I will be doing on factoring your software architecture for development agility, software performance, and total cost of ownership (TCO).

When object oriented programming first arrived on the scene (25 years ago!), it delivered important concepts: encapsulation, polymorphism, and inheritance. These concepts were designed to help the developer factor code. Proper factoring reduces complexity, redundancy and cohesion. One of the most powerful factoring techniques in programming is grouping for reuse. Functions, Objects, and Aspects are all code groupings that organize an area of concern for reuse.

Code reuse and other factoring techniques tend toward greater simplicity and development agility. These characteristics have an important and positive impact on cost and revenue. There is no doubt that software development can be an expensive undertaking and at the end of the day it’s always about the economics.

As we have observed, programming languages have been evolving to help manage complexity and make software development more efficient and effective. As computing power continues to improve, platforms are also evolving to improve development agility. For example JAVA introduced the JVM and the concept of “write once run anywhere.” It’s clear that the JAVA platform (as opposed to the JAVA language) provides clear agility over languages compiled to specific machine architectures because it removes the dependence on specific machine architectures by introducing an abstraction; the JVM. It has greatly simplified building, packaging and the distribution of software.

Today scripting languages are mainstream. Scripting languages are generally loosely typed and are interpreted rather than compiled. There are debates between what might be termed the “systems level programming languages” and “scripting languages.” Some in the traditional camp cite that scripting languages lack rigor, and claim that it won’t perform when compared to their compiled counterparts. Those in the scripting community point to “extra work for little value” and complex deployment environments as the other side of the coin. The communities around PHP, Ruby, Python, PERL, Groovy and others boast impressive development agility characteristics over JAVA, C++, etc.

It’s unlikely that there is anything inherent in the languages available today that drastically change the agility characteristics of development in those languages. Most of the mainstream languages have similar concepts and differ in terms of syntax. While some expressions may be quicker in one language over another, it’s unlikely that any of the mainstream language’s syntax will produce agility characteristics that are orders of magnitude above and beyond the others. That is to say, it is not the “PHP” in “PHP” or the “Ruby” in “Ruby on Rails” that makes them faster to develop in. It’s platform and architecture that accounts for the difference. PHP, Ruby and many other examples are interpreted rather than compiled and this means that when a change must be made to a program there is no need for a recompile and no need for a restart. Just change the code and (in the case of the web) hit refresh. In the same way JAVA cleaved an entire effort out of the development process (building for individual architectures), scripting languages have cleaved a massive time sync off the hands of developers by making it easy to modify code “on-the-fly.” I believe that scripting and compiled languages are not at odds but rather they are complimentary.

The strong typing, static analysis and offline assembly of byte code makes perfect sense for framework or systems oriented code. This code is not likely to change much in the course of an implementation but is executed frequently. Framework code often defines the performance profiles of a system. You always want to optimize when possible. Where there is no absolute requirement for interpretation and no strong value proposition it should be avoided. That is to say favor compilation over interpretation where interpretation does not deliver significant value. Don’t make the machine do the same work twice when it can be avoided.

Application level code (as opposed to framework code) changes often. Developers benefit from the ability to easily write and run code without having to restart servers and perform compilations and deployments. Application code has a lifecycle and release cycle that is much different from infrastructural / framework code. This becomes more and more apparent as the framework matures and changes less and less often. They are two different types of code with two different lifecycles. Businesses don’t want to spend more time on framework than is necessary. The value is in the applications and this is where agility matters most.

The optimal approach doesn’t have to be one or the other (although in some cases it is.) Each platform plays best to a different set of concerns. In software, a common approach for tackling separation of concerns is called layering. It is possible to layer a system by using a traditional, compiler based language and platform (such as JAVA) for infrastructure needs while leveraging scripting languages and template technologies (such as PHP, Ruby, Groovy and so on) for the application layer. By doing so, you combine the success characteristics of both platforms: compensating for weaknesses while playing to strengths. To understand the power and success of this approach, one needs to look no further than Excel; a truly killer application. Excel is a framework. You bring the application to it when you build your spreadsheet. Excel’s (a compiled, c++ based application) power is opened full bore with the VBA scripting environment.

We also see this approach taking hold in the web space with packages like Bean shell, groovy, JRuby, Quercus PHP and so on. At a recent community conference Alfresco, an open source enterprise content management platform demonstrated SURF, a java based framework that enables developers to code applications in server side Javascript. Alfresco used the SURF platform to create its new Share application (a Share Point alternative.) They are moving away from developing in pure JAVA because it just doesn’t provide the agility they need to compete at “internet speed”. Instead, they will continue to build their core repository and framework in JAVA but applications will be built based on SURFs support for Javascript and templates. It’s powerful and fast as a development platform. The productivity Alfresco has demonstrated in the last year is truly impressive and a testament to layering the two types of development platforms. Use the right tool for the job and it will get it done better and faster every time.

I’d like to point out one more important outcome of layering your development platform. In doing so you can greatly reduce the learning curve that one must overcome before one can develop for the system. A relative few people know how to program in JAVA. However a great many more people have at least some experience programming in Javascript and even more have experience with PHP. Why? That’s simple. Javascript is common on web pages. PHP is offered by almost every ISP on the planet and it has a huge online community from which one can find code examples. When you layer your system you get all the technical benefits of JAVA on the back end with all the benefits of easy to develop code on the front end (the application) in a way that is open to a very wide range of developers; for example: The core framework written in JAVA and the application consuming that frame-work written in PHP (Quercus PHP is an Open Source, JAVA based implementation of PHP5).

PHP developers tend to be much more available and affordable than JAVA programmers. It’s simple economics.

Today I am back in Boston after spending most of the week in Washington DC. I was there for the Alfresco Community Conference and also to spend some time at Rivet Logic’s new headquarters. We have a lot more room for our team in our new digs. Every time I have a chance to spend time with the group in Reston I am reminded of what an awesome team Rivet Logic has put together and why joining this team was such an easy decision.

The DC Conference was absolutely awesome. I left DC with the same excitement I had for Alfresco the first day I read about it on the web back in early 2005. This coming release is a Landmark release for Alfresco and a springboard for really big things in the future.

Last year Alfresco gave us Web Scripts. Web Scripts was raw functionality / capability for binding web-based functionality hosted in the repository to a parameterized, ReSTful URL. Web Scripts allowed Alfresco to easily integrate with other platforms, participate in mash-ups and to some extent get around the issues with the traditional alfresco web client (it’s much slower to develop for and a bit “click” intensive.) Web Scripts by it’s very nature is AJAX friendly which leads to better, more rich user experience and the javascript / freemarker construction makes building Web Scripts a whole lot easier than writing, compiling and deploying heavy Java code.

This year Alfresco gave us:

A better core repository

SURF

Alfresco Share

A peek at SURF Development Studio

CMIS

It’s clear that without the foundational work of Web Scripts and the capabilities in the WCM product the items above would not have come to pass in a single year. Web Scripts has enabled an explosion of capability. Last years release of Web Scripts may have seemed like a powerful but merely additional capability but it laid the foundation for a huge growth explosion. The game board was set up with last year’s release and it is evident with 3.x that the game has changed.

As Alfresco’s application architecture is refactored they are also able to refactor their team a bit and more cleanly dedicate resources to specific areas of the architecture. We now have a dedicated team of strong developers with a focus on repository scalability and stability. This week we were told we can expect better performance, scalability in both the DM and WCM repositories. We also heard that harmonizing the APIs and capabilities for these repositories is a goal and is underway. Alfresco has also added a new remote interface to the repository that allows Microsoft Office to use the Alfresco repository as if it were a Share Point server. Something good just got better. I like the direction the engineering is heading by cleanly separating the repository from the applications that work on top of it. I also like what I have heard about the focus on key areas like performance and scalability. New features are always important but are a distant second to improved performance and scalability of something as core and foundational as the repository and its content services.

SURF is an application platform for aggregating and delivering Web Scripts (and other components.) SURF is an MVC for site / application composition. Alfresco has taken Webscripts, templating, and URL addressability and parameterization capabilities out of the core repository, combined them with a set of new capabilities and re-organized them in a entirely separate framework. In essence SURF is entirely independent of the Alfresco Repository. The key here is that while SURF is entirely separate, creating Alfresco client capabilities in SURF is a snap.

Alfresco Share is a new application that Alfresco has developed, which, for many people will eliminate the need to use the traditional Alfresco web client for anything other than repository administration. Share is a collaboration platform similar to something one might expect from Share Point but with much more Enterprise 2.0 and social features. Share is really impressive and it demonstrates what can be built with SURF and how quickly and easily one can build it. Share was developed in less than a year but has features and capabilities of other systems that have been under development for years. Best of all, Share will continue to get better at a similar rate and because it is so easy to write new components with Web Scripts the community can contribute and accelerate this growth.

Development Studio is a SURF based application that integrates with Alfresco WCM, the Alfresco Network and your SURF application to provide you with a visual (WYSIWYG / drag and drop / edit in line) environment for developing SURF applications. I truly believe that Alfresco WCM is an awesome platform with advanced features and capabilities not found anywhere else in Open Source and in some cases even in the world of the proprietary giants. WCM is a new platform with groundbreaking capabilities but without a something like SURF or the Development Studio to demonstrate these capabilities, it was hard for customers to recognize the value sitting right in-front of them. Early on in WCM, Rivet Logic had developed similar capability to what you see in SURF for the exact same reason. SURF and the Development Studio help to round out the Alfresco offering and will really help to highlight the unique and powerful value in Alfresco WCM.

CMIS (Content Management Interoperability Standard) is a new standard for ECM platform interoperability. Today it is in DRAFT status with OASIS but according to John Newton, CTO of Alfresco there is a strong probability of its adoption with the backing of the like of Microsoft, Documentum, Open Text, Alfresco and several other key players. CMIS supports both Web Service and REST based protocal bindings making it very easy to integrate in to an existing platforms. Alfresco’s REST implementation provides nearly full coverage of the specification. Web Scripts played an important role in the lightning-fast turn-around time for this implementation. Again we see the foundational work of Web Scripts delivered last year providing big results less than a year later. CMIS will allow developers to write repository agnostic applications that will work against any repository which supports CMIS including Alfresco. CMIS also specifies a SQL like query language. Unlike previously proposed standards that pushed XQUERY and XPATH, CMIS is adopting a well understood paradigm which I believe will only encourage its adoption.

It was a fantastic week and an exciting conference. If you have not looked at Alfresco lately it is definitely time to take another look. This is truly an exciting release for this product! I really enjoyed the opportunity to see everyone in the community, Alfresco, and at Rivet Logic HQ.