3
Planning for Deployment

3.1 Overview

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.2 Distributed Deployment Considerations

3.2.1 Web Conferencing Issues

Given the intrinsic nature of Oracle Web Conferencing functionality where data from one user's desktop is distributed to other end-user desktops, there could be latency issues for end-users, depending on their location. Oracle Web Conferencing, by itself, cannot address the network latency issues. You must resolve these issues through other mechanisms.

In environments in which users are geographically dispersed, a deployment with a single set of Real-Time Collaboration Core Components instances is not optimal for preventing network latency issues. Instead, consider the following scenarios:

Scenario 1--If there are a lot of 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.

Example: A company has multiple divisions all over the world, and each division's employees have a lot of conferences with each other, and, sometimes, they have conferences with employees from other divisions that are 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. Each location could have its own set of Real-Time Collaboration Core Components instances.

Scenario 2--If attendees of most conferences are in different regions, then having a set of Real-Time Collaboration Core Components instances in each geographical region does not help.

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 is no reason to deploy Real-Time Collaboration Core Components instances in the India site.

3.2.2 Voice Conversion Server Issues

You should deploy Voice Conversion Servers in areas where they are able to successfully dial in to all conference numbers that will be used. In view of phone charges, it might 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.

3.3 Sizing Guidelines

See the Oracle Web Conferencing Sizing Guide to determine the hardware required to set up Web Conferencing for your specific needs.

3.4 Internet/Intranet Considerations

All typical firewall considerations for Web-based applications (Real-Time Collaboration Core Components in DMZ listening on port 80 for HTTP and port 443 for HTTPS, Real-Time Collaboration Repository behind the inner firewall, Oracle9iAS Infrastructure behind the inner firewall) apply when deploying Web Conferencing. Additional requirements for Web Conferencing follow:

• Mx listening port(s): As explained in Chapter 2, "Understanding Oracle Web Conferencing", it is mandatory that Document and Voice Conversion Servers be able to connect to the Real-Time Collaboration Core Components they are servicing. If they are deployed in different DMZs, intra-DMZ firewalls need to be opened up on the port(s) to which the mx component on the Real-Time Collaboration Core Components machine is listening.
• Mx listening port(s): All intranet users should be able to make a direct TCP/IP connection to the Real-Time Collaboration Core Components (the ports that the mx is listening on).

3.5 LBR Considerations

Figure 3-1 Geographically Distributed Deployment Using LBRs

Text description of the illustration dist_lbr.gif

For geographically distributed deployment, you can use load balancers (LBR) to leverage the Real-Time Collaboration clustering support.

• Leveraging the InstanceLocation property requires that geographically separated users are routed to the Oracle Web Conferencing Application (OC4J_imeeting) in their respective areas. This can be accomplished automatically with a geographically enabled load balancer or manually by having users in different locations access different Web Conferencing URLs. The Oracle Web Conferencing Application (OC4J_imeeting) in an instance is the component that picks the Web Conferencing Server process for a conference. The Oracle Web Conferencing Application (OC4J_imeeting) 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.
• Even when an LBR is used, it is mandatory that all Real-Time Collaboration Core Components behind the LBR have externally routable addresses and are accessible directly from the Internet. The Web Conferencing Console needs to establish a connection to mx. See Chapter 2, "Understanding Oracle Web Conferencing" for more information.
• When using an LBR, follow the special configuration guidelines in the Advanced Configuration document at http://otn.oracle.com/products/webconferencing/ to properly configure Oracle9iAS Single Sign-On for use by all the Oracle Real-Time Collaboration Core Components.