Rivet Logic Blogs

Tag: cmis

Digital assets are a key component of almost all web experience and customer engagement projects. In today’s era of engagement with all of the additional content targeting, personalization, internationalization and multi-channel publishing the number and permutation of digital assets associated with any given project are growing rapidly. This trend will only continue as we move forward. Content workers (authors, designers, content mangers) need to be able to create, locate, modify and manage the growing number of assets easily and efficiently in order to maintain brand quality and deliver projects on time and on budget.

In today’s blog entry we’re going to focus on the creative side of WCM (Web Content Management) and DAM (Digital Asset Management) even though this is only a small portion of the overall set of use cases.

Let’s begin by considering the following example use cases:

Create mobile appropriate image resolution variants

Create video stills

Imprint watermarks

Thumbnails for galleries and promotional kickers

Each of these use cases are important ingredients in providing the user with a great experience but they also introduce a lot of additional work for our content teams. One of the ways to deal with the large volume of asset creation and manipulation responsibilities is to automate them. The use cases mentioned above and many others like them are a perfect candidate for automation.

Crafter Rivet leverages Alfresco’s enterprise content management services for image transformation. With a few simple rules applied at the repository level it’s possible to provide your content team with image resolution variants, video stills, apply watermarks, to scale and crop thumbnails and then to make these assets available for review by our authors all in an automated fashion with no additional labor required beyond uploading the canonical assets.

Another important way to help our content teams cope with the sheer volume of digital asset related workload is to make sure our teams are able to work with the very best tools at their disposal. With today’s modern browsers it is possible to provide a fairly decent set of tools / asset manipulation functionality right with-in the browser. However, while purely web-based tools have their advantages they are often slower and much less powerful than the desktop tools serious content contributors are used to working with.

The biggest productivity boosts are gained when we empower our designers and other content workers on our team with rich, native tools that they are already familiar with and work with on a daily basis.

Adobe’s creative suite (which contains tools like PhotoShop) is the quintessential software package for image/digital asset creation and manipulation. Designers are deeply familiar with these tools and are able to leverage their enormous arsenal of capability to accomplish a tremendous amount of work in a short amount of time. The issue that many organizations often face, is that while the tools themselves are great, the interfaces between the tools and the systems that ultimately store, manage and deliver the assets are either non-existent, human-process based, or have clunky integration. This gap creates a drag on the margin of productivity and introduces room for error.

Fortunately Alfresco, Adobe and Crafter Rivet Web Experience Management have a solution that connects rich, creative desktop tools, to your systems of record (e.g. repository) and ultimately to your systems of engagement (e.g. website) in a seamless fashion. Content creators work right with-in the rich, local tools that they are familiar and productive with and those tools are deeply integrated with the repository which means that all of the organization, policies, metadata extraction, and versioning provided by the repository etc are seamlessly integrated and enforced. Alfresco is a CMIS (Content Management Interoperability Standard) compliant repository. This standards based interface enables it to communicate with external applications like Adobe’s products in order to interact with and operate on the content, metadata, permissions, versions and so on housed within the repository. Adobe provides a platform called Adobe Drive which enables its tools to connect in a rich fashion over CMIS to Alfresco. Once we’ve connected our Adobe tools and our Alfresco repository authors working within Crafter Studio, the authoring and management component of Crafter Rivet can now see content updates coming from the Adobe tools right in context with the work they are doing through in context preview and editing. They can also interact with that content through the web based tools, workflow, versioning, metadata capture and publishing capabilities of Crafter Studio.

By closing the integration gap we can now provide powerful tools for productivity and at the same time do so in a way that makes it seamless and easy for our creative teams to collaborate across the entire process.

Click on the video below to see Adobe and Crafter Rivet WEM / Alfresco in action together!

Crafter Rivet is a 100% open source, java based web CMS for web experience management and customer engagement. Learn more about Crafter Rivet at crafterrivet.org

Over the years, Liferay Portal has transformed into a complete Web platform for social collaboration, Web content management, and development tools to create customized solutions.

