Skip Headers

Oracle® Web Conferencing Administrator's Guide
Release 2 (2.0.4.3)

Part Number B10877-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

3 Planning for Deployment

This chapter highlights the factors to consider when deploying Oracle Web Conferencing. The issues range from sizing guidelines to firewall issues to topology considerations for an enterprise that is geographically distributed.

3.1 Sizing Guidelines

The Oracle Web Conferencing Sizing Guide helps you determine the hardware required to set up Web Conferencing for your specific needs. Please read this guide prior to installing and deploying Web Conferencing

3.2 Internet/Intranet Considerations

As discussed in previous chapters, the Oracle Web Conferencing system includes the following components:

In addition, the Oracle Web Conferencing system interacts with an Oracle9iAS Infrastructure system to manage user sign-on and to synchronize user information with the Oracle Internet Directory.

Figure 3-1, "Oracle Real-Time Collaboration Basic Components" shows the components needed for Web Conferencing. After you have installed Web Conferencing, you will have the following components:

Figure 3-1 Oracle Real-Time Collaboration Basic Components

Real-Time Collaboration Basic Components
Description of the illustration ocsig002.gif

The Oracle Real-Time Collaboration Core components and Document and Voice Conversion servers are installed on Oracle9iAS mid-tier systems. Document and Voice Conversion servers must be installed on a computer running Microsoft Windows and Microsoft Office. (The Voice Conversion and Document Conversion servers have additional hardware and software requirements discussed in the Oracle Web Conferencing Sizing Guide). The supporting database and infrastructure systems are often installed on a separate database host, although they can also be installed together with the core components.

Some considerations need to be made, however, to support conference services on a corporate intranet that generally includes a secure intranet area behind a firewall, a DMZ ("demilitarized zone") between the firewall and the public Internet, and web conferencing users both within the intranet and outside the firewall in the Internet.

Figure 3-2, "Oracle Real-Time Collaboration Example Deployment" shows an example of a deployment that can allow access to users outside the corporate firewall. The components are placed as follows in the DMZ or behind the firewall:

Figure 3-2 Oracle Real-Time Collaboration Example Deployment

Components deployed inside and outside the company DMZ area.
Description of the illustration ocsig003.gif

The Single Sign-On Server and Oracle Real-Time Collaboration Core components can be located on the same mid-tier system, if desired. The Single Sign-On server can remain with the Oracle9iAS infrastructure if both are placed in the DMZ to serve Internet users. The repository and Oracle9iAS infrastructure can be on separate machines or combined, or can even be combined on a machine with the Oracle Real-Time Collaboration core components.

In addition, you must consider where the multiplexer listening ports are placed:

3.3 Load Balancer Considerations

You may use a Load Balancer (LBR) to manage processes handled by your Oracle mid-tier servers. If so, then keep these considerations in mind:

See Chapter 6, "Sample Deployments" for an example.

3.4 Distributed Deployment Considerations

If you have multiple corporate locations that will use Web Conferencing, then you must consider:

The following sections outline some rules of thumb to apply when considering where to deploy Real-Time Collaboration core components and Voice Conversion servers.

3.4.1 Deploying Core Components Locally or Globally

Because data from one user's desktop is distributed to other end-user desktops during Web Conferencing, end users may experience latency issues depending on their location. Oracle Web Conferencing, by itself, cannot address network latency issues. You must resolve these issues through other mechanisms.

However, you can consider where you will deploy the Real-Time Collaboration core components, depending on how many meetings are held in specific geographic locations as described the the following two scenarios.

Scenario 1: Many Meetings in Separate Geographical Locations

If your company holds many conferences where most of the attendees are in the same geographical region, then Oracle Corporation recommends deploying a set of Real-Time Collaboration Core Components instances in that geographical region.

For example, a company has multiple divisions all over the world, and each division's employees hold many conferences with each other. Occasionally they hold conferences with employees from other divisions in different locations.

In such a scenario, it does not make sense to force users to use a Real-Time Collaboration cluster in a different location, thereby causing network latency problems for users. Instead, each location can have its own set of Real-Time Collaboration Core Components instances. See "Real-Time Collaboration Clusters" for discussion of how to create geographically-oriented clusters of components.

Scenario 2: Many Meetings Across Geographical Locations

If attendees of most conferences are in different regions, then having a set of Real-Time Collaboration Core Components instances in each geographical region will not help prevent latency issues.

For example, a US-based company has outsourced its sales/support organization to a site in India. If a typical conference involves a sales agent from the site in India and a customer in the US, then there deploying Real-Time Collaboration Core Components instances in the India site will not prevent a latency problem.

3.4.2 Deploying Voice Conversion Server Locally or Globally

You should deploy Voice Conversion Servers in areas where the servers are able to successfully dial in to all conference numbers that will be used. It may be beneficial to deploy a Voice Conversion Server in the region where most calls terminate. For example, if a significantly large number of Web Conferencing users dial out to a particular region like the United Kingdom, it would be beneficial to have a Voice Conversion Server deployed in the UK instead of using a Voice Conversion Server in the United States to dial the UK numbers. See "Real-Time Collaboration Clusters" for discussion of how to create geographically-oriented components.

3.4.3 Real-Time Collaboration Clusters

Without explicit partitioning of the instances in the system, all Web Conferencing Server processes in all instances are considered part of one group. Whenever a new conference is created and a Web Conferencing Server process needs to be chosen for a conference, the conference could be assigned to any one of the Web Conferencing Servers in the system. But, sometimes, it is useful to partition the system into clusters based on geographical distribution.

Figure 3-3, "Real-Time Collaboration Clustering" shows a sample Web Conferencing deployment where components are grouped according to their geographic locations.

Figure 3-3 Real-Time Collaboration Clustering

Example of two Real-Time Collaboration clusters.
Description of the illustration dist_lbr2.gif

To create clusters like those shown in Figure 3-3, you use the InstanceLocation property. Instances that have the same value for the InstanceLocation property are part of a Real-Time Collaboration cluster. The advantages of creating a cluster include:

  • Load balancing: All Web Conferencing Server processes in all instances that are part of the cluster become part of one pool of available servers, and the load is balanced intelligently between the different Web Conferencing Servers.

  • Load separation: If hardware load balancers are also geographically distributed, users can be served by separate Real-Time Collaboration clusters that are more locally situated to the users.

  • High availability: An instance could be down, which means that all Web Conferencing Servers in the instance are down, but other Collaboration Servers from other instances that are part of the same cluster can provide undisrupted service to users.

The Oracle Web Conferencing Application (OC4J_imeeting) is the component that picks the Web Conferencing Server process for a conference. The Oracle Web Conferencing Application knows the Web Conferencing Server process location and picks a Collaboration Server process in an instance which has the same value as its own location.

The Document Conversion server or Voice Conversion server can also be assigned an InstanceLocation property. If you have multiple Document and/or Voice Conversion servers that are installed at different geographic locations, and you used the InstanceLocation property to identify clusters of Real-Time Collaboration core components, you can also assign matching InstanceLocation properties to the Document and Voice Conversion servers. For example, as shown in Figure 3-3, "Real-Time Collaboration Clustering", each instance of the Document and Voice Conversion Servers in the United Kingdom is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "UK." Each instance in the set of Document and Voice Conversion Servers in the United States is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "US."


See Also:

See "Properties to Configure Clusters" for details about setting the InstanceLocation property.