OpenCms Application Overview
Before undertaking development, it will be helpful to understand the basic design of OpenCms. OpenCms is structured as a typical J2EE web application conforming to a 3-tier web application architecture:
A web server on the front-end tier services incoming requests. The requests are passed through to an application server in the middle tier, where the OpenCms application runs. The OpenCms application utilizes the database on the third tier to read and store its content.
For production, using an array of web servers will typically distribute load to the application server tier. A common choice is to use the Apache web server, utilizing the mod_jk plug-in to distribute load. For development purposes, using a web server is optional, and instead the application server container may be accessed directly. Open Cms supports a wide variety of application servers, including commercial servers such as IBM Websphere and BEA WebLogic. It also supports open source servers such as Tomcat and JBoss. A popular choice among developers is the Apache Tomcat server. We will be using the Apache server for our development environment.
On th e back end, OpenCms supports a variety of databases, including Oracle, Postgreas, and the popular open source database, MySQL. The OpenCms installation setup procedure provides a wizard interface guiding the user through the creation of the database schema. Optionally, it allows for manual creation of the database schema through provided scripts.
This wide variety of choices makes it easy to install and run OpenCms in many mixed environments. It also allows for easy integration with other technologies, such as portals, CRM systems, and document management systems. Next, let's take a look at the file structure of an installed environment.
OpenCms Architecture
OpenCms has a modular architecture centered on a VFS. The file system is considered virtual as it resides inside a database and not on a hard disk. The VFS is similar to a real file system that supports folders, file types, and permissions. Access permission masks on the fi les and folders, and controls access that users and groups have to the files. The OpenCms VFS also provides a feature very similar to symbolic links in a Unix file system. A link is a directory entry that contains meta-information which is kept separate from the file contents.
The core also provides support for basic features such as publishing, access control, and revisions. Layered above this are application level features such as confi guration, the user interface, and module support. Module support is a key feature of OpenCms, providing the ability to extend and modify it. Module support is layered on top of OpenCms. A logical view looks like this:
It is interesting to note that although OpenCms is a web application, it comes with a shell application that provides an interpretive interface to the API from a Java command line interface! Furthermore, it is possible to script this interface to install content into the VFS.
Extensibility through Modules
M odules are a key aspect of the OpenCms design. They provide a way to package together necessary components that may be easily plugged into OpenCms. Modules are the way that new content types, templates, or web capabilities are added to OpenCms. Later in this book, we will go into the details of creating an administration module for OpenCms.
The OpenCms Web Request Process
It would be useful to understand how a request made to OpenCms results in the display of content. The structure of a typical OpenCms URL looks like:
http://[server]:[port]/[context]/[servlet]/[parameters]
For example:
http://mydevserver:8080/opencms/opencms/system/logon/index.html
Server: mydevserver
Port: 8080
Context: opencms
Servlet: opencms
Parameters: /system/logon/index.html
The request will invoke the opencms servlet with the parameter /system/logon/ index.html. When the servlet runs, it goes through the following sequence:
1. Uses the passed in parameter to locate the item in the virtual fi le system
2. Determines its access permissions, and see if it can be accessed by the requestor
3. Determines its file type
4. Based on its fi le type, locates a resource loader for that type
5. Invokes the resource loader to load the file
There is a bit more going on; but for our discussion we will consider only the previous steps. It can be seen that after permission has been established, a resource loader is utilized to load the file. Resource loaders are responsible for encapsulating the knowledge required to load and execute items requested from the VFS. There are several types of resource loaders provided by OpenCms, and there is a one-to-one mapping between an OpenCms fi le type and a resource loader.
Most site content is structured XML, and the assigned loader for this type is the CmsXmlContentLoader. W hen this resource loader is invoked, it examines the properties assigned to the resource, specifi cally looking for the template-elements property. This property must contain the full path to a template used to render the XML content. The resource loader passes control to the template. When the template runs, it takes the responsibility of parsing the original XML resource, and displaying it. Most templates will be JSP fi les, but they are not restricted to this type. In fact, when a template is invoked, it follows the same loading process, resulting in its corresponding resource loader being invoked. This allows for new template languages to be plugged into OpenCms, by writing and adding new resource loaders.
As resource loaders act on file types, the extension of a fi le in the VFS is not signifi cant. This means that a fi le with an HTML extension in the VFS may, in fact, be run as a JSP fi le, or vice versa. A useful way to leverage this, is to create a fi le with a .CSS extension that is in fact a JSP file. The JSP could then dynamically generate the CSS based on browser type.
ref from:
http://careerride.com/OpenCms-Application-Overview.aspx
http://careerride.com/OpenCms-Architecture.aspx