Originally designed as an extensible content management platform running on any J2EE app server -- unlike much of the competition at the time -- WebCenter Sites (WCS) picked up some great features along the way -- including personalization and content targeting, flexible data design and multiple (four at last count) layers of caching, now based around Ehcache.
The product is comprised partly of a number of servlets deployed inside a web application. These do most of the heavy lifting. A few frequently used examples are:
- ContentServer -- Generates and serves web pages dynamically. This servlet provides disk caching, session management, event management, searching and personalization services.
- CatalogManager -- Provides most of the database management for the Content Server database, including revision tracking, security, result set caching and publishing services.
- BlobServer -- Locates and serves binary large objects (blobs).
- Satellite -- Assembles pages from cache and from requests to Content Server servlet if they don’t exist in the cache.
Starting with a database cache that holds all the most frequent queries in memory, up the stack to a pagelet (page chunk) cache at the Content Server level, and another one at the Satellite Server level, and with a new asset object cache in the more recent versions, WCS has an incredibly sophisticated and powerful caching model. It’s one of the architectural features that sets WCS apart from its competitors.
On the other hand, caching needs to be considered and factored into any design from day one. If your cache configuration is incorrect, you can find yourself with massive duplication, excessive heap usage, and incorrect content served, and it’s not always easy to see where you’re going wrong, so it bears paying close attention.
One of WebCenter Site's greatest strengths (and dangers) is and always has been its extensibility and flexibility. You can do just about anything with the platform. I've integrated it with video encoding, mobile delivery and messaging platforms like Tibco Rendezvous, written custom ingestion software to import twenty thousand pieces of content a day and used it purely as a content repository to be interrogated by custom applications.
However, because it's so open ended from a design point of view, it's also possible to make some particularly bad decisions if you don't have the right information and know-how.
WCS is commonly deployed with a configuration which includes Satellite Servers. These are essentially a distributed caching mechanism which store and assemble "pagelets," or elements of output. These Satellite Servers also sit on an application server, but have no database -- they are memory and disk based only. They add a cheaper scaling alternative for handling large quantities of traffic.
To put that into perspective, I've recently worked on a project running on a 60 plus server cluster serving up to 250 million page views a month.
Let’s dig into some of the key product features.
Everything (well, almost everything) in WCS is called an “asset.” This means that all your content, as well as your code, is an object that has a set of standard operations that can be performed on it -- creation, editing, deleting, revision tracking, workflow and so on.
Multilingual and Localization Support
Through the use of asset types called Dimensions and DimensionSets, WCS allows for the creation and management of content in multiple languages including the ability to link the translations together and assign a master language.
Most usefully of all it allows you to create a language fall-back strategy so that, for example, if a piece of content is not available in Swiss French, it would look for a Standard French version and, failing that, an English version.
There are also language packs allowing the Editorial interface to be rendered in a number of languages.
There is a module in the core product (although licensed separately) called Engage. This implements a number of additional asset types, such as Visitor Attributes, Segments and Recommendations.
Users can define characteristics of their visitors, arrange them into segments and then recommend specific content to them, making use of either explicit or implicit knowledge about the visitor.
There are also APIs to integrate that with external data sources like Business Information Warehouses, make this a fairly powerful tool to analyze customer data and target content accordingly.
Core product development seemed to stagnate slightly during the Fatwire years, but since the Oracle acquisition, a raft of new features has recently surfaced, including:
WEM Framework / REST
In version 7.6, a Web Experience Management (WEM) Framework was introduced.
This provides a technology for developing custom applications and integrating them with the WCS product, including features like Single Sign-On, allowing applications to communicate with the WCS via a REST API. Objects in the WebCenter Sites database, such as sites, users and data model map to REST resources in the WEM Framework.
For editorial users, mobile website support provides a series of device specific previews. This gives users an indication of what the site will look like rendered in a range of devices.
There’s support for providing device specific templates and site plans to allow editorial users to create device specific versions of a site. Features include:
- Device detection using a simple xml format, or even better, WURFL
- The ability to create separate Site Plans for devices/device groups
- The ability to create device specific templates for rendering assets
- Preview content as your users will see it using the multi device preview in the Contributor User Interface
Vanity URL management
It may seem slightly odd that it's taken 15 years to get around to implementing Vanity URLs as a feature, but that oversight has been corrected in the most recent 220.127.116.11 version.
Developers enable URL generation by specifying patterns and functions to automatically generate friendly and stable urls. This is possible for both normal and binary (Image, Document, etc.) assets.
Editorial users can also supply custom crafted urls to support SEO and other marketing activities.
Drag and Drop Interface
Most pleasingly, WCS has recently had a long overdue overhaul of the dated user interface, which is now based around the Model-View-Controller pattern and allows tabbed browsing, provides a graphical drag and drop interface for editors to create and manipulate content, and has tightly integrated search based on Lucene.
Many implementations had previously sought to develop such features as customizations to the out of the box, not always successfully.
Content Server Developer
Historically, development of WCS projects has been fairly arduous using the out of the box tools, some of which (e.g. Content Server Explorer) are 10 years old and really showing their age.
However, in the last couple of versions a new development method and tools have been introduced called Content Server Developer tools.
They consist of an Eclipse IDE plug-in that allows a developer to connect an Eclipse workspace to an instance of WCS, as well as a command line tool that allows assets and templates to be imported and exported to flat file-system based resources.
These two together make the use of version control systems such as Subversion or Git a much more viable option through Eclipse plugins such as Subclipse, which really streamlines the development, build and deployment process.
In the past it has been difficult to implement and manage customizations to the Editorial interface. Any changes to the interface had to be analyzed and merged during any upgrade process, which was time consuming.
But from 11.1.6 onwards, there has been a customization framework providing developers a logical way to extend and customize the product at the Global, Site or Asset level, without impacting the upgrade path.
The interface has also been overhauled under the covers, and provides distinct layers (Presentation, Service and Data) and a clear separation of responsibility between the layers.
UCG / Community
Community is an application that runs on the WEM Framework and integrates with WCS. It provides community widget tags that can be deployed on any web page to display comment, review, rating, poll and login bar widgets to visitors.
All comments, reviews and ratings posted to the website are displayed in the Community interface where they can be manually moderated and/or automatically moderated by the auto-moderation filters -- Restricted Words,” “Visitor Blacklist” and “Visitor Whitelist.”
The latest version is now leveraging the authentication APIs of Facebook and Twitter. Community widgets enable visitors to your website (or blogs) to use their existing social networking profiles to provide feedback on your company’s content and to share the same content on their social networking profiles.
Earlier versions were pretty dire -- they were difficult to install, customize and internationalize -- and integration with WCS was pretty arbitrary. It’s still a slightly immature product, but is moving in the right direction with the latest release.
Authentication and Security
As of version 7.5, WCS uses Central Authentication Service (CAS) forits authentication, providing a framework which allows creation of Single Sign-On solutions between WCS and other applications.
Despite its strengths, configuration of CAS can be challenging, particularly in clustered and distributed environments.
Probably the closest competitor to WCS is Adobe’s Experience Manager / CQ5 product (AEM). There are two differentiators that look positively towards WCS.
The first is the level of control you have over caching. AEM caching seems to be very much that you either cache the page or not. Whereas with WCS you can cache to your heart’s content at different levels of the application.
The second is that there doesn’t seem to be any real way of customizing the editorial user experience of AEM other than through the widgets that come with it. WCS seems to have more sophisticated ways to enhance and integrate the product with other applications via the Customization and WEM frameworks mentioned above, making it more of a platform than an application.
However, from a standards point of view, AEM uses CRX, an implementation of the Java Content Repository (JCR) API specification. This spec was led by a developer from Day who wrote CQ5, so the Adobe product definitely has the advantage there.
Pricing, Support and Documentation
The bad news about all the power and flexibility of WCS is that it doesn't come cheap. Perpetual licenses are currently $100,000 per processor according to Oracle’s site, and the first year of Oracle Support will set you back an additional $20,000 or so. Development licenses are generally a lot cheaper, but you can see how running multiple delivery servers with multiple processors can be an expensive exercise.
Oracle’s support for WCS is generally excellent, providing experienced staff and 24x7 coverage, but be aware that their Support agreements usually only cover the core product. This means that for any custom code, modifications or extensions that are used or created for a particular implementation will not be covered by Support, and as most implementations extend the product in one way or another, this can be an issue.
The documentation is very thorough and covers all aspects of the software, from installation to administration, development and end user guides, and has numerous screen shots, examples and code snippets included. The only issue is generally that there’s so much of it, it’s sometimes difficult to know where to start to find what you’re looking for.
WCS is a mature, powerful and extensible platform which is suitable for the most demanding of Enterprise Content Management applications, and its recent reincarnation with a new Editorial interface and Developer Tools is a boon for both business and technical users.
However it needs expert knowledge to really get the best of it and avoid making bad decisions when implementing it, and its price means it may be out of reach for smaller companies and applications.
Title image courtesy of Nuiiko (Shutterstock)