| Oracle® Web Conferencing Administrator's Guide Release 2 (2.0.4.3) Part Number B10877-03 |
|
|
View PDF |
| Oracle® Web Conferencing Administrator's Guide Release 2 (2.0.4.3) Part Number B10877-03 |
|
|
View PDF |
This chapter explains Oracle Web Conferencing concepts and architecture. This chapter describes:
Real-Time Collaboration terms and concepts
Real-Time Collaboration processes of Oracle Web Conferencing, including the function of each and their interactions.
The detailed runtime flow of various kinds of clients connected to the Web Conferencing Server for a conference.
Ports required for Web Conferencing and and an overview of network connectivity issues
The following sections describe in detail some of the terms used in Oracle Real-Time Collaboration and introduce you to some basic concepts about the system.
A Real-Time Collaboration instance is a group of Real-Time Collaboration components installed on the same machine.
Three basic components—the Core Components, Document Conversion Server, and the Voice Conversion Server—are created during installation. If all are installed on the same machine, there is only one instance only. The Real-Time Collaboration Repository is either present in the information store database when Oracle Collaboration Suite information store is installed, or it is created during installation of first Core Components installation.
An Oracle Real-Time Collaboration component is a set of processes within an instance that perform an identical function. Each component has a component type and component name. (Component types and names can be used when configuring the system using the imtctl command, as described in Chapter 10, "imtctl Command Line Utility".)
The following table lists the Real-Time Collaboration component types and names:
Table 2-1 Real-Time Collaboration Components
| Full Component Name | Component Type | Component Name | Number of Processes |
|---|---|---|---|
| Oracle Web Conferencing Server | clbsvr | imt-collab | 1-n |
| Web Conferencing J2EE Application: OC4J_imeeting | oc4j | oc4j_imeeting | 1-n |
| Multiplexer | mxcomm | imt-mx | 1-n |
| Voice Conversion Server | voiceconv | imt-voiceconv | 1 |
| Document Conversion Server | docconv | imt-docconv | 1 |
| Real-Time Collaboration Process Monitor | imt-pm | imt-pm | 1 |
You can use the listComponents imtctl command to see a list of components in an instance. See Chapter 10, "imtctl Command Line Utility" for details.
Figure 2-1, "Components and Processes of a Real-Time Collaboration Instance" shows an instance with three components and each of their processes.
Figure 2-1 Components and Processes of a Real-Time Collaboration Instance
Component A: OC4J_imeeting (one process)
Component B: Real-Time Collaboration multiplexer (two processes)
Component C: Web Conferencing Server (four processes)
A group of Real-Time Collaboration instances that have the same InstanceLocation property and that use the same Real-Time Collaboration Repository. Clusters are discussed in more detail in Chapter 3, "Planning for Deployment".
Figure 2-3, "Real-Time Collaboration Architecture" shows how the Real-Time Collaboration components interact with each other. The following sections describe each component's role in the Web Conferencing system in more detail.
Oracle Web Conferencing Server
A Web Conferencing Server component does the following:
Manages all the conference attendees' states and their permissions within the conference
Intelligently distributes real-time data for all the collaboration modes that are active during the conference
Provides services for the recording and archiving of the conference
Real-Time Collaboration Multiplexer (mx)
The multiplexer component does the following:
Accepts inbound connections from clients, Web Conferencing Servers, and other Real-Time Collaboration processes.
Routes data traffic between all clients and all Web Conferencing Servers on a machine.
Acts as a communication hub for all components.
OC4J_imeeting
OC4J_imeeting is the Oracle Web Conferencing J2EE Application running in the Oracle9iAS Containers for J2EE. It does the following:
Provides the Web-based user interface to Oracle Web Conferencing for end-users.
Provides integration with external applications like Oracle Calendar.
Interfaces with Oracle Internet Directory for user management.
Real-Time Collaboration Process Monitor (imt-pm)
The process monitor watches all the other 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 Conversion Server
The Voice Conversion server dials in to a voice conferencing system, captures the analog voice stream, digitizes it, and streams it to a Web Conferencing Server process through the mx.
Document Conversion Server
The Document Conversion server converts Microsoft Office documents to HTML for document presentation. The Web Conferencing Application provides the front end for a user to convert a document.
HTTPD + mod_imeeting
The mod_imeeting plug-in interacts with the Oracle HTTP Server. It makes it possible for Oracle Web Conferencing to use Oracle HTTP Server as the only listening point to listen for end-user connection requests. Connections are handed off to the mx using socket hand-off, after the connection has been established using Oracle HTTP Server as the listener. See "Client Connection Details" for more information about how the HTTP Server and plug-in interact.
The following sections describe the Real-Time Collaboration processes within an instance, and across instances. They also describe the connections made by the processes.
Within an instance, each Web Conferencing Server process is always connected to each multiplexer (mx) process.
Each OC4J process can connect to any mx in the cluster to which the instance belongs. OC4J initially connects to one of the mx processes when required, and from then on caches the connection.
Through the Oracle Web Conferencing Console, each conference participant connects to one of the mx processes, either directly or through a socket hand-off as described in "Client Connection Details". The mod_imeeting connects to all the mx processes in the same instance.
Across instances, the Voice Conversion server and Document Conversion server processes in an instance connect to all the multiplexer processes in another instance that they have been configured to service.
Real-Time Collaboration components make both virtual channel connections and connections to the Real-Time Collaboration Repository (the database).
Virtual Channels
All processes connect to the multiplexer, which acts as a communication hub, and so the following essential virtual channels are created:
The Web Conferencing Console connects to the Web Conferencing Server process through the multiplexer during a conference.
The Oracle Web Conferencing OC4J_imeeting processes connect to the Document Conversion Server process through the multiplexer used for document conversions.
Each Web Conferencing Server process connects to the Voice Conversion Server process through the multiplexer for voice streaming during a conference.
Database Connections
Each Web Conferencing Server process maintains a pool of connections to the Real-Time Collaboration Repository.
Each OC4J_imeeting process maintains a pool of connections to the Real-Time Collaboration Repository.
Each Document Conversion Server maintains a connection to Real-Time Collaboration Repository.
Each Real-Time Collaboration Process Monitor maintains a connection to Real-Time Collaboration Repository.
The following sections describe the flow of events as users join a conference, and provide more details about how users connect to the Web Conferencing system.
When an attendee joins a conference through the Oracle Web Conferencing Application, an e-mail invitation, or through an application that is integrated with Oracle Web Conferencing, the following events take place:
The application looks up the conference record from the database and retrieves the list of Web Conferencing Servers that can host the conference. The application authorizes the request based on the person joining and the attributes of the conference the person intends to join.
The server load balancer functionality in the Oracle Web Conferencing Application (OC4J_imeeting) chooses a Web Conferencing Server process, initiates the session there, and records the association between the conference ID and the Web Conferencing Server process.
The list of client parameters for the Web Conferencing Console to connect is generated:
The multiplexer load balancer (running in OC4J) functions in the Oracle Web Conferencing Application (OC4J_imeeting). It chooses one mx, which can be used to connect to that server process.
HTTPS connection information is taken from the mx description (that identifies which Oracle HTTP Server/mod can be used to redirect the connection).
An encrypted client authentication token is generated.
URLs to send user feedback information and retrieve Java/JSP components used in the console are generated.
The Oracle Web Conferencing Application response causes a pop-up window on the user's Web browser to open, which contains a Web Conferencing Console Installer (an ActiveX control) with the client parameters.
If the user does not have the Web Conferencing Console Installer yet or has an earlier version, the most recent version is downloaded and installed by Internet Explorer automatically (with a permission alert).
The Web Conferencing Console Installer performs compatibility checks. If compatibility checks are successful, it checks the version of the Web Conferencing Console available on the client system.
If the Web Conferencing Console is not installed on the client machine, or if the Web Conferencing Console version does not match the current one, the new console package is downloaded and installed.
The Web Conferencing Console Installer starts the Web Conferencing Console (as a separate process) with all parameters.
The Web Conferencing Console tries to establish connection to mx using the algorithm described in detail in "Client Connection Details". Then:
If all attempts fail, the client receives an error message.
If a connection is established, then the Web Conferencing Console creates a virtual channel through mx to the conference session and continues with the next steps.
The Web Conferencing Console sends an authorization token identifying the client to the server.
The Web Conferencing Server sends all conference state information (list of attendees, shared content, chat transcripts, and so on) to the Web Conferencing Console to initialize the Console.
The Web Conferencing Console opens and the conference begins.
This section describes in more detail how attendees connect to Web Conferencing. All conference attendees fall into one of three categories:
Attendees connect directly to Oracle Web Conferencing without traversing any firewall. Example: all attendees are in the corporate intranet.
Attendees connect to Oracle Web Conferencing from the Internet crossing a company firewall. Example: Web Conferencing is deployed in a company demilitarized zone (DMZ), and attendees from the Internet connect to the conference.
Attendees are connecting through the Internet from another company's corporate intranet through their proxy.
The Web Conferencing Console attempts to connect to the multiplexer as follows:
Direct TCP/IP: This method is typically successful for clients within a corporate intranet. It is also successful for clients coming from the Internet, if the multiplexer port is open to the Internet.
HTTPS direct (through Oracle HTTP Server/mod_imeeting): If direct TCP/IP fails, the Web Conferencing Console tries to connect through HTTPS. This connection is typically successful for clients in the open Internet or across transparent proxies. Once a connection is established by Oracle HTTP Server, it is handed off to the multiplexer by mod_imeeting using socket hand-off. The multiplexer and the Web Conferencing Console then communicate directly with each other.
HTTPS tunnel (through Oracle HTTP Server/mod_imeeting): If both direct TCP/IP and HTTPS direct fail, going through the HTTPS tunnel is the only connection method for clients in a different intranet coming through their own internal proxy. The Web Conferencing Console tries to retrieve proxy information from the browser settings on the client machine and establish a connection to the Oracle HTTP Server using the proxy. Once established, the connection is handed off to the multiplexer by mod_imeeting. In this case, the Web Conferencing Console and multiplexer communicate over the HTTPS tunnel through the remote proxy.
The connection information required to connect using the methods described in this section is provided to a Web Conferencing Console (transparent to a user) when a user tries to join a conference.
The following table contains port and network connectivity information for Oracle Web Conferencing.
Table 2-2 Ports and Network Connectivity
| Component | Protocol | Port | IP | No. of Ports | Accessibility (Mandatory) | Accessibility (Recommended) |
|---|---|---|---|---|---|---|
| Oracle HTTP Server / mod_imeeting | HTTP | 80 | Primary | 1 | All clients | |
| Oracle HTTP Server / mod_imeeting | HTTPS | 443 | Primary | 1 | All clients | |
| Oracle HTTP Server / mod_imeeting | HTTPS tunnel | 443 | SecondaryFoot 1 | 1 | All clients | |
| mx (multiplexer) | mxFoot 2 | 2400-49151Foot 3 | Primary | n | Voice Conversion Server and Document Conversion Server must be able to access the multiplexers on the instances they serve. | Intranet clients could connect using direct TCP/IP. If Real-Time Collaboration Core Components are deployed in a DMZ, accessing these port(s) from the intranet is not an issue. |
| mx (on NT) | redirectFoot 4 | 2400-49151 | Primary | n | Local host | |
| voiced | HTTP | 2400-49151 | Primary | 1 | All machines with the Real-Time Collaboration Core Components this Voice Conversion Server supports. | For remote status |
| imt-pm | HTTP | 2400-49151 | Primary | 1 | Local host from all Real-Time Collaboration instances. |
For deployments that are accessible from the Internet, it is enough for Internet- or extranet-facing firewalls of the DMZ to have just the traditional ports (443 and 80) open.
Oracle Real-Time Collaboration uses the Oracle Internet Directory store, which uses LDAP (Lightweight Directory Access Protocol), to authenticate its users. Any Oracle Internet Directory user can use Real-Time Collaboration. Users are created using the standard mechanisms available through Oracle Internet Directory.
Real-Time Collaboration users can be assigned different roles. Roles determine the Oracle Web Conferencing functionality to which a user has access. There are three roles in Web Conferencing:
The end-user role, enduser, is the default role given to any user who logs in to the system for the first time. This role is intended for all regular users of Oracle Web Conferencing.
The business monitor role, businessmonitor, is intended for those Oracle Web Conferencing users who want to monitor the system and have access to various reports that can be run on the system. Users with this role have access to the Monitor and Reports tabs, in addition to all end-user tabs in the Oracle Web Conferencing Application.
The business administrator role, businessadmin, is intended for those Web Conferencing users who are in charge of administering the Web Conferencing deployment. This includes users who are responsible for supporting the end-users. Users who have this responsibility have access to the Site Management and the System Configuration tabs in the Web Conferencing Application.
Use the imtctl command, modifyRole, to assign roles to Web Conferencing users. See Chapter 10, "imtctl Command Line Utility" for more information about imtctl.
Oracle Web Conferencing lets you create individual sites for your different lines of business (for example, sales and support) and to customize system, application, and conference level properties for those sites. Users with businessadmin privileges as described in "User Management" can configure sites with imtctl and access the Sites tab to monitor sites. See Chapter 9, "Web Conferencing Sites" for details about creating and using sites.
Oracle Real-Time Collaboration provides various reporting capabilities, including e-mailed reports and usage trend information available within the Oracle Web Conferencing Application. Some aspects of these features require post-installation configuration, such as including sender's and receiver's e-mail addresses. See Chapter 4, "Post-Installation" for details about the properties that must be configured.
Anyone with the businessadmin or businessmonitor role as described in "User Management" can see the Reports tab to view reports. See Chapter 8, "Reports" for details about Web Conferencing reports.