The new Liferay Portal 6.1 EE features extensive updates to existing Web content management and document management systems plus new capabilities that are designed to provide more power to end users. Extensive user interface updates will make document management more productive and intuitive, with desktop and mobile access, live previews, and integration to external enterprise document repositories. Liferay 6.1 EE also simplifies the development and maintenance of rich websites, with sophisticated page templates and multiple site and page version editing. The new release also integrates with Liferay Marketplace, which will allow administrators to find and install applications to extend functionality directly from the portal.

“The new Liferay 6.1 EE release matures the 6.x branch with much anticipated implementations that in so many ways completes Liferay as an enterprise-grade product,” says Alaaeldin El-Nattar, Engagement Director and Certified Liferay Trainer at Rivet Logic. “Liferay 6.0 EE introduced several services that opened the door for the development of Auditing, Reporting, Workflow, and other enterprise features, while Liferay 6.1 EE takes Liferay as a leading and powerful portal framework and packages it into a fully functional enterprise ready portal solution. We have been waiting a long time for this release and are very excited about all the client needs that we will now be able to fulfill with relative ease. I am especially looking forward to making full use of Liferay 6.1’s new CMIS support, Document Sync, Website Management, and Mobile support. Cudos to the Liferay team on a job well done.”

Today organizations of all sizes are adopting wiki solutions as a way to facilitate communication and collaboration around planning, projects and departmental matters. Wiki solutions allow users to attach documents to pages and to hyperlink to those documents from other pages. This is extremely useful, however documents, which have traditionally been stored and secured on corporate shared drives are now living in separate places. Some now live within the wiki, while others continue to live on file servers. This is an example of an age-old issue in technology; as we bring in new tools that provide us with more options and better ways to work we are faced managing the side effects of a growing technology footprint.

This issue is not new technology, but instead, one of architecture. As our needs grow we need to adjust our architecture to accommodate new demands. In this case, what we need to do to solve the problem is to separate a few concerns. Some users want to access the document through a file server (shared drive) while others want to access it via the wiki. Traditional shared drive technology doesn’t do a great deal to help us accommodate this. Traditional shared drives provide file system access to documents but lack APIs that allow us to get to our content by more sophisticated means. Further, most wiki technology is one sided as well; while a wiki solution may provide web based access via pages and services they tend to lack file system access. Finally, even if the wiki could “project” its store as a shared drive it’s not likely to be the proper system of record for your documents. By separating the issues of storage, management and delivery we can articulate a solution that allows us to serve documents through a traditional shared drive interface via a proper system of record while at the same time, providing APIs that allow us to get to that content as a service so we can incorporate better ways of working with the document through new technologies as they emerge.

Enter Alfresco. Alfresco is architected from the ground up to be a system of record. It’s designed to provide API / service based access to your documents and content, as well as traditional shared drive access. Alfresco supports three different remote programming APIs including SOAP, webscripts and CMIS. And in addition to presenting itself as a file server so users can connect to it as a file share, Alfresco also mimics an FTP server, a WEBDAV server and even a Microsoft Share Point server. Alfresco is designed to store, secure and manage your documents and to provide access to those documents in the way that best suits your users.

If we use Alfresco to store our documents and integrate our wiki solution to read and write documents though Alfresco’s APIs rather to the wiki itself we satisfy our objectives:

Store documents in a proper system of record

Allow file-share access to the documents

Allow API level access to client applications like wiki

Alfresco’s capabilities go far beyond security and content retrieval. Once your documents are in Alfresco they can be searched, workflowed, transformed, translated, versioned and so on and so on, no matter how they are accessed; all through stock capabilities provided by Alfresco out of the box.

At Rivet Logic we see real value in allowing knowledge workers to interact with their content though tools and in whatever process that fits their needs best. At the same time, it’s important to manage content or the same efficiencies that are gained through productive tools and well-designed process are lost due to stove-piped information. The need is real, and given that, we set out to create an open source project that demonstrates a more appropriate architecture and provides a stepping-stone for much greater integration going forward. Najy Nicolas, a “Riveter” from our Boston office has integrated one of the most popular wikis, Confluence, with the management capabilities of Alfresco, the leading open source document repository. We’re calling this project the Confluence Alfresco Integration rivet or CAIr for short. CAIr is open source. You can find downloads, source code and documentation here: http://wiki.rivetlogic.com/display/CAIR/Home

