Administration Guide
|
 |
 |
|
 |
 |
Providers
The following providers are included with the WebLogic Personal Messaging API:
This chapter contains the following sections:
Exchange Providers
The Personal Messaging API offers two separate providers for connectivity to MS Exchange. Your decision on which provider to use may be affected by the need to support MS Exchange 5.5. In addition, consider the performance, latency and functionality requirements for your application. With a few exceptions, the exchange schema can be used in the same way regardless of which provider you choose. See Table 3-1 for more detail on both Exchange Providers.
Note: In some cases, the optimal way to decide which provider is better in your environment is to test both with your application and evaluate the IT requirements of your deployment against the results of that test.
This section contains the following topics:
Exchange/MAPI Provider
The Exchange/MAPI Provider offers an implementation of the groupware schema (and an extended exchange schema) for interacting with MS Exchange. The Exchange/MAPI Provider uses the low-level MAPI interfaces to MS Exchange to provide groupware functionality. These low level interfaces offer the best potential performance when interacting with MS Exchange. Much of the complexity of Exchange groupware functionality is exposed in MAPI but is implemented in the Outlook client. The Exchange/MAPI Provider hides these details while making the Java application appear as though it were an Outlook client to the Exchange server.
This section contains the following topics:
WebLogic Exchange Service
To use the Exchange/MAPI Provider, you must install and configure the WebLogic Exchange Service. The WebLogic Exchange Service provides connectivity to Exchange as an intermediary between Java and the MAPI subsystem.
Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service.
Figure 3-1 Configure the WebLogic Exchange Service to Use the Exchange/MAPI Provider
Connectivity to Exchange
The WebLogic Exchange Service is implemented using the MAPI subsytem to communicate with an Exchange server. Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service and the MAPI subsytem.
Network/Firewall Requirements
HTTP or HTTPS traffic must be able to pass between the Java application machine (where the API is running) and the WebLogic Exchange Service machine. This could be port 80, port 443, or whatever port you have chosen for your WebLogic Exchange Service. The network connection for the traffic between the application and service machine does not require as low a latency as the MSRPC connection. 50-100 ms ping times should be tolerable given reasonable bandwidth.
The network link between the Java application API and theWebLogic Exchange Service machine can be over wide area networks to traverse larger distances between your application and the Exchange server. However, the WebLogic Exchange Service machine should be as close to Exchange as possible. If you have Exchange servers in different locations, try to group them together and place the WebLogic Exchange Service machines as close as possible on the network to each cluster of Exchange servers.
Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service.
Sizing Information
A guideline is approximately 250 active users per machine running the WebLogic Exchange Service. Potentially more users than that could have sessions open on the machine, but a limit of around 250 in-use sessions exists for the process running MAPI. If more than 250 sessions are open, the Exchange/MAPI Provider closes and opens any underlying sessions to Exchange as needed, but performance will suffer if many of these opens and closes need to occur.
Additional processors on the WebLogic Exchange Service machine will minimize response time degradation as more simultaneous active users are added to the machine, but there will be a point of diminishing returns. Testing suggests that a dual processor machine is the best combination of scalability vs. cost when running the WebLogic Exchange Service. Using a faster machine for the WebLogic Exchange Service will simply allow the MAPI/RPCs with Exchange to occur faster and the WebLogic Exchange Service to run faster; however at a certain point you will be limited by the speed with which the Exchange server can respond to your MAPI/RPC requests.
A recommended configuration for a fully loaded WebLogic Exchange Service machine is one GByte of RAM. Minimum configuration for low-load configurations is 128 MBytes of RAM.
Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service.
Exchange/WebDAV Provider
As shown in Figure 3-2, the Exchange/WebDAV Provider uses the WebDAV protocol directly against the Exchange server to provide groupware functionality. This allows the Java application and no MAPI subsystem installation or intermediary service machine, regardless of which operating system your applications runs on. Much of the complexity of Exchange groupware functionality is actually exposed in the published WebDAV protocol, but is implemented in the Outlook client. The Exchange/WebDAV Provider hides these details while interacting with Exchange using the same protocol as Outlook Web Access 2000 or 2003.
Figure 3-2 The Exchange/WebDAV Provider
Network/Firewall Requirements
The Java application connects directly to the OWA-enabled Exchange server using the HTTP or HTTPS protocol over any TCP port (typically the standard 80 or 443). The only firewall requirement is that traffic on whichever port is to be used may pass between the application and the Exchange server.
For more information on network requirements you may wish to see the Outlook Web Access (OWA) Planning Chapter available at: http://www.microsoft.com/technet/prodtechnol/exchange/2000/deploy/upgrademigrate/series/planningguide/p_10_tt1.mspx. Additionally, there are many other resources available on Microsoft's site regarding OWA deployment and scalability.
One important note regarding WebDAV performance and networking is that when connecting to Exchange 2000 you will experience a delay associated with TCP delayed acknowledgements that can hinder the performance of your application. Windows waits 200 milliseconds to acknowledge the small TCP packets that come from Exchange 2000 server. This can be fixed by applying the workaround in the following Microsoft article: http://support.microsoft.com/default.aspx?scid=kb;en-us;321098.
Sizing Information
A guideline is approximately 250 active WebDAV users on a CPU running the Java application (an active user defined not as a thread, but as a user using an application with typical user delays between each request). Unlike MAPI, there is no per-process limit. Adding additional CPUs to the hardware will increase the scalability of the application, with diminishing returns. A potential guideline is going from one to two CPUs increases the number of users that could be supported by about 75%. Going from two to four CPUs increased the two CPU number by about 50%. However, each application and environment may be different.
A fully loaded machine should need no more than one GByte of RAM to run the virtual machine with the WebDAV provider. Low load configurations can get away with 128 MBytes of RAM.
Reporting Problems with Exchange Messages
You might find that a particular message or folder is causing problems. In this case, it is possible to export the original messages for support to import in order to reproduce the problem.
Perform the following steps to export the messages:
It is easiest to export an entire folder (such as the calendar folder), but you may also click Filter and restrict what is exported by date range, subject, attendees, created time, etc. Be sure that the offending messages get included by the filter you have chosen. Provide this file to support along with a small readme.txt file that explains the problem with the message/s and any filter that was used for the export in step 5 .
Domino Provider
The WebLogic Domino Service leverages native Domino Service to expose Lotus Domino groupware functionality from the Domino mail database. The WebLogic Domino Service machine acts as an intermediary between the Java API and Lotus Domino, as shown in Figure 3-3.
See the BEA WebLogic Domino Service Setup Guide for more information on installing and configuring the WebLogic Domino Service.
Figure 3-3 The WebLogic Domino Service Machine Acts as an Intermediary Between the Java API and Lotus Domino
This section contains the following topics:
Connectivity to Domino
The WebLogic Domino Service is implemented using a combination of Notes RPC and Notes DSAPI and runs within Lotus Domino as part of the HTTP task. The details of this do not need to be understood by the application programmer, but this is the reason the Lotus Domino install is a prerequisite of the installation. This is where Notes RPC and the Notes DSAPI filter for Domino are obtained.
Network/Firewall Requirements
The WebLogic Domino Service must be located on a machine running Lotus Domino that is part of the same Notes Domain as the Domino server to access. It is possible to put the WebLogic Domino Service on an existing Domino server, but be aware of the additional processor and memory burden that will be placed on Domino.
HTTP traffic must be able to pass between the Java client and the WebLogic Domino Service. Traversing an HTTP proxy is OK as long as it is able to pass the POST requests used by the XML protocol. Although a high bandwidth, low-latency connection will improve performance, the protocol has been designed to reduce the number of round trips made on the network. Therefore, packet round trip times of 50-100ms should be tolerable for the application. The amount of bandwidth required will depend on the number of users simultaneously using the application. Each user may consume roughly 1K/sec. on average, with this number increasingly dramatically if users do a lot of work with large file attachments.
Notes RPC traffic must be able to pass between the WebLogic Domino Service and Lotus Domino. Notes RPC requires TCP port 1352 to be open. The network connection for this Notes RPC traffic must have a low latency (less than 10 milliseconds, and preferably a 100 megabit LAN with less then one millisecond response times). Round trips are made over the network for each Notes RPC, therefore the WebLogic Domino Service machine must be located as close as possible to Domino on the network.
Sizing Information
A guideline is approximately 250 active Domino users on a CPU running the Java application (an active user defined not as a thread, but as a user using an application with typical user delays between each request). Adding additional CPUs to the hardware will increase the scalability of the application, with diminishing returns. A potential guideline is going from one to two CPUs increases the number of users that could be supported by about 75%. Going from two to four CPUs increased the two CPU number by about 50%. However, each application and environment may be different.
A fully loaded machine should need no more than one GByte of RAM to run the virtual machine with the Domino provider. Low load configurations can get away with 128 MBytes of RAM.
