Understanding Web content management
In today's global business world, businesses depend upon visibility in their respective marketplaces. With the pervasiveness of the Internet, the Web has become a prime delivery mechanism of this visibility. Worldwide, organizations use the Internet to deliver their presence, from basic organization and company information to e-Commerce. The Web is a sophisticated and key tool.
A Web site is a collection of all of the text, graphic images, links, sounds, and other content elements that make up a presence on the web. Ultimately, the goal is to present content and information in the most dynamic, up-to-date method possible. Each individual document is called a web page. Web sites have three basic components:
A home page - The home page is the top-most page in the Web site.
Local and remotely stored web pages linked to the home page.
Content - Content includes text, graphic images, and sounds.
Content and its management
Content can mean many different things. The most common understanding of business content can be summarized as:
Content supports the work that the enterprise does and interacts in many ways with business operations.
Enterprise content management is the discipline involved with the capture, storage, and management of this kind of content across the enterprise.
Content management makes information easy to find, use, update, and discard when the time comes.
Content can be categorized into the following types among others:
High-volume production content, such as document imaging and computer output, archiving, and presentation
Rich media, such as audio, video, and photos
Web content, such as Internet, intranet, and extranet
Collaborative content, such as office documents, discussions, and e-mail
Enterprise content management has the following objectives:
Provide an efficient and secure solution for managing content within the enterprise, including enterprise-wide content storage, access, search, distribution, and retention. This is especially true with the current focus on corporate accountability and regulatory compliance.
Build knowledge-based environments to leverage corporate know-how and expertise.
Web content types
When your organization offers information via a Web browser, this material is considered Web content. Web content consists of two parts:
The design or presentation of that content
There are two types of content as related to creating, managing, and publishing Web content:
Static Web content
Dynamic Web content
Static Web content
Static Web content is embedded directly into the design and placed statically on a Web page. This type of content is most likely the result of programming rather than content authoring. Due to its static nature and embedded design, this type of content can be difficult to reuse and change.
The content of static Web sites is difficult to alter as the bulk of the content such as text, graphic, and multimedia content are usually stored in HTML pages and not in databases. Changing the content on multiple Web pages can be (and usually is) tedious and time-consuming. There is also the risk of file overwriting critical content and the possibility of important non-content areas such as the security code of the site getting corrupted.
The basic disadvantage of static Web sites is that the web pages are developed at the time of constructing the site. As such, all static Web site owners have to be abjectly dependent on Web professionals whenever any changes become necessary. Though the initial cost of setting up a static Web site may not be costly, its long term maintenance will be expensive, especially if the site owner wishes to effect changes at regular intervals.
Static Web content solutions often require someone within an IT department, or at least a person who possesses Web design and some Web-based IT skills, to translate content into HTML before it can be posted to a Web site or a portal. Accordingly, static Web content is more difficult to use within a dynamic Web site, which changes frequently and requires up-to-date information to deliver maximum value. Additionally, static Web content is often impossible to reuse due to its embedded design.
Dynamic Web content
Rather than embedding the information directly together with the design, dynamic Web content treats the content and the presentation of the content as two distinct entities. By separating the Web content from the presentation layer, you can manage and deliver content quickly and efficiently, independent of its presentation. The ability to manage both content and its presentation layer as separate entities is enabled most frequently by using Web content management systems.
The other advantage of a dynamic-content Web site is not having to depend on Web professionals for making alterations to the Website. A dynamic-content Web site, though developed by Web professionals, can be maintained directly by the site owner. Unlike static Web sites, the initial set up costs of a dynamic-content Web sites is quite high but there will be enormous saving in subsequent maintenance costs.
The owners will not be required to pay Web professionals every time a change in the Web content is needed. A dynamic Web site design will become necessary for online databases, e-businesses and online shopping sites. A dynamic Web design page has the facility to change its content via a program.
Web content management
To thrive in an on-demand environment, you need flexible, cost-effective content management solutions to manage any type of information, including structured data and unstructured content. You need content management solutions that enable data and content to be integrated with multiple applications and processes, distributed or shared throughout and beyond your organization. Furthermore, you need it structured and organized in the way that is best suited for your business.
Web content management fundamentals
In order to understand Wweb content management we must first distinguish between content and the presentation of the content. When a clear separation is made between content and how it is presented, you can appreciate how a single piece of content can potentially be rendered in multiple ways. For example, a single item of content, such as a news article, can be presented in any of the following ways:
On a Web page in a variety of formats, based on user preferences and personalization
In a PDF file
Downloaded to a mobile device
Streamed as an RSS feed
The content is the same, but the presentation can be adapted to best meet a user’s needs within the context of their specific role or preference. This approach also guarantees a consistent view and usage of a Web site. If the design changes, the content parts remain unaffected. Additionally, the content creators do not have to worry about the presentation of their content. This is important because content creators usually do not have significant knowledge of HTML.
Moving forward with this idea, key concepts and functional areas that apply to web content management systems can be grouped in terms of dynamic presentation or content management.
After content is authored and approved, the content publication stage is when the content is released for delivery to the live site. The delivery can be a simple process, such as making a file available on a file system to a Web server and advertising the URL. Or it can be a more complex procedure such as moving content through a complex workflow and into a production environment.
The accuracy and relevancy of content is assured by automating the content life cycle, from creation through approval and delivery to review and archival.
Content aggregation occurs when content from various sources is brought together. In a simple Web site, this occurs manually during the content creation phase. However, in a more dynamic and data-driven environment, the aggregation occurs at an application server level.
Content must be delivered to the user in the appropriate (or desired) format. Most frequently, this implies delivery via HTTP by using browsers and similar devices. Alternatively, content delivery can refer to other publish-and-subscribe methods, data feeds, or Web service protocols.
Aggregation, transactional integration, and performance enhancing caching enrich the user experience.
Content creation and authoring
Content creation and authoring refer to the creation of content and information that is intended to be delivered. Content creators are guided through the authoring process, by using familiar applications, without having to learn new technical skills.
The need for Web content management
It is quite a standard practice for most organizations to use a Web content management system to assist with the process of delivering content to their intranet or Internet site. For example, a product page that details the features and advantages of a new coffee maker. The generation of the words and images can involve several people, including subject matter experts, image designers, proof readers, legal, and IT. If we achieve this all through existing desktop office tools, it can be quite arduous and time consuming. However, by using a modern Web content management system, the process can be streamlined to allow distributed authoring, work flow, preview and ultimately delivery of the finished article to the Internet Web site, notifying the appropriate people. For both intranet and Internet sites, content is king. Without it being current, timely, and appropriately placed, the site can be perceived in a lesser light. From the content delivery process alone, a Web content management system seems like a good choice.
With the content creation, approval and delivery process providing the top capability and benefits from a Web content management system, are there other areas that can lend weight to using a Web content management system? The answer is "Yes". Ensuring that the Web site has a consistent look and feel (branding) is extremely important for the external Internet sites . It is important for a businesses' brand awareness and for ensuring that visitors to the Web site are comfortable with the layout, presentation, and navigation to content. A web content management system provides a structured approach and framework to allow the separation of content and design while ensuring consistency where required. Componentization is also an area that the Web content management framework affords you, by allowing a higher degree of reuse, ultimately building more with less. Again this is another clear area where a Web content management system seems like a good choice.
Content and design are just two important aspects of any Web site (intranet or Internet) that benefit from a WCM system. In addition, the following aspects are important to a Web site:
Content: The creation, approval, and delivery process streamlined to take advantage of your organization's distribution of knowledge and skills.
Design: Separation of design from content to allow for the design process (in-house or agency) to deliver consistent branding of your business, its products, and services.
Componentization: Reuse of assets to allow the business to deliver more with less, and saving money.
Standards: A system to employ best practices where accessibility is required.
Integration and delivery: Providing a framework from which a business can integrate with systems, services, and information including growth from Web sites to portals and beyond.
With these concepts in mind, you can be reassured that you are making the right decision to use a web content management system. While there might be many factors to consider, the following decision tree can guide you to some that might help or provide a starting point to expand upon.
Defining a content centric site
Content-centric applications, currently being adopted by companies, take content management onto the next level. Content combined with business logic is used to influence the behavior of an organization’s key stakeholders- customers, partners, and employees - by persuading them to take actions that best support business objectives. The content displayed in such applications is typically relevant, personalized, and context-aware.
Take the example of a typical corporate intranet, the information is pushed out and presented to users in a completely static form for them to consume. A Web 2.0 intranet, on the other hand, will be dynamic and augmented or even populated by user-generated content and with the flexibility that will enable users to assemble the content in whichever way they want.
Wikis, mash-ups, user-tagging to create folksonomy: social networks are moving interaction far beyond the traditions of business applications. And it is not just the jargon that has evolved: dynamic web development techniques, such as Ajax, are becoming widely adopted; XML is becoming ubiquitous and the whole structure of application delivery is changing.
A content-centric organisation had pushed the use of wikis and blogs to foster improvements in team working. That has had a transformative effect in the way the organisation should think about disseminating information and the way content is delivered for the next stage.
Such work has now filtered through to the way the organisation thinks about all information classes, and how it can squeeze every last drop of knowledge from the vast quantities of operational data it has accumulated.
Introduction to IBM Lotus Web Content Management
In today's global business world, businesses depend upon their visibility in their respective marketplaces. With the pervasiveness of the Internet, the Web has become a prime delivery mechanism of this visibility. Worldwide, organizations use the Internet to deliver their presence, from basic organization and company information to e-commerce. The Web is a sophisticated and key tool.
IBM Lotus Web Content Management provides a sophisticated Web content management tool and platform that is designed to accelerate the delivery and management of critical business information. It enables a collaborative approach to content creation for individuals and teams. It allows for approval of processes, management, and assets. Lotus Web Content Management is an extremely powerful and sophisticated tool that is remarkably easy to use.
Lotus Web Content Management new features and improvements
IBM Lotus Web Content Management v6.0 was released and generally announced in June of 2006. With the introduction of v6.0, Lotus Web Content Management received many new and significant enhancements that added to its capability as an enterprise content management system (CMS) and introduced further levels of scalability and reliability.
Today, Lotus Web Content Management v6.1.5 has built upon these areas further to deliver an enterprise scalable CMS capable of meeting both business and technical requirements. Version 6.1.5 has introduced new product enhancements in many significant areas across the platform including administration, authoring and management of content, rendering, security, workflow, APIs and many others. The following information explores key new additions to the platform and the benefits gained through their use and implementation.
IBM Lotus Web Content Management v6.1.5 includes new features, such as a new rich text editor and Web content viewers, as well as improvements, such as large file handling.
New Web content viewers
Lotus Web Content Management includes a new JSR 286 Web content viewer that integrates the portal's page structure with information from a Web content library. As a result the portal page hierarchy helps to organize the navigation of your content. In addition to leveraging the personalization, presentation, and security benefits afforded by JSR 286, there are additional advantages:
Web Content pages allow you to attach content directly to a page, so you no longer have to configure a rendering portlet to display content from your content library. Other benefits of the JSR 286 Web content viewer include:
Sessions are not required for rendering Web content for both anonymous and authenticated portal users.
Performance is improved over the traditional Web content viewer.
The JSR 286 Web content viewer can be configured to create site analysis log entries, enabling you to gather data about how often content is visited.
Portal Search supports the use of seedlists to make crawling Web sites and their metadata more efficient and to provide content owners fine-grained control over how content and metadata are crawled. Support has been added for the new seedlist 1.0 format. With support for seedlist format 1.0 and the JSR 286 Web content viewer, search result links going to content items now display the content items in the context of the portal page where they are rendered. Seedlist format 1.0 is the out-of-the box seedlist format, however you can configure the portal to use a previous seedlist format if required.
JSR 286 Web content viewer
Based on the Java Portlet Specification 2.0 (JSR 286), the JSR 286 Web content viewer is a full-featured viewer that integrates the portal's page structure with information from a Web content library. In addition to leveraging the personalization, presentation, and security benefits afforded by JSR 286, the JSR 286 Web content viewer provides additional advantages:
Web content pages are supported. Because you attach content to a Web content page when you create it, the JSR 286 Web content viewer automatically displays that content without requiring configuration when you add the Web content viewer to the page.
The portlet does not create a portlet session for rendering Web content for both anonymous and authenticated portal users.
Support for portal site analysis is available to measure how frequently content items are visited.
Performance is improved over the traditional Web content viewer.
New rich text editor
EditLive! is the market leading rich text editor providing rich desktop/office tool capabilities like advanced table editing as well as linking to Web Content Management style sheets, role-based control over the RTE features, accessibility support and more.
New link resources
A new link type is now included to allow you to create links to documents stored in an external ECM or document repository, such as Lotus Quickr. When creating a link to an external document in an HTML or rich text element, you are able to select documents to link to from a pre-defined list of external document repositories.
New syndication feature
A new tool view been added to the syndication administration to allow you to monitor pending items on a syndicator and manually syndicate those items.
Large file handling
Web Content Management now supports documents and other binary files that are greater than 50Mb. Of course, good content design would say you don't want to have a lot of really large content objects that need to be downloaded to your site visitors' browsers.
Web content feed integration
The IBM Web Content Integrator is a solution used for integrating externally managed Web content with Web Content Management. Through the use of standard content syndication feed technologies based on RSS 2.0, the Web Content Integrator provides a loosely-coupled mechanism for transferring published content and meta data to the portal after they have been approved in the source system. Once the content and meta data have been transferred to the portal, it is possible to leverage the built-in content management features of Web Content Management to secure, personalize, and display the content to end users.
Working with IBM Web Content Integrator
If your file resource element is a file type that can be converted to HTML you can now convert the file to HTML and render the converted HTML directly in your Web content. Examples of supported file types include:
Word processing documents (*.doc, *.odt)
Spreadsheets (*.xls) *
HTML files (*.htm, *.html)
Text files (*.txt)
New file upload validation plugin
A new plugin class has been added to allow you to write file validation plug-ins that can be used to validate files uploaded into file resource, image and style sheet elements, and images uploaded into rich text or HTML elements.
IBM Lotus Web Content Management Architecture
The Lotus Web Content Management 6.1.5 application is fully integrated with WebSphere Portal 6.1. As such, all required components of the Lotus Web Content Management application are installed with WebSphere Portal 6.1.5 The following figure provides a high level overview of where Lotus Web Content Management fits into the WebSphere Portal infrastructure.
Architectural frameworks for content in WCM
The following sections briefly describe various frameworks supported by WCM in WebSphere Portal.
Portal provides the basic framework services for content aggregation, role-based access, personalization and security. The underlying J2EE platform provides low-level middleware services such as enabling security with a user registry and session management. These underlying services coupled with the basic services supported by the portal framework can be effectively used to provide content life cycle management in terms of content authoring and content delivery. Different roles, such as author, reviewer, and approver, can participate in their capacity to move the content from authoring to delivery. The content management and delivery framework embedded into Portal can be used in tandem with the other features, such as personalization and content aggregation, which provides an effective layer for presentation services in the architecture. The information architecture can be a combination of the content management and delivery interspersed with other portal navigable pages to render content from different back-end systems.
Traditionally, content is prepared in pure HTML format by using different HTML editors, and the content is hosted on a Web server for the presentation. The URLs are exchanged with the reviewers and approvers for verification and validation over e-mail. The hosting platform is lean and provides no functionality in terms of content management. Dynamic applications came into existence with CGI scripts but had lots of limitations. The evolution of the J2EE platform has brought in a new dimension to display content on Web sites. Static Web content is coupled with the dynamic content generated through servlets and JavaServer Pages (JSPs). One aspect that cannot effectively be provided through this framework is content management.
Internal facing sites are those meant for the employees of an organization. Apart from being simple but easily accessible (through effective navigation), there must be an important application for the employees to visit the site. Typical entities on such an intranet are news, alerts, and role-specific content. Apart from the content, in terms of production, such sites benefit immensely if the intranet users are provided access to applications that are useful for day-to-day activities, such as sales management, defect tracking, customer relationship management, or technical support. The challenge is to intersperse the content by using a content management framework, such as Lotus Web Content Management, with Portal (pages and portlets).
On external facing sites, the content must be updated because the public view decides the image of the organization. The taxonomy of the site should be well defined, and the content should be easily accessible either through browsing or search. The site needs to be fast enough and within the limits of the users' response time perceptions. Any response times more than 5 seconds are perceived to be slow by the users. The framework should support caching techniques at various levels to enhance the response times for different scenarios. The user can have a unique ID with the site, and the content can be personalized according to the profile of each of these users. The architectural and design frameworks should consider how these content management, search, caching, and personalization services can be provided to the user, with the goal of attracting and keeping the attention of the users.
Information architecture and site design
When designing a Web site, organize information in a way that is readily accessible to users. The structure in which information is organized is called the information architecture. In this section, we provide an approach for determining the information architecture for the top levels of your Web content manager (WCM) Web site. You structure the information that is published on a Web site within a site framework that is accessed through Web site navigation. In this section, we lead you through the decision making process by discussing and defining the information architecture, key considerations, decision processes, and information design. Additionally, we explain how to define criteria for site acceptance.
It is important to acknowledge the relationship between the information architecture and the site framework. The site framework structures the information about a published site and is closely integrated with the Web site navigation. To begin, you define an initial site framework with primary and secondary site areas. The site framework is a prerequisite for the design and development of the content management system. In addition, you must develop an initial layout of the home page based on the primary and secondary site areas. Both the framework and the home page layout require review and validation with business stakeholders, from both an authoring and Web usability viewpoint.
Defining the information architecture
Content accessibility on an intranet can have a direct impact on an organization's overall productivity. If users can find the information they are looking for before they even are aware that they are searching, then you have accomplished the goal of organizing the information correctly. The primary reason for sharing information on a Web site is to make it available for users. However, it is often the central reason why Web sites fail, which include for the following reasons:
Information is often voluminous and widespread over different divisions within an organization, making it difficult to maintain a consistent oversight of the structure of information and to determine a structure that is easy to understand and to use.
There is rarely a single person or department with a consistent oversight of all the information that an organization wants to share.
Information is used everyday, and as a result, it is often not obvious which pieces of information are most valuable or how they should be structured.
By using a content management system, content providers can share more information and gain more experience, which can unfortunately result in a strain on the primary organization of the content.
The information architecture defines how the information on a Web site should be organized and linked so that users can access content. An organization should investigate, analyze, design, and implement the information architecture for a site. Then, it must face the challenge of presenting an image that enhances the way in which the user experiences the information.
You might find reasons why a specific path to information supports your business needs. The experience that a user gets can be the key to success and often reflects the organization’s philosophy. Frequently, an organization builds its success on a unique customer experience that cannot be ignored when architecting a Web site. In addition, the audience can vary such that it becomes necessary to separate users into categories to get a good acceptance of the way information is presented on the Web site. For example, consider the following diverse offerings:
A food company might offer both traditional, home style food and more contemporary fast food.
A vehicle manufacturing company might have diverse offerings that range from passenger cars, to industrial trucks, to motorcycles.
A technology company might offer a range of products and services, from technical consulting services to consumer electronics.
Because of this diverse range of products, brands often get their own Web sites with there own information architecture and Web address (URL). In this case, a master (parent) Web site, which includes links to detached Web sites that represent the specific branding, is the best choice. Defining the information architecture is often the most underestimated part of a content management project. Organizations frequently spend a lot of time finding the right content management system and then deciding on the best information architecture for that system.
When planning the information architecture, an organization must determine the following information:
The hierarchical structure of the site
The functionality that is required on the site
The look of individual pages
How to classify the content
The flexibility of the architecture to allow the business to evolve
The information architecture determines the structure of the site, how navigation is derived, and the ease of navigating the site. You develop the following information architectures when designing a content management system:
Document type hierarchy
Defining the information architecture lays much of the groundwork for how content is organized on a site. Regardless of where the content resides, you need a good understanding of the content that is to be displayed.
Physical architecture best practices
In this section, we look at physical architectures that you can use to build the Lotus Web Content Management infrastructure.
In real-world installations of Lotus Web Content Management, a variety of common infrastructure designs are in place. The primary differences in these designs are due to variations in several basic assumptions:
Site size and complexity: For a relatively small Web site, it might not be necessary to have individual servers dedicated to all four types of Lotus Web Content Management environments.
Funding: In many cases, there is a limitation in regard to the funding provided to build out the Lotus Web Content Management infrastructure. In these cases, you must construct your environment as soundly as possible within the budget. However, the budget is likely to force you to reduce the infrastructure.
Corporate standards: Your company standard might not allow for the creation of certain types of servers. For example, it is quite common for smaller companies to omit the staging environment because it requires time and resources to perform the content review in this stage.
The basic architecture (illustrated in the following figure) is the smallest acceptable design for an IBM Lotus Web Content Management infrastructure.
In the basic architecture, a single Lotus Web Content Management server is responsible for all Lotus Web Content Management activities. Site visitors access this single server for content when they visit the Web site.
An HTTP server is placed in the DMZ to receive all requests for site content. This HTTP server acts primarily as a proxy to shield the Lotus Web Content Management server from direct access. If you use IBM HTTP Server (or Apache), the WebSphere Portal and Lotus Web Content Management server can generate an HTTP plug-in to ease configuration of the HTTP server.
While this architecture is technically feasible, there are a variety of issues that make it sub-optimal.
Design advantages include simplicity. This design is simple to implement due to the limited number of components that are involved.
This architecture has the following design disadvantages:
Failover or redundancy: This environment has no failover or redundancy in any layer. If any one part of the system fails, then the entire site appears to be down.
Load balancing: This environment has no load balancing capabilities. There is only one Lotus Web Content Management server, and it must handle the entire workload at all times.
Maintenance: To perform site maintenance, the site must be unavailable.
The intermediate architecture (illustrated in the following figure) attempts to correct the primary run-time deficiencies of the basic architecture.
In the intermediate architecture, multiple Lotus Web Content Management servers share the responsibility for Lotus Web Content Management activities. Site visitors can access any of these servers for content when they visit the Web site.
Multiple HTTP servers are placed in the DMZ to receive requests for site content. These HTTP Servers perform two primary functions:
Proxy: The HTTP servers act as a proxy to shield the Lotus Web Content Management servers from direct access. If you use IBM HTTP Server (or Apache), the WebSphere Portal and IBM Lotus Web Content Management server can generate an HTTP plug-in to ease configuration of the HTTP Server.
Load balancing: The HTTP plug-in can be configured to provide load balancing based on a variety of algorithms. If your Lotus Web Content Management servers are not similar in processing capabilities, you can set up the plug-in to load balance traffic according to server capacity.
While this architecture improves upon the basic architecture, still several issues make it sub-optimal for larger environments.
The intermediate architecture has the following design advantages:
Simplicity: This design is simple to implement due to the limited number of components that are involved.
Load balancing and redundancy: If you are using IBM HTTP Server (or Apache), this environment has basic load balancing capabilities. Because there are duplicates of all components, a basic level of redundancy exists in this design.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.
The intermediate architecture has the following design disadvantages:
Administration: As more Lotus Web Content Management servers are added to the infrastructure, the maintenance effort to make changes increases in a linear fashion. Changes must be manually made to each server because the servers are not clustered in this design.
Failover: While we have redundancy with this design, there is no automated failover in the event that a specific component fails. If any one part of the system fails, there is a likelihood that the site is down to some subset of the users.
The intermediate architecture still contains one major deficiency. That is, there is no failover within the environment. To resolve this issue, we look at building a slightly more complex infrastructure that includes clustering some of the servers.
When you cluster WebSphere Portal servers, they share an identical configuration. This configuration is managed from a WebSphere Deployment Manager server (not pictured). The Deployment Manager is responsible for synchronizing the WebSphere Portal configuration across all servers in the cluster. Thus, when you deploy a Lotus Web Content Management portlet or create a new portal page, the Deployment Manager synchronizes all servers in the cluster, which is a reduction in administrative time and effort.
In addition, when you cluster the WebSphere Portal servers, the Deployment Manager can create a plug-in for IBM HTTP Server and Apache that allows the HTTP servers to gracefully failover in the event that one of the portal servers stops functioning. While setup and maintenance of a cluster take time and effort, this effort is typically small compared to the ongoing benefits provided to the infrastructure.
The WebSphere Portal and Lotus Web Content Management integrated architecture has
the following design advantages:
Load balancing and redundancy: If you are using IBM HTTP Server or Apache, this environment has basic load balancing capabilities. Because there are duplicates of all components, a basic level of redundancy exists in this design.
Failover: With the addition of a cluster, the HTTP Server can provide failover for the WebSphere Portal servers. If any one part of the system fails, the entire site does not appear to be down.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.
Local rendering portlet: If IBM Lotus Web Content Management is running on all portal servers, you can use the Local Rendering Portlet. By not having to communicate with an external Lotus Web Content Management server (as required with the Remote Rendering Portlet), you eliminate a potential performance bottleneck.
Administration: As more IBM Lotus Web Content Management servers are added to the infrastructure, the maintenance effort to maintain the infrastructure does not increase significantly. Changes to server configurations are performed from the central Deployment Manager console.
The WebSphere Portal and Lotus Web Content Management integrated architecture has the following design disadvantages:
Complexity: This design is fairly complex. The learning curve for installing and administering a clustered environment servers should not be underestimated.
Cost: Enabling Lotus Web Content Management on every WebSphere Portal server quickly increases your infrastructure cost.
WebSphere Portal and IBM Lotus Web Content Management separated
In the WebSphere Portal and IBM Lotus Web Content Management separated architecture, we no longer enable Lotus Web Content Management on all of the WebSphere Portal servers. Instead, we create a separate tier of servers with the sole task of serving Lotus Web Content Management content as illustrated in the following figure.
As with the other advanced architecture, this configuration clusters the portal servers. However, in this configuration, we create a separate cluster for the Lotus Web Content Management servers.
When you cluster the WebSphere Portal or Lotus Web Content Management servers, they share identical configurations within their respective cluster. This configuration is managed from a WebSphere Deployment Manager server (not pictured). The Deployment Manager is responsible for synchronizing the configuration across all servers in each cluster. This means that, when you deploy an updated Lotus Web Content Management portlet or create a new portal page, the Deployment Manager synchronizes all servers in the appropriate cluster, resulting in a reduction in administrative time and effort. In addition, when you cluster the WebSphere Portal or IBM Lotus Web Content Management servers, the Deployment Manager can create a plug-in for IBM HTTP Server or Apache that allows the HTTP Servers to gracefully failover in the event that one of the portal servers stops functioning. This is how both sets of HTTP Servers can provide failover for WebSphere Portal and Lotus Web Content Management requests.
The WebSphere Portal and IBM Lotus Web Content Management separated architecture
has the following design advantages:
Failover: The addition of a cluster allows the HTTP Server to provide failover for each cluster. If any one part of the system fails, the entire site does not appear to be down.
Maintenance: With multiple servers available to deliver content, site maintenance can be performed without the entire site becoming unavailable.
Administration: As more WebSphere Portal or IBM Lotus Web Content Management servers are added to the infrastructure the maintenance effort to maintain the infrastructure does not increase significantly. Changes to server configurations are performed from the central Deployment Manager console.
The WebSphere Portal and IBM Lotus Web Content Management separated architecture has the following design disadvantages:
Complexity: This design is fairly complex. The learning curve for installing and administering a clustered environment servers should not be underestimated.
Remote Rendering Portlet: If IBM Lotus Web Content Management is running on a separate set of servers all portal servers, you must use the Remote Rendering Portlet. Because this portlet communicates with an external IBM Lotus Web Content Management server, there is a potential performance bottleneck if the network connection is poor.
IBM Lotus Web Content Management system components
This section defines the key components of IBM Lotus Web Content Management.
IBM Lotus Web Content Management Server
The IBM Lotus Web Content Management Content Server is the core of the IBM Lotus Web Content Management application. All requests for content are ultimately processed by the Content Server.
The IBM Lotus Web Content Management Content Server leverages Virtual Member Manager as its user repository. This repository is used for both authentication as well as determining group membership for authenticated users.
IBM Lotus Web Content Management Content Repository
When you first enable IBM Lotus Web Content Management, it uses WebSphere Portal’s embedded Apache® Derby database as its content repository.
If desired, you can switch your IBM Lotus Web Content Management repository to any of the supported databases.
IBM Lotus Web Content Management Authoring Portlet
The user interface for working with IBM Lotus Web Content Management is provided via a Portlet running within WebSphere Portal.
The Authoring Portlet is (more accurately) your sole graphical user interface for interacting with IBM Lotus Web Content Management. Content creators use the portlet to author content. Content approvers use this same portlet for managing content.
Developers use this portlet to create technical assets (for example, Presentation Templates, Workflows, Syndication components, and so forth). The Authoring Portlet allows for very granular user interface security controls.
IBM Lotus Web Content Management Connect Servlet
The Connect Servlet is used to deliver Web content outside of a WebSphere Portal environment. You would use this servlet when you need to deliver a traditional standalone Web site. Site visitors can access content by requesting the HTML directly from the Connect Servlet.
It is important to note that even if you only use Connect Servlet to deliver stand-alone (non-portal) Web sites, the core IBM Lotus Web Content Management™ application always runs on WebSphere Portal.
IBM Lotus Web Content Management Rendering Portlets
IBM Lotus Web Content Management provides two Portlets that can display your content in WebSphere Portal. These portlets require no Java coding - only simple configuration by the portal administrator.
IBM Lotus Web Content Management Local Rendering Portlet
A local rendering portlet displays Web content on the same portal server as the instance where IBM Lotus Web Content Management is installed. This portlet can only be used when deployed to a WebSphere Portal Server that also has a live instance of IBM Lotus Web Content Management.
The Local Rendering Portlet relies on the IBM Lotus Web Content Management API to interact with the IBM Lotus Web Content Management Content Server.
IBM Lotus Web Content Management Remote Rendering Portlet
A remote rendering portlet displays Web content on a different portal server than the instance where IBM Lotus Web Content Management is installed. Unlike the Local Rendering Portlet, the Remote Rendering Portlet uses an HTTP connection to interact with a remote IBM Lotus Web Content Management Content Server at run time. The configuration of this portlet contains some additional fields to facilitate this type of connection.
IBM Lotus Web Content Management Public API
While IBM Lotus Web Content Management provides a solid set of Web content management capabilities out-of-the-box, there are times when the standard capabilities of IBM Lotus Web Content Management do not meet your exact needs. For situations such as this IBM Workplace Web Content Management provides a Java API. It is important to note that the IBM Lotus Web Content Management API does not expose all the capabilities of the IBM Lotus Web Content Management application. The JavaDocs should be reviewed for a complete set of the features available using the API. The Javadoc HTML files are located under the was_profile_root folder. In this path name, was_profile_root is the profile root for WebSphere Portal Server.
IBM Lotus Web Content Management JavaServer Pages Tags
In addition to the Java API, IBM Lotus Web Content Management provides a JavaServer Pages Tag Library that you can use when developing Portlets and other J2EE applications. The tags in this library make it very easy to access your IBM Lotus Web Content Management content from a JSP page. These tags rely on the API for their functionality so they do not provide any capabilities beyond those of the API.
Understanding roles in IBM Lotus Web Content Management
Different types of users are responsible for different tasks when deploying a Web Content Management system or when creating and managing Web sites and Web content.
System wide roles
Web Content Management is a component of WebSphere Portal. As such, the deployment process for Web Content Management systems is a sub-process of the overall WebSphere Portal deployment process. Many of the overall system planning and deployment tasks will be performed by users with system-wide responsibilities.
Web content administrator
A Web content administrator is responsible for configuring the Web content servers within a WebSphere Portal system.
Web content information architect
The information architect is responsible for determining the architecture of a site including things like library structure, the site framework, categories and site navigation as well as delivery methodologies.
Web content graphic designer
A Web content graphic designer is responsible for designing the layout and style of the Web pages and graphics in a Web site.
Web site creator
A Web site creator is responsible for building a Web site by creating presentation templates, authoring templates, site areas, components and categories. They are also responsible for creating content management items such as folders and workflows. The items created by a Web site creator are based on the designs created by the information architect and graphic designer.
Web content developer
A Web content developer is responsible for extending Web Content Management by using the Web Content API, developing JSP components and creating Web content plug-ins.
Web content author
A Web content author is responsible for creating Web content for the sites developed and managed using Web Content Management.
Web content approver
A Web content approver is responsible for approving Web content items that use workflows.
Web content manager
A Web content manager is responsible for performing ongoing site maintenance activities.
Web content tester
A Web content tester is responsible for performing functional and performance user acceptance testing (UAT) within UAT environments.
Web content viewer
A Web content viewer is the person viewing your Web site. They could be an internal viewer within a company intranet, or an external viewer such as a customer of a commercial Web site.
Case Study of moving River Bend to a Portal content centric site
This section provides information and examples related to the movement of a fictional site (River Bend Coffee) to a Portal content centric site.
River Bend is a fictional coffee company created as part of another wiki: Building a website using WCM 6.1: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WCM-Master-Table-of-Contents
For the purpose of providing a realistic business context to this wiki, we reuse the River Bend Tea and Coffee Company as the basis for the development scenario. River Bend Coffee and Tea Company, a subsidiary of WWCorp, is a fictitious company that uses Lotus Web Content Management software.
It operates a chain of 20 retail stores in 12 cities worldwide. In addition, the company runs an Internet-based retail operation, offers small-scale catering services, and has launched a certification program for employees and customers who wish to become skilled roast masters.
The figures below illustrate highlights of their current site and provides a brief overview of the components we build in this section.
The current economic landscape in the coffee market pushed River Bend to invest strongly in their Web site to increase customers awareness and one of the key initiatives that the IT department will be taking on is migrating the current WCM based site to a Portal centric solution that would provide these advantages:
Improved branding through Portal themes
User self-care and personalization
Rich user interface through client-side aggregation
Integration of external services consumption such as widgets and google gadgets
Access to online services
Integration of social software services like blogs and wikis
This figure shows the new Portal based site that provides a stronger platform to achieve River Bend business goals while improving the old user interface with Portal rich user interface features:
The following sections cover the steps in the migration process.
Import River Bend library
The River Bend WCM library was imported in a fresh Portal 6.1.5 installation by using the standard JCR import tool.
Adapt presentation artifacts for Portal
Most of the work that had to be done was related with adapting the old user interface to be Portal based.
River Bend presentation templates were based on WCM components to display the banner, navigation elements and footer so it was necessary only to remove those elements from the existing templates to make existing content ready to be displayed through portlets.
This figure shows how a content item was displayed on the old River Bend site:
This figure shows the same content item displayed in two separate portlets, one for the launch content and the other for a menu of items:
The following shows the code for a WCM based presentation template:
<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
<Component name="html-header" htmlencode="true" />
<!-- set bg colour, x-y overlay image and fonts -->
<div id="mainBg" > <!-- main transparent background 946px -->
<div id="banner" ><Component name="html-logo" />
<Component name="search_form" /></div>
<div id="middle_left"> <!-- left column content begin -->
<div id="navigation"><Component name= "nav-left" /></ div >
<!-- left column content end -->
<div id="middle_center"> <!-- middle column and actual content begin -->
coffeeSmall.JPG?MOD=AJPERES" BORDER="0" title="" />
<td background="images/gradient_490.gif" height="1">
<img src="images/1pix.gif" width="5" height=
"5"></ td >
<table width="100%" border="0" cellpadding="0" cellspacing="10">
<td ><b> <!-- Reference the title of the content -->
<IDCmpnt context="current" type="content" field ="title" /></b></td>
<!-- Reference the elements of the content in the following section -->
<Element context="current" type="content" key=
<Element context="current" type="content" key="Body" /></span></td>
<td><Element context="current" type="content" key="Image" /></td>
<Element context="current" type ="content" key="Complimentary"/></td>
<Element context="current" type="content" key="Related" />
<td> <!-- Reference the menu component of the products menu-products -->
<!-- Reference the authoring tool component -->
<!-- Reference the JSP Component for adding comments here -->
And this is the same presentation template adapted to be shown in a portlet:
<h1><IDCmpnt context="current" type="content" field="title"/></h1>
<h3><Element context="current" type="content" key="Summary"/></h3>
<Element context="current" type="content" key="Body"/>
<img src="<Element context="current" type="content" key="Image" format="url"/>"
weight="200" height="200" />
Something you should notice is that Portal theme css styles are being used in presentation templates to keep a consistent user interface.
Create a Portal theme
As we mentioned earlier, the site branding will be managed by a Portal theme so you must create or configure an existing Portal theme to generate a look and feel similar to the old WCM based site.
Create a Portal page hierarchy
Once you have adapted your presentation templates and menu components to be displayed in a portlet you should create a page hierarchy that links part of your site area with the Portal navigation tree.
One thing to keep in mind is that not all your site areas need to be converted into Portal pages. Alternatively, you can use a portlet to display a menu or navigator component that lists the last levels of navigation just like River Bend did in the Beverages area:
It's strongly recommended to use both WCM based pages and JSR 286 Web content viewers to allow portal to automatically link content between different pages while browsing, previewing or displaying search results. To create a Web content page proceed as follows:
From Portal administration click on New page from
Enter page name, URL mapping and click on Web content folder and Select
Select the WCM area that will be linked to this Portal page
This will create a new Portal page linked to the WCM site area. Now it is time to add a WCM JSR 286 viewer to display some content on it. To do this just open the page, put it in edit mode and drag and drop a Portlet instance:
The portlet will display the default content for the area linked with this page without further configuration
Portal provides over WCM an extra aggregation layer that provides three big advantages: improve personalization and customization, integration with other services and rich user interfaces.
This features might be leveraged by River Bend to create a web 2.0 portal that adds value to their customer on top of their existing content.
This figures and the next sections provide a description of the kind of services that can be used to improve the existing services:
Branding through themes
Portal themes will allow River Bend to separate the site branding from the content making it easier to:
Test and update the site design more frequently
Use different look and feels for different brands or countries
Allow the end user to personalize some part of the interface such as the color palette
Reuse Portal theme widgets to give rich user interface theme components like navigation menus or search boxes.
Site navigation and dynamic layout management
Managing the navigation of the site through Portal will make it easier to create new pages and mix Web content with external and internal services such applications, widgets or information that comes from feeds.
Dynamic layout management will allow River Bend Web masters to update the content and structure the home page easily making the site more attractive to customers with just a few clicks.
User self care and personalization
Portal customization allows the end customer to personalize their Portal experience in different ways:
Customize page contents and structure
Updating their profile to reflect their topics of interest
River Bend Web masters can use personalization campaigns to show or hide parts of the Portal navigation as well as specific page components.
Rich UI features
Portal rich user interface features such as client-side aggregation or live text will give River Bend customers a better user experience with minimal changes to the existing content.
WCM presentation templates can leverage Dojo widgets to build rich components such as image galleries or graphical effects.
Integration of services
Current WCM content can be mixed in a Portal page with services and applications either internal or external to provide customers role-based, contextual pages. Some examples are:
Widgets and Google Gadgets
Wikis, Blogs, bookmarks, activities, communities or files hosted on Lotus Connections
Team spaces in Lotus Quickr
Federated content from ECM systems displayed through personalization elements
Transactional services such order management through portlets.