The topic of Liferay and Alfresco integration continues to be popular among portal developers and what we’ve seen is that in the last year both products have matured in important ways to enable better integration. This evolution also opens the door for more possibilities. And as we all know, with more options there is more confusion. From my readings on the Liferay and Alfresco forums I observe that there are two main issues that puzzle people when they’re thinking about integrating Liferay and Alfresco:
What are the different possible ways for me to integrate the two products?
Which approach should I use?

To help answer these questions I thought it might be useful to list what the current options for integration are as well as a brief description of the architectural implications of each.

Note that the type of integration I’m referring to here is between Liferay Portal and Alfresco’s Document Management (DM) repository, and not the Web Content Management (WCM) repository.

Option #1: Using the Web script Container
With this approach you would basically deploy Alfresco’s Web script container into Liferay as a portlet application. Your Web scripts would be deployed along with the container and will be fully executed within the Liferay Portal context. What’s new here is that authentication between the Web scripts running in the container and the Alfresco repository will be taken care of automatically. This is nice since it alleviates the need to deploy the entire Alfresco WAR file into the portal as was the case with Alfresco versions prior to 3.2.

That said you should keep in mind that (for now) to accomplish this you would need to deploy the Alfresco Share WAR file in its entirety into the Liferay portal. It should be mentioned though that according to Will Abson’s blog post about the subject this is expected to change with the reduction of the needed WAR file’s footprint. Also, the portlet still needs some work to make it configurable from the Liferay Portal UI using portlet preferences — but I gather that this will be implemented eventually as well.

Option #2: Alfresco Web script Portlet rivet
Another option is Rivet Logic’s Alfresco Web script Portlet rivet (AWPr). This portlet is pretty much an Alfresco Web script proxy. With the help of a custom Alfresco authentication component known as STAr (Secure Token Authentication rivet), an AWPr portlet instance will use a series of Java HTTP Client calls to RESTfully and securely retrieve the rendered contents of a single Web script, proxy the contents so that all URLs are valid portal URLs (e.g. action URLs, serve resource URLs for downloads, etc.), and render the updated content in the portlet’s render phase.

AWPr has a very small footprint and thus can safely be used heavily on one Liferay portal page; meaning that a single portal page can have multiple instances of AWPr each configured to proxy a different Web script without much performance impact on the Liferay instance. Keep in mind that it is a proxy so the content is being transferred from Alfresco to Liferay and then from Liferay to the client browser, which might have some cost implications if bandwidth is not cheap and the Web script generated markup is large.

Options #3: Custom Portlet Development
For those of us who need to build their own custom portlets and need to have access to the Alfresco DM repository APIs from within their portlet code in order to perform certain ECMS functionality, there are a number of options.

CMIS
Recently, Alfresco, IBM, Microsoft, Documentum and others announced the submission of a new content management standard proposal called “CMIS” or “Content Management Interoperability Service” and on May 1st, 2010, the OASIS standards body approved CMIS v1.0 as an official OASIS Specification.

Alfresco has released a full implementation of CMIS v1.0, which includes support for both RESTful AtomPub and Web Services bindings. This basically allows Liferay portlet developers to use either one of those interfaces to communicate directly with the Alfresco repository (and any other content management system that supports the CMIS specification). More details on Alfresco’s CMIS support may be found at: http://wiki.alfresco.com/wiki/CMIS

RAAr
Another recently available option is presented by Rivet Logic’s Remote Alfresco API rivet (also referred to as RAAr). This API is a Java API that uses REST calls to communicate with a remote Alfresco repository. The advantage of this approach is that it provides all the pros of Alfresco’s Web services API but does not carry the burden of the SOAP stack — thus making it an attractive option for Java portlet developers.

RAAr is open source and is currently maintained by Rivet Logic Corporation. It provides most (if not all) of the Alfresco Foundation Service methods and can basically be used to do anything that the Alfresco web client can do.

More information about RAAr can be found at: http://wiki.rivetlogic.com/display/RAAr

