I've been around the block with this product so many times I've worn out all my shoes. From its earliest days as FutureTense ContentServer, through the FatWire years, to its most recent incarnation as Oracle WebCenter Sites and everything along the way, it's been a very interesting, rewarding and occasionally frustrating journey through the eight (or eleven, depending on how you count) versions.
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 126.96.36.199 version.