| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.2) Part Number B25478-02 |
|
|
View PDF |
| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.2) Part Number B25478-02 |
|
|
View PDF |
This chapter, through the following sections, describes Oracle Mobile Collaboration deployment scenarios.
Oracle Collaboration Suite 10g provides users with continuous access to enterprise collaboration data such as e-mail, voicemail, calendar, address book, online files, and employee directory, from any location and from any mobile device. Providing such universal, network- and device-agnostic access to corporate content requires that the Mobile Collaboration Server component be deployed and configured correctly. For more information, see "The Deployment Messaging and Notifications Components".
This chapter describes the deployment architecture and data flows for Mobile Browser Access, Oracle Mobile Text Access through e-mail and SMS, Oracle Voice Access, and mobile notifications for Messaging and for Oracle Collaboration Suite 10g Calendar. In addition, this chapter describes the deployment architecture and data flows for Oracle Mobile Data Sync andOracle Mobile Push Mail. For information on such deployment scenarios as the single- box, multi-box and high-availability installations of Oracle Collaboration Suite 10g Mobile Collaboration, refer to Oracle Collaboration Suite Deployment Guide
The OracleAS Wireless component of the Oracle Mobile Collaboration Server (Figure 2-1) provides the following messaging and notification functions for the Oracle Mobile Collaboration Server:
Messaging Server
The Messaging Server is the component that delivers messages and notifications by interfacing with the Async Listener, Notification Engine and a messaging gateway to deliver messages. Although this component ships configured to use the Oracle-hosted online push service (http://messenger.oracle.com/xms/webservices), you can configure the Messaging Server to use other voice, SMS, e-mail, fax, or SMS gateways as needed.
The Messaging Server is the enabling component for Oracle Mobile Text Access (described in "Deploying Mobile Text Access Through E-Mail" and "Deploying Oracle Mobile Text Access Through SMS") and for mobile notifications as described in "Deploying Mobile Notifications for E-Mail", "Deploying Mobile Notifications for Oracle Collaboration Suite 10g Calendar", and "Deploying Oracle Voice Access".
Async Listener
The Async Listener, a client of the Messaging Server, interprets and processes the e-mail and SMS requests. You must configure this component to enable Oracle Mobile Text Access. For more information on configuring the Async Listener, see "Configuring Mobile Text Access".
Notification Engine
The Notification Engine, a client of the Messaging Server, processes the notifications dequeued from the Notification Event Collector and sends them to the Messaging Server for ultimate delivery to users. The roles of the Notification Engine and Notification Event Collector are described in "Deploying Mobile Notifications for Oracle Collaboration Suite 10g Calendar".
Notification Event Collector
Notification Event Collector acquires the notifications from the various OCS content sources (such as Calendar) and then dequeues them to the Notification Engine.
Figure 2-1 The Oracle Application Server Wireless Mobile Access Components
This section describes the following:
Mobile Browser Access enables access to corporate collaboration data over any wireless network from mobile devices that support browsers for such markup languages as HTML, XHTML, WML, and HDML. Mobile Browser Access communicates with all content sources (which are defined in the Identity Management Service Registry) to format and render the content based on the device type (user-agent). Mobile Browser Access does not require deployment or configuration, because the content sources for all of the services available on the Mobile Collaboration Server for browser access are configured out of the box in the Identity Management service registry upon successful installation of Oracle Collaboration Suite. For more information on the Service Registry, see Oracle Internet Directory Administrator's Guide.
Users retrieve corporate data by sending an e-mail to the Oracle Collaboration Server. They in turn receive a text response containing the requested data. Figure 2-2 shows the deployment for Mobile Text Access through e-mail using a two-tier architecture, with the Intranet tier containing the metadata repository, as well as the content source repositories for Oracle Collaboration 10g Calendar, Content Services, Mail, and Search. The Applications tier (separated by a DMZ firewall and load balancer) houses the messaging gateway, the Oracle Mobile Collaboration Server and Web listeners. The listener monitors requests from devices (located outside the router, external firewall and load balancer) and then notifies Oracle Mobile Collaboration (and underlying OracleAS Wireless Server), which mines the content sources and sends the response data to the messaging gateway. The messaging gateway sends the reply to the requesting device through the public Internet.
To deploy Mobile Text Access through e-mail, you must configure the Messaging Server and Async Listener components, create a valid e-mail account for incoming text access requests, and also set up a messaging gateway. For more information, see "Configuring the E-Mail Access Point".
Figure 2-2 Deployment Architecture for Implementing Mobile Text Access Through E-Mail
The following steps illustrate the data flow for accessing the Oracle Collaboration Suite through e-mail.
A user sends an e-mail message to an e-mail account, which is configured as the Async Listener e-mail access point. (For more information, see "Configuring the E-Mail Access Point".) The contents of the e-mail message include the short name commands which request the Oracle Collaboration Suite services.
The SMTP server receives the e-mail message and places it in the mail store.
The Messaging Server retrieves the e-mail message through IMAP requests to the mail server (the IMAP Listener).
The Messaging Server hands the e-mail's requests to the Async Listener, which interprets the e-mail's requests and then retrieves the requested content from the content sources located on the intranet behind a DMZ firewall and a load balancer. The Async Listener sends the retrieved contents to the Messaging Server.
The Messaging Server pushes the content to a messaging gateway which is either hosted in-house or by a third party.
The messaging gateway sends the sends the retrieved content to the end user.
In Mobile Text Access through SMS, users retrieve corporate data by sending a short message (SMS) to the Oracle Mobile Collaboration Server. Figure 2-3 illustrates how the deployment architecture enables the Oracle Mobile Collaboration Server to both receive the user request and send the appropriate text response. The following steps illustrate the data flow for accessing the Oracle Collaboration Suite through SMS:
On the public Internet, a user sends an SMS message to the SMS account, which is the SMS access number attained from the SMS provider. (For more information, see "Configuring the SMS Access Point".) The contents of the SMS message include the short name commands (also known as ASK commands) that request the Oracle Collaboration Suite services.
The wireless (or mobile) carrier receives the SMS message and then conveys it to the SMS aggregator.
The SMS aggregator pushes the SMS message to the Oracle Mobile Collaboration Server, which is located on the Applications tier and separated from the public Internet by a router, external firewall, and load balancer.
The Messaging Server hands the SMS requests to the Async Listener, which interprets the SMS requests and then retrieves the requested content from the content sources, located on the intranet behind a DMZ firewall and a load balancer. The Async Listener sends the retrieved contents to the Messaging Server.
The Messaging Server sends the retrieved content as a text response to the SMS aggregator.
|
Notes: The driver running on the Messaging Server:
|
The SMS aggregator sends the retrieved content to the wireless carrier.
The wireless carrier sends the retrieved content to the user device.
Deploying Mobile Text Access through SMS requires that you obtain a service-level agreement (SLA) with a telecommunications company or an SMS aggregator for forwarding the SMS content to the Mobile Collaboration Server. In addition, you must also configure the OracleAS Wireless Messaging Server and Async Listener components and also set up a driver appropriate to the SMS provider or aggregator's infrastructure. For more information, see "Configuring the SMS Access Point".
Figure 2-3 Deployment Architecture for Mobile Text Access Though SMS
You can deploy Oracle Mobile Push Mail to a non-default port. This section describes how to deploy Oracle Mobile Push Mail.
Deploying Oracle Mobile Push Mail requires the following software and hardware:
An Applications tier host name – The hostname on which the Oracle Mobile Collaboration Server is installed.
An Applications tier Web Cache Port Number– The port number used by the Web Cache component of Oracle Collaboration Suite to listen for incoming requests. This number is identified by the Port directive in the Oracle HTTP Server configuration file (httpd.conf).
An Applications tier Oracle HTTP Server Listener Port Number – The port number on which Oracle HTTP Server listens for incoming events. This number is identified by the Listen directive in httpd.conf.
|
Note: You can also obtain the port information from the Oracle_Home/install/portlists.ini file located on the Applications tier. |
Because some features of the Push Mail Server may not function properly if the push mail traffic is routed through Oracle Web Cache, you must route push mail traffic directly through the Oracle HTTP Server to the OC4J_Wireless JVM. Based on this recommendation, the architecture can be implemented as follows:
A single box installation with no hardware load balancer – With this configuration, the published URL for the Oracle Mobile Push Mail server must be the URL on which the Oracle HTTP listener runs. For example:
https://<applications_host_name>:<application_oracle_HTTP_listener_port>/pushmailMgr
A multi-box installation with no hardware load balancer – With this configuration, the published URL for the Oracle Mobile Push Mail server must be the URL on which the Oracle HTTP listener runs. For example:
https://<applications_host_name>:<application_oracle_HTTP_listener_port>/pushmailMgr
A multi-box installation with a hardware load balancer – With this configuration, all of the push mail data traffic must be routed from the hardware load balancer straight to the Oracle HTTP listener, bypassing the Web Cache listener.
See Oracle Collaboration Suite Deployment Guide for information on the single- and multi-box deployment scenarios. See also "Configuring Oracle Mobile Push Mail and the Oracle Mobile Device Management Access Points".
Figure 2-4 illustrates the deployment architecture for Oracle Mobile Push Mail.
Figure 2-4 Deployment Architecture for Oracle Mobile Push Mail
You must deploy Oracle Mobile Push Mail to a non-default port by changing the default port number for Oracle Mobile Push Mail. This not only enables compliance with I.T. network standards and conventions, but also provides the flexibility to change the ports used to access Oracle Mobile Push Mail to satisfy customer requirements.
You must first complete the default installation of Oracle Collaboration Suite. The installation can be a single-box installation or a distributed (multi-box) installation with Oracle Mobile Collaboration running on a single Applications tier.
|
Note: Oracle Mobile Collaboration must be installed within a DMZ, behind a hardware load balancer. To ensure a secure environment, the hardware load balancer must encrypt and decrypt SSL. |
Table 2-1 describes the port and hostname values and the value formats used as examples to describe this deployment option. These values serve as examples only.
Table 2-1 Example Values
| Description | Value |
|---|---|
|
Applications tier hostname |
|
|
Applications tier Oracle HTTP Server port number (Web Cache) |
7778 |
|
Applications tier Oracle HTTP Server Listener port number |
7779 |
|
External hostname for Oracle Collaboration Suite |
|
|
External Port for Oracle Collaboration Suite |
4443 |
|
External Port for Oracle Mobile Push Mail |
443 |
To deploy Oracle Mobile Push Mail on a non-default port:
Ensure that the routing pool of the hardware load balancer routes traffic from the Internet as follows:
Any incoming request from the Internet on https://collabsuite_companyname.com:4443 is routed to http://pushmail.companyname.com:7778 (Web Cache) after decryption.
Any incoming request from the Internet on https://pushmail_external.companyname.com:443 is routed to http://pushmail.companyname.com:7779 (Oracle HTTP Server) after decryption.
Edit the following parameters in the pimap.properties file (located at ORACLE_HOME/apps/wireless/server/classes/oracle/panama/imap/config on the Applications tier where Oracle Mobile Collaboration resides) to reflect the new external hostname and port number:
pimap.external.URL
setup.external.URL
push.external.URL
dm.external.URL
pimap.udp.listener.server
Example 2-1 illustrates the pimap.properties file before these parameters are updated to reflect the new hostname and port.
Example 2-1 The pimap.properties File Before Updating
pimap.external.URL=http://pushmail.companyname.com:7779/mobileocs/pushMailServer setup.external.URL=http://pushmail.companyname.com:7779/mobileocs/setup push.external.URL=http://pushmail.companyname.com:7779/mobileocs/push dm.external.URL=http://pushmail.companyname.com:7779/mobileocs
Example 2-2 illustrates the pimpap.properties file after these parameters have been changed to reflect the new hostname and port.
Example 2-2 The Updated pimap.properties File
pimap.external.URL=https://pushmail-external.companyname.com/mobileocs/pushMailServer setup.external.URL=https://pushmail-external.companyname.com/mobileocs/setup push.external.URL=https://pushmail-external.companyname.com/mobileocs/push dm.external.URL=https://pushmail-external.companyname.com/mobileocs
Restart the OC4J_Wireless process on the Applications tier on which Oracle Mobile Collaboration is located using the following command:
opmnctl restartproc process-type=OC4J_Wireless
Edit the Oracle HTTP Server configuration file (httpd.conf) to include a new VirtualHost (virtual hostname) directive for the new external hostname and port number. Example 2-3 illustrates the VirtualHost directive for this file, which is located at ORACLE_HOME/Apache/Apache/conf/httpd.conf on the Appications tier where Oracle Mobile Collaboration resides.
Example 2-3 The VirtualHost Directive of httpd.conf
Listen pushmail-external.companyname.com_ip:80
<VirtualHost pushmail-external.companyname.com_ip:80>
ServerName pushmail-external.companyname.com_ip:80
Port 80
<Directory /mid-tier/oracle_home/Apache/Apache/htdocs>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
For Unix and Linux systems, ports under 1024 are privileged ports and require super-user privileges. By default, Oracle HTTP Server runs as a non-root user (that is, as the user who installed the Oracle Application Server). If you change the Oracle Application Server HTTP listen port to a value of less than 1024, then you must enable Oracle Application Server to run as root as follows:
Log in as root.
Run the following commands in the Applications tier Oracle home:
cd ORACLE_HOME/Apache/Apache/bin chown root .apachectl chmod 6750 .apachectl
Restart Oracle HTTP Server using the following command:
opmnctl restartproc ias-component=HTTP_Server
With the configuration complete, mobile users can access the Oracle Mobile Push Mail Server through:
https://pushmail-external.companyname.com/mobileocs/pushMailServer
and Mobile Browser Access through:
https://pushmail-external.companyname.com/ptg/rm
The following steps illustrates the data flow for Oracle Mobile Push Mail.
The Mobile Push Mail client program starts on a user's device and authenticates with the Oracle Mobile Push Mail Server.
|
Notes:
|
The Oracle Mobile Push Mail Command Processor receives the LOGIN command. The LOGIN command is then relayed to the back end IMAP server for authentication.
|
Note: The LOGIN command sent to the back end also carries the current view filter that is applied to the inbox. Because filtering occurs only on the Oracle IMAP Server, there is no impact on performance. |
Once the LOGIN is successful, the Mobile Push Mail client then synchronizes its inbox with that of the server. During this process, one known as state comparison sync, any actions performed by the end user when they are not connected to the server are uploaded to the Oracle Mobile Push Mail Server.
After synchronization ends, the Mobile Push Mail client starts the Push mode, where it sends an IDLE command to the Oracle Mobile Push Mail Server. The IDLE command is relays back to the IMAP Server, so that the Mobile Push Mail client is immediately informed of changes to messages in the inbox (such as creating, deleting or reading messages).
When an event occurs on the Oracle Mobile Push Mail Server, the event is then sent to the Mobile Push Mail client which performs the appropriate action. For a new message event, the Mobile Push Mail client must contact the server to fetch the message body. For delete message or change flag events, the Mobile Push Mail client must update its own message store with the new flags.
If the end user performs actions on the messages stored in the device, then these actions are then sent to the Oracle Mobile Push Mail Server. The events are either sent immediately (when there is an active connection to the Oracle Mobile Push Mail Server) or cached and then sent later. New messages are sent to the Oracle Mobile Push Mail Server using the XDELIVER PIMAP command. The Oracle Mobile Push Mail Server then contacts the SMTP server to deliver the message. After the Mobile Push Mail client sends changes to the Oracle Mobile Push Server, it returns to the IDLE state.
Figure 2-5 illustrates the typical deployment architecture for mobile notifications for e-mail.
Figure 2-5 Deployment Architecture for Mobile Notifications
The following steps illustrate the data flow for mobile notifications through e-mail.
A user sends a voicemail or fax message that triggers notification preferences set by another user.
|
Note: Users create messaging notification rules from the Mobile Preferences page (Figure 3-1) of the Oracle Collaboration Suite portal (ptg/rm). The Mail server maintains the notification rules. |
The notification events are enqueued in a queue in the mail database.
The Notification Event Collector running on the Oracle Mobile Collaboration Server continuously de-queues these events to the Notification Engine, which processes the notification event by looking up the end user's preferences (such as the device notification address) and then hands over the event to the Messaging Server.
The Messaging Server delivers the notification to the end user's device by pushing the notifications through a messaging gateway (either hosted in-house or by a third party)
The messaging gateway sends the notification to the user's device.
See also "Configuring the Messaging Server for Notifications".
Users receive Oracle Collaboration Suite 10g Calendar-related notifications through SMS, e-mail, voice messages, or fax messages. These messages alert users to such events as new meetings, updated meeting information, or cancelled meetings. Figure 2-6 illustrates the deployment architecture for Oracle Calendar notifications.
Figure 2-6 Deployment Architecture for Oracle Calendar Notifications
The following steps describe the data flow for Oracle Calendar notifications.
Users enable (or disable) notifications for Oracle Calendar.
The Calendar Server tracks the users' notification preferences for Oracle Calendar.
The Calendar Server, which uses the Oracle Mobile Collaboration Server's Notification Engine for processing and delivery of Oracle Calendar notifications, pushes the notification directly to the Notification Event Collector using a TCP connection on a configured port. By default, the Notification Event Collector listens on Port 9000 for incoming notification events from the Calendar Server.
The Notification Event Collector running on the Oracle Mobile Collaboration Server continuously de-queues these events to the Notification Engine. The Notification Engine processes the notification event by looking up the end user's preferences (such as the device notification address) and then hands over the event to the Messaging Server. The Messaging Server delivers the notification to the end user's device by pushing the notifications through a messaging gateway (either hosted in-house or by a third party).
The messaging gateway sends the notification to the user.
See also "Configuring the Messaging Server for Notifications".
Figure 2-7 illustrates the deployment architecture for Oracle Voice Access.
Figure 2-7 Deployment Architecture for Oracle Voice Access
Deploying Oracle Voice Access to the Oracle Collaboration Suite requires a VoiceXML gateway which has a telephony interface, an ASR (Automatic Speech Recognition) server, a VoiceXML Interpreter, and a TTS (Text-to-Speech) server (illustrated in Figure 2-8).
Figure 2-8 Required Components for Deploying Oracle Voice Access
The following steps illustrate the data flow for Oracle Voice Access (illustrated in Figure 2-9).
A Oracle Collaboration Suite user calls the voice access number to the Oracle Collaboration Suite. The voice gateway is then contacted. For more information on setting the voice access number, see "Configuring Oracle Voice Access".
Based on the number called, the voice gateway selects the appropriate URL to contact the login service.
An HTTP request is sent to the Oracle Mobile Collaboration Server, asking for the initial login page. The Oracle Mobile Collaboration Server detects that the request originated from a voice device and subsequently contacts the Single Sign-On server.
The Single Sign-On server sends back a login page in presentation-independent XML.
The Oracle Mobile Collaboration Server then translates the login page to VoiceXML, which it then sends to the voice gateway in an HTTP response.
The voice gateway processes the VoiceXML and prompts the caller for an account number.
The caller says the account number and then presses # on the keypad.
The voice gateway then prompts the caller for a PIN.
The caller says the PIN and then presses # on the keypad.
The voice gateway submits the information back to the Oracle Mobile Collaboration Server as an HTTP server request.
The Oracle Mobile Collaboration Server collects the submitted credentials and contacts the Single Sign-On server to verify the credentials.
The Single Sign-On server contacts the Oracle Internet Directory (OID) and matches the submitted credentials with the user.
The Single Sign-On server signals the Oracle Mobile Collaboration Server that the user has been authenticated.
The Oracle Mobile Collaboration Server serves up the Voice Main Menu application in presentation-independent XML and then translates the page to VoiceXML.
The VoiceXML is sent back to the voice gateway as an HTTP response.
The voice gateway processes the VoiceXML and plays the Voice Main Menu for the caller.
Figure 2-9 The Network Flow for Oracle Voice Access
Figure 2-10 illustrates the data flow for Oracle Mobile Data Sync. The following steps illustrate the data flow.
A user initiates synchronization from the OMA-DS client (the client program for Oracle Mobile Data Sync) on the device (this client can be native to the device or from a third party).
The device initiates a data connection through the best channel available that is supported by this device (for example, cradle, Bluetooth, or GPRS). The channel can be different upon each sync.
The connection finds the Mobile Data Sync Server using the URL saved in the OMA-DS client settings.
The Mobile Data Sync Server checks for any valid previous sessions for the user. If any valid prior sessions exist, then the session begins with changes made since the last sync. If it finds no valid prior sessions, then a "slow sync session" begins, wherein the context for the user is built (or rebuilt).
The Mobile Data Sync Server receives data for both the device and the user account. For a "normal" session (that is, one where the Mobile Data Sync Server found a valid prior user session), the Mobile Data Sync Server receives the changed data from the last session. For the "slow sync" session (one where no prior user session was found), the Mobile Data Sync Server receives all data.
|
Note: The connection between the Mobile Data Sync Server and the Calendar Server goes through the firewall. |
The Mobile Data Sync Server performs conflict and ownership resolution. For the "normal" session, the Mobile Data Sync Server performs this task using the mapping tables; for the "slow sync" session, the Mobile Data Sync Server rebuilds the context through a matching heuristic.
Once the Mobile Data Sync Server completes the conflict and ownership resolution, the data is sent back to both the user device and the server account. The context is updated for use for the next sync.
Figure 2-10 Data Flow for Oracle Mobile Data Sync
