| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.1) Part Number B14497-02 |
|
|
View PDF |
| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.1) Part Number B14497-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 Messaging and Notifications Components of Mobile Collaboration Deployment".
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 and 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, 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 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 Application 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 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 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 Application 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:Uses the agreed-upon communication protocol between the Mobile Collaboration Server and the SMS aggregator's server infrastructure.
Listens to the SMS traffic from the SMS aggregator.
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
Figure 2-4 illustrates the deployment architecture for Oracle Mobile Push Mail. The following steps illustrates the data flow for Oracle Mobile Push Mail.
The Oracle Mobile Push Mail client program starts on a user's device and authenticates with the Oracle Mobile Push Mail Server.
Notes:
All commands from the Oracle Mobile Push Mail client to the Oracle Mobile Push Mail Server are sent through the HTTPS/HTTP channel.
The username and device ID are automatically provisioned to the device during the OTA (over-the-air) installation process. The end user enters only the password.
The 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 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.
WARNING:
Because some features of the Push Mail Server may not function properly if the push mail traffic is routed through Oracle Webcache, you must route push mail traffic directly through the Oracle HTTP Server to the OC4J_Wireless JVM. To implement this architecture in the single- and multi-box deployment scenarios discussed in the Oracle Collaboration Suite Deployment Guide. See also "Configuring Oracle Mobile Push Mail and the Oracle Mobile Device Management Access Points".
Figure 2-4 Deployment Architecture for Oracle Mobile Push Mail
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. 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
