| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
This chapter contains the following topics:
This chapter provides the conceptual background required to deploy Oracle Real-Time Collaboration. It provides an overview of the Oracle Real-Time Collaboration architecture which is a discussion of deployment planning issues and deployment configurations.
This section describes the Oracle Real-Time Collaboration architecture.
Figure 10-1 Oracle Real-Time Collaboration Architecture
In Figure 10-1, the Infrastructure tier contains the following:
Oracle Internet Directory for user authentication and verification
Oracle Real-Time Collaboration Store for storing Web conferencing information.
In Figure 10-1, the Applications tier contains the Oracle HTTP Server and the Oracle Real-Time Collaboration server. The Oracle HTTP Server is used as the listening point for end-user connection requests over the Internet to the Oracle Real-Time Collaboration system. Web cache is automatically installed with Oracle Real-Time Collaboration but is typically not used with the product. The Oracle HTTP Server runs with the mod_imeeting service, which does the following:
Provides unified HTTP listening point
Passes inbound connections as sockets to the Real-Time Collaboration Multiplexer
For the Cobrowse mode distributes page content to the browsers of the clients.
The Oracle Real-Time Collaboration Server contains the following components:
Communication Services
Oracle Real-Time Collaboration contains the following communication services:
Real-Time Collaboration Multiplexer: Real-Time Collaboration Multiplexer acts as a communications hub between Web Conferencing console clients (end users participating in a conference) and Web Conferencing servers. It does the following:
Accepts inbound connections from Web Conferencing console clients and Web Conferencing Servers.
Routes data traffic between all clients and all Web Conferencing Servers on a system.
Client Connection Manager: The Client Connection Manager handles all connections between Oracle RTC Messenger clients (end users participating in chat sessions) and the RTC Messenger router.
Real-Time Collaboration Redirector: The Real-Time Collaboration Redirector redirects accepted connections to the appropriate Oracle Real-Time Collaboration communication processes. These include the Real-Time Collaboration Multiplexer for Web conferences or the Client Connection Manager for chat sessions. The Real-Time Collaboration Redirector also load balances between all requests, sending the connections to the most appropriate, available multiplexer or connection manager.
Application Services
Application Services provide the scheduling and reporting features of the Web Client pages.
System Services
System Services provide system management through properties, statistics reporting, and process monitoring.
Integration Services
Integration Services can be used to tightly integrate any application to the Oracle Real-Time Collaboration functions.
Collaboration Services
Oracle Real-Time Collaboration contains the following collaboration services:
Data Services
Voice Services including the voice proxy server. The Voice Proxy server handles real-time, two-way voice communications during voice chat sessions in RTC Messenger, and during voice chats with PC microphone in Web Conferencing.
Presence Server
The Oracle Presence Server provides the services required for instant messaging, chat conferences, and publishing the presence of Oracle Messenger users. There can be more than one Oracle Presence Server in an Oracle Real-Time Collaboration deployment, but only one server runs at a time. If the first goes down, then a special high-availability process associated with each server will start the next.
Voice Conversion Server (Optional)
The Voice Conversion server is used to support streaming voice data during a Web conference and playback of recorded conferences. During a Web conference, it dials in to a voice conferencing system, captures the analog voice stream, digitalizes it, and streams it to a Web Conferencing Server process through the multiplexer. In the figure, the Voice Conversion server is shown residing on another physical computer than most other Oracle Real-Time Collaboration processes. The Voice Conversion server must be installed on a Windows computer, and has associated required hardware requirements.
Document Conversion Server (Optional)
The Document Conversion server converts Microsoft Office documents to HTML for document presentation. The Oracle Real-Time Collaboration Application provides the front end for a user to convert a document. Like the Voice Conversion server, the Document Conversion server must be installed on a Windows computer.
This section lists the programmatic access and user access components of the Oracle Real-Time Collaboration architecture.
Programmatic Access
In Figure 10-1, programmatic Access includes the following:
XML
SOAP
XMPP
SIP
SDKs
User Access
In Figure 10-1, user Access includes the following:
Real-Time Collaboration Messenger Console
Web Conferencing Console
Web Conferencing Playback Console
Web Application Pages
This section describes the functionality of the Oracle Real-Time Collaboration architectural components.
The following terminology must be understood before deploying Oracle Real-Time Collaboration:
Component
A component is a set of one or more identical Oracle Real-Time Collaboration processes that can be considered as logical processes from an operating system perspective. Examples include the Oracle Real-Time Collaboration multiplexer, mod_imeeting, and the Oracle Web Conferencing Server.
Instance
An instance is a group of Oracle Real-Time Collaboration components that share the same Oracle Real-Time Collaboration Home. For example, a group of Oracle Real-Time Collaboration instances running in the United States could be referred to as US Instance 1, and US Instance 2.
Cluster
A cluster is a group of one or more Oracle Real-Time Collaboration Instances that form a logical unit. Clusters provide load balancing, high availability, sharing of Oracle Real-Time Collaboration voice and document conversion services, and ease of management. For example, an organization could have Oracle Real-Time Collaboration clusters in different geographic regions such as the United States (US Cluster) and the United Kingdom (UK Cluster).
Site
A site is set of Oracle Real-Time Collaboration services exposed to a line of business. Examples may include the direct site, development site, and support site of an organization.
System
A system is a group of one or more Oracle Real-Time Collaboration Clusters that share the same Oracle Real-Time Collaboration Repository. For example, http://iMeeting.acme.com could encompass a US Cluster and UK Cluster of an organization, both of which share the same Oracle Real-Time Collaboration repository.
This section describes the interaction between Oracle Real-Time Collaboration components.
Figure 10-2 Oracle Real-Time Collaboration Component Interaction
Figure 10-2 illustrates the interaction between components in an Oracle Real-Time Collaboration core component instance and a voice and document conversion server instance.
Oracle Real-Time Collaboration Core Components Instance
An Oracle Real-Time Collaboration core component instance contains the following components. All of the components listed in this section are monitored by a Real-Time Collaboration Process Manager except for the Oracle HTTP Server and OC4J_imeeting:
Oracle HTTP Server with mod_imeeting is described in the "Oracle Real-Time Collaboration Architecture" section.
Presence server is described in the "Oracle Real-Time Collaboration Architecture" section.
Real-Time Collaboration Redirector is described in the "Oracle Real-Time Collaboration Architecture" section.
Oracle Web Conferencing Server provides the services for a Web conference by performing the following:
Managing all the conference attendees' states and their permissions within the conference.
Intelligently distributing real-time data for all the collaboration modes that are active during the conference.
Providing services for the recording and archiving of the conference.
Client Connection Manager is described in the "Oracle Real-Time Collaboration Architecture" section.
Real-Time Collaboration Multiplexor is described in the "Oracle Real-Time Collaboration Architecture" section.
Real-Time Collaboration Process Manager watches all the other Oracle Real-Time Collaboration processes (except for OC4J_imeeting processes), and provides high availability by restarting processes if they are down. This process itself is monitored by the Oracle Process Management and Notification system.
Voice and Document Conversion Server Instance
A voice and document conversion server instance contains the following components, both of which are monitored by a Real-Time Collaboration Process Manager:
Voice Conversion Server is described in the "Oracle Real-Time Collaboration Architecture" section
Document Conversion Server is described in the "Oracle Real-Time Collaboration Architecture" section
Real-Time Collaboration Process Manager watches all the other Oracle Real-Time Collaboration processes (except for OC4J_imeeting processes), and provides high availability by restarting processes if they are down. This process itself is monitored by the Oracle Process Management and Notification system.
This section describes an Oracle Real-Time Collaboration instance
Figure 10-3 Oracle Real-Time Collaboration Instance
An Oracle Real-Time Collaboration instance is comprised of the following components operating with each other:
Oracle Real-Time Collaboration core component instance
Voice and document conversion server instance
Oracle Internet Directory
Real-Time Collaboration store
Voice proxy server
An additional Real-Time Collaboration Process Manager for the voice proxy server.
Details for each of these components are provided in the "Oracle Real-Time Collaboration Architecture" section and the "Oracle Real-Time Collaboration Component Interaction" section.
External users must be able to connect to the computers containing the Oracle Real-Time Collaboration core component instances. This can be accomplished through a number of different access solutions such as using reverse proxy to bypass the firewall and setup a direct connection with external clients, or using Network Address Translation (NAT) to tunnel into the nodes containing the Oracle Real-Time Collaboration core components instances. Implementation of these solutions may vary depending on an organization's requirements.
|
See Also: For detailed information about the different Oracle Real-Time Collaboration client connections, see "Oracle Real-Time Collaboration Client Connections and Run-Time Flows" in Chapter 1 of Oracle Real-Time Collaboration Administrator's Guide |
The Oracle Web Conferencing and Oracle Messenger console clients attempt to connect to the Oracle Real-Time Collaboration system using one of the following methods, attempting them in the following order until successful:
Direct TCP/IP: Clients within a corporate intranet connect directly to the RTC Redirector, which hands off connections to the Client Connection Manager (for instant messages) or Multiplexer (for Web conferences), using Jabber XMPP/XMPPS for messaging, or proprietary protocols (MX) with TCP/IP or SSL for Web Conferences.
HTTPS direct: Clients in the open Internet or across transparent proxies connect using HTTPS. The mod_imeeting plug-in uses the Oracle HTTP Server as the single listening point over port 443, hands the socket off to the Connection Manager or Multiplexer, and the console connects directly to one of these.
HTTPS tunnel: Clients in a different intranet coming through their own internal proxy provide the console with proxy information from the browser settings. The console establishes a connection to the Oracle HTTP Server, which hands the connection off to the Connection Manager or Multiplexer over an HTTPS tunnel through the remote proxy. Again, the listening port is 443.
Oracle Real-Time Collaboration connections do not work over reverse proxies. If you want to allow connections over the Internet to Oracle Real-Time Collaboration, the Applications tier must have an Internet-routable address. You can either do the following:
Deploy the Applications tier in DMZ of your company, with its IP address publicly routable, with ports 80 (for HTTP) and 443 (for HTTPS) accessible.
Use a NAT machine to map the internal IP address to an external IP address, with ports 80 (for HTTP) and 443 (for HTTPS) accessible.
This section uses an Oracle Real-Time Collaboration cluster to provide an overview of Oracle Real-Time Collaboration access requirements
Figure 10-4 Oracle Real-Time Collaboration Cluster
Figure 10-4 illustrates an Oracle Real-Time Collaboration cluster and how Oracle Real-Time Collaboration consoles establish and maintain communication with the Oracle Real-Time Collaboration Applications tier computers.
Network Architecture
In Figure 10-4 the Applications tier is deployed in a load balanced DMZ (between two firewalls) and the Infrastructure tier is deployed in the internal network of an organization behind a firewall.
Infrastructure Tier
The following components are deployed on the Infrastructure tier:
Oracle Internet Directory
The Oracle Real-Time Collaboration store
Applications Tier
The following components are deployed on the Applications tier:
The single sign-on server, which may be deployed in the DMZ on either a dedicated computer or on any of the Applications tier computers that contain the Oracle Real-Time Collaboration core components. The single sign-on server is not Internet routable and is only routable from the Applications tier.
Two computers, each containing an Oracle Real-Time Collaboration core component instance.
A computer with the voice and document instance (optional)
Internal Network Connections
In Figure 10-4, users in the internal network of an organization connect directly to the Oracle Real-Time Collaboration Applications tier computer using the Web conferencing client console or the instant messenger console.
Web Connections
In Figure 10-4, users connect with Oracle Real-Time Collaboration from the Internet in the following steps:
A user enters the Web address for the desired Real-Time Collaboration site and is authenticated against Oracle Internet Directory. In this example, the Web address for authentication is HTTP://login.acme.com/ or HTTPS://login.acme.com/.
After logging on, the user is redirected to the Oracle Real-Time Collaboration Applications tier computer, which serves a page for downloading the Web conferencing client console and instant messenger console. In this example, the Web address for the download page is HTTP://login.acme.com/ or HTTPS://rtc.acme.com/ on Ports 80/443.
The user downloads the Web conferencing client console and instant messenger consoles and uses them to connect directly to the Oracle Real-Time Collaboration Applications tier computer without using a load balancer. In this example, two consoles connect to two different Oracle Real-Time Collaboration Applications tier computers with Web addresses HTTP://rtc1.acme.com/ or HTTPS://rtc1.acme.com/ and HTTP://login.acme.com/ or HTTPS://rtc2.acme.com/on Ports 80/443.
Details for these steps are provided in the "Client Connection Process Flow" section that follows.
This section provides a step-by-step description of how Web conferencing and instant messenger consoles access the Oracle Real-Time Collaboration Applications tier computers. This process takes place in three basic phases:
The following steps take place during user authentication.
The user requests a login to a pre-login page and load balancer directs the request to one of the Applications tier computers that contains the Real-Time Collaboration core component instance.
The user request is redirected to the Single Sign-On server, which in this example is located at HTTP://login.acme.com/ or HTTPS://login.acme.com/
The user is authenticated against Oracle Internet Directory, a cookie is returned to the browser of a user and the user is redirected to one of the Applications tier computers that contains the Real-Time Collaboration core component instance.
Figure 10-6 Application Pages Access Flow
Following successful user authentication, the browser request is redirected to the Applications tier computer that contains the Real-Time Collaboration core component instance. In this example, the browser is redirected to HTTP://login.acme.com/ or HTTPS://rtc.acme.com/ on Ports 80/443.
The Applications tier computer with Real-Time Collaboration core component instance serves a download page for the Web conference client console and instant messenger console as well as the appropriate Web conferencing address. If the console is already installed on the computer of the user, then it automatically launches.
The user downloads and installs the Web conferencing client console and instant messenger console.
The Web conferencing client console and instant messenger console connect directly to the Oracle Real-Time Collaboration Applications tier computer. In this example, the console connects to the Oracle Real-Time Collaboration Applications tier computer with Web addresses HTTP://login.acme.com/ or HTTPS://rtc1.acme.com/ on Ports 80/443 and optionally using the User Datagram Protocol (UDP) for voice.
|
IMPORTANT: The Applications tier computer with the Real-Time Collaboration core component instance must be internet routable and must have a unique IP address.Client consoles accessing this computer from the Internet may do so using either NAT or a DMZ with a public IP address. |
This section discusses a range of issues involved in deploying Oracle Real-Time Collaboration components. These include hardware and software prerequisites, sizing guidelines, firewall issues, and topology considerations for a geographically distributed organization.
The following prerequisites are necessary for any deployment of Oracle Real-Time Collaboration.
Optional Document and Voice Conversion Server
Voice and document conversion server (needed if using voice streaming over a PSTN phone line, or document sharing in conferences):
Windows 2000 Server SP4 and higher
Intel Dialogic System software 5.1.1 SP1 and higher (for voice streaming over a PSTN line)
System Requirements for Web Conferencing Client
Each Web Conferencing user must have administrative privileges on his system in order to install the client console. Each user's system must meet the following requirements:
Windows 98 or higher
Internet Explorer 5.5 or later, Netscape 4.75 or later, Netscape 7.0 or later, Mozilla 1.0 or later, or Firefox 1.1 or higher
1024 x 768 screen resolution
Microsoft Java Virtual Machine (JVM) version 1.1.4 Build 3740 or later, or Sun JVM 1.3.1 or later, installed and enabled
*All listed browsers can perform all tasks in the Real-Time Collaboration Web application pages, and can use the conference whiteboard and desktop sharing features. In addition, Netscape 4.X browsers (prior to Netscape 4.75) can use most Web application features, but they cannot use the Schedule tab to schedule a conference.
Only Internet Explorer 5.5 browsers (or later) can share documents in document presentation mode, stream voice data in a conference over PSTN, or play back a recorded conference. Each Internet Explorer user must have Java Virtual Machine (JVM) installed and Java enabled in Internet Explorer in order to use these features. To check whether you have a JVM installed and enabled, do the following:
Open Internet Explorer.
Select Tools and then Internet Options.
Click the Advanced tab.
Scroll down to Java (Sun) or Microsoft VM and make sure all boxes under the heading you find are checked ON.
If you do not see any references to Java or VM, then you need to download and install a Java Virtual Machine. Please contact your system administrator for information about what JVM your company uses and supports. After you've installed a JVM, verify that it is enabled by repeating the previous steps.
System Requirements for Oracle RTC Messenger Client
Each RTC Messenger user must have administrative privileges on his system in order to install the client console. Each system must be running Windows NT, Windows 2000, or Windows XP.
Oracle RTC Messenger uses XMPP, an open, industry-standard protocol for instant messaging. For more information about XMPP, go to http://www.jabber.org/protocol/.
The native Oracle RTC Messenger client works only on a Windows computer. For the list of supported instant messaging clients and instructions about using them to connect to RTC Messenger, see the RTC Messenger FAQ at http://www.oracle.com/technology/products/cs/user_info/ortc/messenger_index.html.
Requirements for Oracle Real-Time Collaboration Add-in for Microsoft Office
The Oracle Real-Time Collaboration Add-in for Microsoft Office works with Microsoft Office 2000 or later.
This section discusses Oracle Real-Time Collaboration sizing information. Additional information is posted on Metalink.
The Oracle Real-Time Collaboration components perform load balancing as they handle communications between clients and servers. The Redirector determines which multiplexer or communication manager processes are available as it routes requests from clients. The multiplexer determines which Web Conferencing Server processes are available as it routes communications from and to the Web Conferencing clients.
You may also choose to use a Load Balancer to manage processes handled by your Oracle mid-tier servers. If so, then keep the following considerations in mind:
All systems behind the load balancer should have intranet-routable IP addresses and must be directly accessible from the Internet at least on the standard HTTP and HTTPS ports (80 and 443).
If you use geographic load balancers – that is, load balancers to separate loads between geographic locations – then you must create Oracle Real-Time Collaboration clusters to partition the system based on geographical distribution
Messenger also uses ports 5222 and 5223 which in some cases must be open to the Internet.
If you have multiple corporate locations that will use Oracle Real-Time Collaboration Web Conferencing, then you must consider the following:
The number of conferences held and instant messages sent at a single geographic location
The number of conferences held and instant messages sent across geographic locations
The number of streaming-voice conferences held across geographic locations, if voice streaming over PSTN phone lines is used
After evaluating these issues, you can then consider whether creating clusters will help distribute Real-Time Collaboration Web Conferencing and instant messaging processes to distinct geographic locations.
The following sections outline some rules of thumb to apply when considering where to deploy Real-Time Collaboration core components and Voice Conversion servers.
|
Note: Note that there is only one RTC Messenger Router running at any time. The considerations discussed in the following sections apply only to deployment of systems to support the multiple Web Conferencing Server processes. |
Because data from desktop of one user is distributed to other end-user desktops during a Web conference or instant message, end users may experience latency issues depending on their location. Oracle Real-Time Collaboration, 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 much traffic passes within specific geographic locations, as described the following scenarios.
Scenario 1: Many Meetings or Messages in Separate Geographical Locations
If your company holds many conferences where most of the attendees are in the same geographical region, or sends many instant messages between employees in the same region, then Oracle 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 employees of each division hold many conferences with each other and send many instant messages to each other. Occasionally they hold conferences with or send messages to employees 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.
Scenario 2: Many Meetings Across Geographical Locations
If attendees of most conferences are in different regions, or instant messages are sent equally between members of 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 or 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 deploying Real-Time Collaboration Core Components instances in the India site will not prevent a latency problem.
If you hold streaming voice conferences using PSTN phone lines, then 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 UK, it would be beneficial to have a Voice Conversion Server deployed in the UK instead of using a Voice Conversion Server in the USA to dial the UK numbers.
Oracle Real-Time Collaboration server is designed to scale well in a Symmetric Multiprocessing (SMP) configuration, or a multi-node configuration. You can scale up. In other words, you can add more components to an Oracle Real-Time Collaboration Applications tier computer. You can scale out. In other words, you add more Oracle Real-Time Collaboration Applications tier computers.
Figure 10-8 Scaling Oracle Real-Time Collaboration
Figure 10-8 illustrates the available options for scaling Oracle Real-Time Collaboration. This figure, shows two configurations, scaling up and scaling out. In the scaling up configuration, more hardware components are added to an Oracle Real-Time Collaboration Applications tier computer. In the scaling out configuration, more Oracle Real-Time Collaboration Applications tier computers are added.
Oracle Real-Time Collaboration deployment configurations follow the same guidelines as those for Oracle Collaboration Suite. For information on deploying Oracle Real-Time Collaboration in a single-computer, multiple-computer, or high availability environment, please refer to Chapter 3, "Deploying Oracle Collaboration Suite". Other Oracle Real-Time Collaboration deployment configurations are provided in this section.
By default, 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 can be assigned to any one of the Web Conferencing Servers in the system. But, as described in the previous sections, it is sometimes useful to partition the system into clusters based on geographical distribution.
Figure 10-9 Geographic Distribution with Oracle Real-Time Collaboration Clusters
Figure 10-9 illustrates an Oracle Real-Time Collaboration geographic distribution using Oracle Real-Time Collaboration.
In Figure 10-9, the Infrastructure tier contains Oracle Internet Directory and redundant Oracle Real-Time Collaboration store computers configured for RAC.
In Figure 10-9, Applications tier consists of two clusters in a DMZ and traffic is served to each cluster from multiple load balancers. Separate clusters of Real-Time Collaboration core components are placed in the US and UK and each configuration has multiple Oracle Real-Time Collaboration Applications tier computers as well as a voice and document conversion server. The single sign-on server, may be deployed in the DMZ on either a dedicated computer or on any of the Applications tier computers that contain the Oracle Real-Time Collaboration core components. The single sign-on server is not Internet routable and is only routable from the Applications tier. The single sign-on server can be deployed in either cluster and will still authenticate against Oracle Internet Directory and return a cookie to the browser of the user.
In Figure 10-9,users in the internal network of an organization connect directly to the Oracle Real-Time Collaboration Applications tier computer using the Web conferencing client console or the instant messenger console.
In Figure 10-9,users connect with Oracle Real-Time Collaboration from the Internet in the following steps:
A user enters the Web address for the desired Real-Time Collaboration site and is authenticated against Oracle Internet Directory. In this example, the Web address for authentication is HTTP://login.acme.com/ or HTTPS://login.acme.com/.
After logging on, the load balancer determines the user's geographic origin and redirects the user is to the appropriate Oracle Real-Time Collaboration Applications tier computer for the user's desired geographic location (in this example, either the US, or UK). This computer serves a page for downloading the Web conferencing client console and instant messenger console. In this example, the Web address for the download page is HTTP://rtc.acme.com or HTTPS://rtc.acme.com/on Ports 80/443.
The user downloads the Web conferencing client console and instant messenger consoles and uses them to connect directly to the Oracle Real-Time Collaboration Applications tier computer without using a load balancer. In this example, two consoles connect to two different Oracle Real-Time Collaboration Applications tier computers with Web addresses HTTP://rtc1.acme.com/ or HTTPS://rtc1.acme.com/and HTTP://rtc2.acme.com/ or HTTPS://rtc2.acme.com/on Ports 80/443.
