12 Overview of Community-Gadgets

This chapter provides an overview of WebCenter Sites: Community-Gadgets and describes its configuration for both a simple development and content management environment, and a complex production environment.

This chapter contains the following sections:

• Section 12.1, "About Community-Gadgets"

• Section 12.2, "Production and Management Environments"

• Section 12.3, "Community-Gadgets Configurations"

12.1 About Community-Gadgets

Community-Gadgets is a set of Java EE web applications that integrates with Oracle WebCenter Sites and works in a distributed environment as a social computing application. Community-Gadgets provides its users with two Web Experience Management (WEM) applications: Community and Gadgets.

The Community WEM application enables its users to configure widgets for gathering visitors' comments, reviews, and ratings on website content. The Community WEM application also enables its users to create and manage polls for surveying site visitors about desired topics. The Gadgets WEM application enables its users to deploy individual gadgets, or even a dashboard with one or more gadgets, to website visitors.

Before proceeding to describe the configurations in which Community-Gadgets can be installed, this chapter provides an overview of Community-Gadgets, its relationship to WebCenter Sites, its components, and their purposes.

This section contains the following topics:

• Section 12.1.1, "Community-Gadgets Using Components of WebCenter Sites"

• Section 12.1.2, "Community-Gadgets Management and Production Components"

12.1.1 Community-Gadgets Using Components of WebCenter Sites

Community-Gadgets integrates with WebCenter Sites through the Web Experience Management Framework to make use of the following resources:

• Asset repository: Community-Gadgets requires an asset repository. WebCenter Sites provides an asset repository, that is, a database. Community-Gadgets does not directly access the database. All interaction with the database is managed by WebCenter Sites.

• WebCenter Sites: Web Experience Management Framework (WEM Framework), which provides Community-Gadgets with the REST service and the Central Authentication Service (CAS).

  • REST service enables Community-Gadgets to communicate with WebCenter Sites to make use of its asset model.

  • CAS is used to provide authentication services for the REST API.

    Note:

    Like WebCenter Sites, Community-Gadgets has its own CAS instance, but only on the production side. To distinguish between CAS instances, CAS shipped with WebCenter Sites is called "WEM CAS" (or Sites CAS), and CAS shipped with Community-Gadgets is called "Visitors CAS."Despite the fact that CAS web applications (WEM CAS and Visitors CAS) are nearly identical at the code level, their configurations differ and they are not interchangeable; nor can they be installed on the same application server or cluster.

    More information about CAS is available at the following URL:

    http://www.jasig.org/cas

    Note:

    WebCenter Sites can be integrated with OAM (instead of CAS).

    • On the management system, Community-Gadgets uses the same OAM that is integrated with WebCenter Sites in order to communicate with WebCenter Sites.

    • On the production system, Community-Gadgets uses Visitors CAS for visitors authentication. It cannot be replaced with OAM. However, WebCenter Sites on the production system can be integrated with OAM (like WebCenter Sites on the management system), and Community-Gadgets can use OAM to communicate with WebCenter Sites on the production system.

12.1.2 Community-Gadgets Management and Production Components

Community-Gadgets consists of two parts: a management set of applications, and a production (delivery) set of applications.

Note:

Management Community-Gadgets and production Community-Gadgets must be deployed on separate application server instances. Deployment of both on a single application server is not supported.

• Management Community-Gadgets contains two web applications:

  • Community-Gadgets web application

  • Shindig web application

• Production Community-Gadgets contains three web applications:

  • Community-Gadgets web application

  • Shindig web application

  • CAS web application

Management Community-Gadgets is used for the administration of user-generated content (UGC), registering gadgets, and similar functions. For security reasons, it is typically accessible only internally. Production Community-Gadgets is accessed by visitors through widgets and gadget dashboards deployed onto web pages. It manages visitor authorization through Visitors CAS.

Both management and production Community-Gadgets use Shindig OpenSocial container for rendering gadgets. Production Community-Gadgets must be externally accessible. More information about the Shindig web application is available at the following URL:

http://shindig.apache.org/

For its end users, Community-Gadgets provides two WEM applications:

• Community WEM application — provides the Community interface, which is used to configure widgets for collecting visitors' comments, reviews, ratings, and votes at polls. The Community WEM application is also used to moderate user-generated content.

• Gadgets WEM application — provides the Gadgets administrator interface (Global Catalog) and the Gadgets user interface. Which interface is displayed to the user depends on the user's roles. Both interfaces are used for gadgets management, which includes registering, sharing, and configuring gadgets and the dashboard.

For more information about the WEM Framework and WEM applications, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide and the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

12.2 Production and Management Environments

To manage user-generated content, Community-Gadgets requires two environments: a management environment and a production (delivery) environment, where the management and production Community-Gadgets instances are in constant communication with WebCenter Sites.

This section contains the following topics:

• Section 12.2.1, "WebCenter Sites Communications"

• Section 12.2.2, "Community-Gadgets Communications with WebCenter Sites"

12.2.1 WebCenter Sites Communications

In WebCenter Sites, content for the website is generated and managed strictly on the management system, then published to the production system, as shown in Figure 12-1. Templates are generated on the content management system, and then published to the production system to configure the appearance of published content.

Figure 12-1 WebCenter Sites Communications

Description of ''Figure 12-1 WebCenter Sites Communications''

Website content is generated, managed, and published strictly by users of the WebCenter Sites content management application.

12.2.2 Community-Gadgets Communications with WebCenter Sites

In Community-Gadgets systems, content generation and management processes differ from those on WebCenter Sites because they involve several types of users, including website visitors, all interacting with each other's content through WebCenter Sites.

• Widgets and gadgets are generated and deployed by users of the management Community-Gadgets instance to the WebCenter Sites production system.

