What is AWPr?
AWPr (Alfresco Web Script Portlet rivet) is a JSR-286 portlet that can be used to expose remote Alfresco Web scripts, including those that need user authentication. With the help of a custom Alfresco authentication component that we wrote, the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.
This portlet alleviates the need for having to deploy all of Alfresco inside the portal as is the case when using Alfresco's OOTB (out-of-the-box) Web script portlet.
AWPr is also highly configurable. Through the use of portlet preferences you can create multiple instances of AWPr and configure each one with a different Web script URL and a set of parameters with default values if needed. The instance will then RESTfully fetch the result of the Web script's render phase and carry that over to the portlet finally rendering it on the screen within the confines of the portlet window.
It is hence possible to run two instances of AWPr on a single portal page where each instance is exposing a different Web script even if those Web scripts are hosted on two different Alfresco servers regardless of their geographic location.
An example of the result could look something like this:
Liferay Portal
JBoss Portal
AWPr is licensed under the GNU Affero General Public License.
Motivation
At Rivet Logic we've been tasked on multiple occasions to expose Alfresco features through a JSR-168/286 portlet. Alfresco provides us with a number of ways to do this:
- Write a portlet and use Alfresco's web services API to expose the ECMS features
- Use Alfresco's out-of-the-box Web script portlet to expose an Alfresco Web script
The first approach was OK but in many cases required that we develop custom Alfresco actions since the web service API did not cover the full feature set of AFS (Alfresco Foundation Services).
[As a side note, the fact that the Alfresco web services API is heavy and lacks the needed AFS coverage was the motivation behind the RAAr project which makes writing portlets backed by a Java-based Alfresco API a lot more practical.]
The second approach provided us with more AFS coverage but had (and still has) one restriction that was not easy to work with. Alfresco's Web script portlet requires that all of Alfresco be deployed inside the portal as a portlet application. So if you needed to deploy a Portal running a Web script portlet that exposes the MySpaces Web script, the deployment would look like so:
The problem with this approach is that it introduces scalability constraints. Namely, if you need to scale the portal you are forced to scale Alfresco with it and vice versa.
The fact that there was no single solution that solved all of our problems was the motivation behind creating AWPr. With this portlet we would be able to have a better deployment architecture that could be represented by the following diagram:
Now the portal and the ECMS are in two different tiers as they should be. This not just helps by allowing for better scalability but it also gives IT personnel more flexibility and ease of maintenance since they can treat each tier differently if required.