cancel
Showing results for 
Search instead for 
Did you mean: 

Newbie question... WCM delivery stack best practices

goldpelican
Champ in-the-making
Champ in-the-making
Is there a current "best practices" for developing a web application to deliver content from Alfresco WCM?

I've been doing a bit of reading, but haven't had much of a chance to play with the technology yet… but my understanding is that Web Scripts should be used to expose web services against the Alfresco repository, and these are utilised by the web application of your choice, be it Java, PHP etc? If this is the case, I appreciate the loose coupling that this provides and the flexibility in the choice of presentation technology, but is it a highly scalable and an efficient means of accessing the repository?

Can Web Scripts be used to populate content into the repository? i.e. allow users to create content without using Alfresco WCM directly, but a from custom web application.

I'm considering an architecture using JBoss Portal as a front end for a website, and would like to evaluate Alfresco WCM as the web content repository - has anyone done this?

thanks in advance for your replies.
5 REPLIES 5

jbarmash
Champ in-the-making
Champ in-the-making
Sounds like you are getting it. 

There are two main ways to deploy sites - to Alfresco runtime (ASR), in which case you'll have your site interact with web scripts, and deploy to file system, in which case alfresco deploys xml, and other files, and it's up to your site to know how to interpret that.

web scripts - is it a highly scalable and an efficient means of accessing the repository?

Yes.  Each ASR contains its own copy of all content and DB.  They are not dependent on each other at all, which means you can deploy your site on 20 servers, giving very good ability to scale.

Can Web Scripts be used to populate content into the repository? i.e. allow users to create content without using Alfresco WCM directly, but a from custom web application.

Yes, Think of Web Scripts as stored procedures on top of Alfresco that may in some cases generate UI, so they can support all CRUD operations.

I'm considering an architecture using JBoss Portal as a front end for a website, and would like to evaluate Alfresco WCM as the web content repository - has anyone done this?

I know people got the two to work and to talk.  Web Scripts are automatically JSR 168 compliant portlets.

goldpelican
Champ in-the-making
Champ in-the-making
Thanks! Very useful information.

goldpelican
Champ in-the-making
Champ in-the-making
Web Scripts are automatically JSR 168 compliant portlets.
Could you elaborate on this further? I'm familiar with portlet development for WebSphere Portal.

As I interpret it, there's two potential uses of web scripts in relation to JSR-168 portlets:

Case 1. Running a web script in a JSR-168 runtime as a portlet
Case 2. Running a web script in a servlet runtime and accessing it via HTTP from a portlet

Are these interpretations correct? I'm not clear on whether case 1 includes the use of a "proxy" portlet or not that maps to the web script - I picked that term up somewhere while reading up on this.

In the first case, does that mean Alfresco and the portal of choice (e.g JBP, Liferay) need to be deployed on the same app server, or can they still reside on separate app servers if there's a "proxy" portlet in the picture? I'm looking at deploying an architecture where the portal is merely the content delivery channel, backed by one or more Alfresco Runtime Servers on separate infrastructure.

I would not be interested in an architecture where Alfresco has to be "embedded" within a portal to use a web script as a portlet. Does this limit my design to the second usage case, or have I misinterpreted how web scripts work as a portlet?

jbarmash
Champ in-the-making
Champ in-the-making
Case 1. Running a web script in a JSR-168 runtime as a portlet
Case 2. Running a web script in a servlet runtime and accessing it via HTTP from a portlet

Are these interpretations correct? I'm not clear on whether case 1 includes the use of a "proxy" portlet or not that maps to the web script - I picked that term up somewhere while reading up on this.

You are right in both cases.   Web Scripts are automatically portlets - they have a special channel which defines proper authentication, you can find it in web.xml, just like you can view a portlet at /alfresco/service/, you can call it as a portlet at /168service/.  There are instructions on the wiki:

http://wiki.alfresco.com/wiki/Deploying_2.1WAR_Liferay4.3

You do need to be on the same server as the portal container. .

I would not be interested in an architecture where Alfresco has to be "embedded" within a portal to use a web script as a portlet. Does this limit my design to the second usage case, or have I misinterpreted how web scripts work as a portlet?
For Case 2 you described, which is also perfectly valid, you can be on two different systems, since you are just making http calls.     So yes, overall if you want to NOT embed alfresco, this is the way to do it.  this is on 2.X code branches.  

I was just told that with 3.0 / SURF, you can house portlets within the portal container which connect to a remote alfresco repository.  so you'll need surf runtime together with portlet container, but then you can have alfresco elsewhere on a different server.   Surf layer is pretty light weight and is just responsible for the UI.

eli_lindner
Champ in-the-making
Champ in-the-making
Hi,

Sorry to cut into this thread, but on the topic of the following…

I was just told that with 3.0 / SURF, you can house portlets within the portal container which connect to a remote alfresco repository.  so you'll need surf runtime together with portlet container, but then you can have alfresco elsewhere on a different server.   Surf layer is pretty light weight and is just responsible for the UI.

In this use case scenario, would it still be possible/good practice in using WCM to manage the SURF platform layer?
Getting started

Tags


Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.