Custom API
Even though it doesn’t really make much sense to do this I’m including this option just to be thorough. The idea here is that if you want to develop against Alfresoc’s REST API but want to abstract it using your own API you can do so. The problem with this approach is that depending on the problem you’re trying to solve you’ll eventually end up writing a CMIS API if you want to be platform independent (mostly) or RAAr if you want to access Alfresco’s service layer APIs remotely. So unless you have a legitimate reason to go down this road it’s most probably going to be better for you in the long run to stick with CMIS or RAAr.

This pretty much covers the options available for integrating Liferay with Alfresco’s DM repository. To know which options suites you best, you should weigh the features and drawbacks of each until you find a good fit, and with enough projects, making the right choice will start to become more obvious.

Yesterday about 100 people crowded the halls of the Kellogg Conference Center in Washington DC as another round of Alfresco community summits got underway.

Bill Robinson (Alfresco, VP Sales) reported that 1% of the total Alfresco community / ecosystem base has been attending these meetings. The customer to vendor mix seemed to be about 50 / 50. As a member of Rivet Logic I now help to tip the scales on the vendor side. As a customer of Alfresco in my past life in publishing I can tell you that these events are really important for customers. The opportunity to network with other customers is unparalleled. If you can’t make it out to Atlanta or LA for the upcoming events, mark your calendar for next year. You can’t afford to miss these.

John Newton, Alfresco co-founder and CTO gave the keynote address and laid out the strategic and technical vision for the upcoming versions of Alfresco. As usual he did not disappoint. Alfresco will continue to attempt to disrupt the current ECM market with evolving open source business model and technical strategy and innovation. Of particular note:

Alfresco will license the Webscript engine and Surf framework under an ASF (Apache Software Foundation) license. The repository and other core technology will remain under the GPL. Alfresco will retain ownership and continue to maintain these libraries.

Alfresco will continue with ongoing activities in partnership with SpringSource (now a division of VMware) to integrate the Webscript engine and Surf in to Spring MVC.

Some components of the platform, which are intended specifically for enterprise deployments, will only be available in the Enterprise edition of Alfresco.

CMIS, an emerging content management standard continues along its approval process within the OASIS standards body, albeit at a slower pace mostly due to red tape. CMIS is to content repositories as SQL is to the database. In the late 80’s and early 90’s the adoption of SQL standards helped the relational database market gain widespread traction. SQL enabled third party vendors and development platforms more easily and cost effectively develop value. John Newton, a veteran of the SQL revolution, strongly believes that CMIS will have a similar effect in the content management space. CMIS will be a core component of the Alfresco architecture and strategy.

Alfresco will be evolving its architecture to better support an ability to run in a cloud environment. Alfresco’s architecture has always contained key elements of cloud-ready software including its stateless service tier. Future enhancements will include functionality like repository sharding.

The DM and WCM repositories will be consolidated. The AVM technology under the WCM repository will be retired in favor of a DM / CMIS based store which supports a similar feature set including snapshots, sandboxes, and a simplified layering scheme. This activity will lead to a, much needed single object model and a single set of core services for library functions, permissions, auditing and so on.

Alfresco Runtime servers, currently based on AVM stores will be replaced with scalable CMIS runtimes.

Alfresco Share will continue to take on administrative functionality and should completely replace the Alfresco Explorer client by 4.x

I was able to get to the Records Management best practices break out session, which I found very informative. Strong RM capabilities and DOD 5015.2 certification have been a long time coming. Alfresco RM is implemented within Alfresco Share as a “Site type.” Users may be invited in to the RM space to become record managers and consumers. During the presentation we learned about current trends in RM and were treated to a demonstration of the RM application and the process of moving content through its lifecycle as a record from declaration to deposition.

Our CEO, Mike Vertal, outlined a large-scale records management solution that Rivet Logic has been working on with SAIC based on Alfresco, Liferay, and SAIC’s Teratext email archiving platform.