• User-generated content, such as comments and reviews, is entered by website visitors into deployed widgets on the Community-Gadgets production instance.

• User-generated content is stored in the WebCenter Sites production database. The content is managed by administrator and moderator users of the management Community-Gadgets.

Throughout these interactions, widgets, gadgets, and content are stored in the WebCenter Sites management and production databases. As shown in Figure 12-2, all content generation and management processes involving Community-Gadgets pass through WebCenter Sites.

Figure 12-2 Community-Gadgets Communications with WebCenter Sites

Description of ''Figure 12-2 Community-Gadgets Communications with WebCenter Sites''

Note:

Figure 12-2 shows the use of a firewall. The firewall must allow free information exchange on all ports used by WebCenter Sites and Community-Gadgets.

12.3 Community-Gadgets Configurations

The Community-Gadgets environment can be configured in many ways. This section describes the commonly used configurations: basic and production.

This section contains the following topics:

• Section 12.3.1, "Basic Configuration"

• Section 12.3.2, "Production Configurations"

12.3.1 Basic Configuration

A basic Community-Gadgets environment consists of four self-contained blocks: Community-Gadgets (production), Community-Gadgets (management), WebCenter Sites (production), and WebCenter Sites (content management). These blocks are depicted in Figure 12-3, where they are labeled as A, B, C, and D.

Figure 12-3 Basic Community-Gadgets Environment: Development, Staging, or Limited Production Environment

Description of ''Figure 12-3 Basic Community-Gadgets Environment: Development, Staging, or Limited Production Environment''

The blocks shown in Figure 12-3 can be deployed in a number of ways, in any configuration, as long as independent application servers are used for each application inside each block.

Note:

Possible configurations range from running all four blocks on different servers to running all the blocks on a single server. Deployment of management and production applications on a single server are supported only for development purposes (non-production environment).

The configuration shown in Figure 12-3 is best suited - and commonly used - for development and staging. It may also be used for QA and production where limited load and no expandability or redundancy are required. In Figure 12-3, two independent servers are used. Each server has an independent stack consisting of an instance of WebCenter Sites: Community-Gadgets and an instance of WebCenter Sites. This means, each server has two independent (non-clustered) application servers and a local database. Between the two servers, communications flow through an optional firewall (depending on security requirements).

12.3.2 Production Configurations

Deploying Community-Gadgets on a production environment uses the same four basic blocks introduced in Section 12.3.1, "Basic Configuration." However, each of these blocks is now divided into sub-blocks to provide both redundancy and scalability. In addition to breaking up the blocks, we recommend using HTTPS for all communications to improve security.

The figures in the rest of this chapter illustrate, at a high level, the different clustered configurations that will be used in a production environment.

• Figure 12-4 shows a sample management stack in a production environment.

• Figure 12-5 shows a sample production (delivery) stack in a production environment.

• Figure 12-6 shows a Community-Gadgets production block divided into two sub-blocks.

• Figure 12-7 shows a Community-Gadgets production block divided into six sub-blocks.

Figure 12-4 Sample Management Stack in a Production Environment

Description of ''Figure 12-4 Sample Management Stack in a Production Environment''

Figure 12-4 shows a clustered version of the management stack illustrated in Figure 12-3.

In Figure 12-4, the management Community-Gadgets (Block B in Figure 12-3) is now clustered. The management WebCenter Sites application (Block D in Figure 12-3) is also clustered and uses a database cluster.

Figure 12-5 Sample Production (Delivery) Stack in a Production Environment

Description of ''Figure 12-5 Sample Production (Delivery) Stack in a Production Environment''

Figure 12-5 shows a clustered version of the production stack illustrated in Figure 12-3.

In Figure 12-5, production Community-Gadgets (Block A in Figure 12-3) is now clustered. The production WebCenter Sites application (Block C in Figure 12-3) is also clustered and uses a database cluster.

Figure 12-6 Community-Gadgets Production Block Consisting of Two Sub-Blocks

Description of ''Figure 12-6 Community-Gadgets Production Block Consisting of Two Sub-Blocks''

In Figure 12-6, the Community-Gadgets production block (Block A in Figure 12-3) is divided into a cluster of two servers (which can be expanded to any number of servers simply by duplicating the sub-block, as shown in Figure 12-7).

• Critical to the functionality of each sub-block is the fact that the application servers are fully clustered and include session failover.

• The file system is duplicated on each instance, as each cluster member requires unique configuration files for Community-Gadgets, Shindig, and Visitors CAS.

  Note:

  The example in Figure 12-6 uses a shared file system. A shared file system is not required and the relevant directories can simply be copied, if that is preferred.

• A load balancer has been introduced in front of the cluster members to provide failover in case of a failure.

Figure 12-7 Community-Gadgets Production Block Consisting of Six Sub-Blocks

Description of ''Figure 12-7 Community-Gadgets Production Block Consisting of Six Sub-Blocks''

In Figure 12-7, the Community-Gadgets production block (Block A in Figure 12-3) is divided into six sub-blocks, on six servers. The Community-Gadgets production block consists of three independent clusters: one for Visitors CAS, one for Shindig, and one for Community-Gadgets. While this kind of breakdown is possible, it is not recommended. Typically, a cluster of two sub-blocks, as shown in Figure 12-6, provides the required capabilities and failover, and with less administrative overhead.

• In Figure 12-7, critical to the functionality of each sub-block is the fact that the application servers are fully clustered and include session failover.

• All servers access the same shared file system for configuration information.

  Note:

  The example in Figure 12-7 uses a shared file system. A shared file system is not required and the relevant directories can simply be copied over if that is preferred.

• Three load balancers have been introduced: one for Community-Gadgets, one for the Shindig application, and one for Visitors CAS.