![]() ![]() ![]() ![]() ![]() ![]() |
This chapter describes the different methods of Microsoft Exchange connectivity offered by the WebLogic Portlets for Groupware Integration.
Note: | This chapter is applicable only if you are running Microsoft Exchange 2000 or 2003 |
The WebLogic Portlets for Groupware Integration offers two separate methods for connectivity to Microsoft Exchange. Your decision on which provider to use may be affected by performance, latency, and functionality requirements for application. With a few exceptions, the portlets can be used in the same way regardless of which provider you choose. See the following table for more detail on both methods.
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:
The WebLogic Exchange Service uses the low-level MAPI interfaces to Microsoft Exchange to provide groupware functionality. Much of the complexity of Exchange groupware functionality is exposed in MAPI but is implemented in the Outlook client. The WebLogic Exchange Service hides these details while making the portlets appear as though it were an Outlook client to the Exchange server.
The WebLogic Exchange Service provides connectivity to Exchange as an intermediary between WebLogic Portal and the MAPI subsystem. Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service.
The WebLogic Exchange Service is implemented using the MAPI subsystem 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 subsystem.
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 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 the WebLogic 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 the Exchange server as possible.
If you have Microsoft 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.
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 WebLogic Exchange Service 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 1 GB of RAM. Minimum configuration for low-load configurations is 128 MB of RAM.
Refer to the BEA WebLogic Exchange Service Setup Guide for more information on installing and configuring the WebLogic Exchange Service.
As shown in Figure 3-2, connecting to Microsoft Exchange via WebDAV uses the WebDAV protocol directly against the Microsoft Exchange server to provide groupware functionality. This allows the WebLogic Portlets for Groupware Integration and no MAPI subsystem installation or intermediary service machine, regardless of which operating system your applications runs on.
Much of the complexity of MS 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.
The WebLogic Portlets for Groupware Integration connect directly to the OWA-enabled MS 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 MS 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 MS 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.
A guideline is approximately 250 active WebDAV users on a CPU running the WebLogic Portlets (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 1 GB of RAM to run the virtual machine with the WebDAV provider. Low load configurations can get away with 128 MB of RAM.
You may find that a particular message or folder is causing you problems. In this case, it is possible to export the original messages for import in order for BEA support to reproduce the problem. To do this:
.pst
).
After exporting the PST file, place this in a zip file 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.
![]() ![]() ![]() |