I gave a talk entitled Alfresco Best Practices, which I co-authored with Jeff Potts of Optaros and Peter Monks of Alfresco. The three of us are very excited to have had an opportunity to consolidate all of the practices, pointers and gotchas we’ve learned over the years. The presentation is aimed a variety of levels from Alfresco noobs to Alfresco experts and attempts to cover the lifecycle of a project from conception to deployment and operational aspects. It’s a lot of material to cover in 90 minutes. We invited listeners to tweet about their favorite best practices, practices they thought they could implement immediately and any areas we might have missed. The most active, productive tweeter in each section was awarded a much-coveted Alfresco Community Member t-shirt. We’ll be giving this talk in Atlanta, LA and at a number of the international meet ups – so bring your notepad and twitter account! For those who can’t make it to the events please watch and contribute online at: #alfrescobestpractices. All the material – including more detailed source material will be made available on line after the meet ups. We invite you to enhance and embellish the material. Also for those of you who run local community groups… this presentation is a great score. Download it and present it at your next meeting!

Last week I attended the Alfresco community meetup in New York City. The turn out was impressive. Nancy Garrity (Alfresco Community Manager) told me that the event was completely “sold-out” and that there was not enough room for everyone that wanted to come. I was sorry to hear that we were not able have everyone there that wanted to be there but it’s really great that there is so much interest in Alfresco.

The session got underway with Ian Howells, Alfresco’s Chief Marketing Officer, who reviewed the trends in favor of open source ECM, not the least of which is the accelerating demand driven by the global recession.

• Repository harmonization. Alfresco provides two distinct content stores: the Web Content Management (WCM) repository, and the Document Management (DM) repository. Alfresco is bringing these two stores together at the API level and then consolidating many of the core capabilities.

• Clustering for the WCM repository (not just DM) is under development.

• New Forms Service: Alfresco WCM has long had a capability for defining forms. A user can install an XSD in the Data Dictionary. The XSD is then translated in to a Web form that provides a friendly user interface for reading, modifying, and storing XML. The DM repo does not have such a feature. Instead, within DM property sheets map to the underlying content model. Many users have requested both capabilities be available uniformly for both DM and WCM. Alfresco is responding to these requests with the new service. The new Forms Service will have a much more powerful persistence capability. I asked to find out if customers who already have XSD form definitions in play would need to change to a different format. I was told that these customers should be safe.

• Spring Webflow integration with Surf: Spring Webflow is the project in the Spring Portfolio that focuses on providing the infrastructure for building and running rich, Java-based web applications.

Uzi laid out a timeline for future Alfresco releases:

1. v3.2 Labs targeted for June

2. v3.2 Enterprise targeted for September 2009

3. v3.3 in early 2010

4. v4.0 later in 2010

In addition to Uzi’s presentation, a number of other presentations and demos were also given. I particularly liked the customer case study given by the Warren country Correction Center. They process a large volume of inmates in and out of the facility. Each time an inmate is processed in or out of the correction center a large volume of paper work is generated which must be stored for long periods of time. Warren country is now well on their way to eliminating the need to store large volumes of content in physical file cabinets. They have implemented an Alfresco based solution for archival and retrieval of inmate data. Electronic storage of the inmate information allows the correction center to quickly search and retrieve important information on inmate background, health, behavior and other important documents for both operational and legal functions.

Other demonstrations included
• Scanning best practices and an Alfresco-integrated Kofax demonstration.
• A walkthrough of Alfresco Share
• Digital tampering protection through an integration with Surety’s Absolute Proof.
• IMAP demonstration that allows your email bin and folders directly with Alfresco.
• A demonstration of a Flex UI for Alfresco.

I gave a presentation entitled “Leveraging Alfresco Share for Enterprise Content”. At Rivet Logic, we get a lot of requests for solutions to help authors manage deep, inter-related content types that need to ultimately be published to numerous channels, including the Web. In addition to the publishing requirements, enterprise class assets usually benefit from an authoring environment that includes social and collaborative capabilities like those found in Alfresco Share. To address this, we demonstrated a number of best practices and design patterns for managing enterprise content with an authoring environment plugged in to Alfresco Share combined with an instant Web preview capability. Based on the feedback, the approach seemed well received. Like many of our customers, members of the Alfresco community are quite interested in collaborative authoring environments for enterprise class content.

It was great to meet with everyone who was able to attend. These types of events are vital for the community. It’s a perfect time to give Alfresco feedback and for the customers and community to meet one another.

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.