Administration Guide
This chapter provides information on the architecture and concepts that are useful for understanding the high-level ideas and terminology used with the WebLogic Personal Messaging API.
This chapter contains the following sections:
Figure 2-1 shows the various components of the WebLogic Personal Messaging API and what JAR
file the classes for these components are located in. When setting up the WebLogic Personal Messaging API to run within your Java application, the appropriate JAR
files must be placed on the CLASSPATH
as shown in the diagram. For example, for an application that requires connectivity to Exchange, the collab.jar
and collab_exchange.jar
files should both be in the CLASSPATH
. In lieu of selecting multiple individual JAR
files, there is a JAR
file called collab_all.jar
that contains all schemas, providers, and supporting classes.
Note: If the collab_all.jar
file is used, no other WebLogic Personal Messaging API JAR files need to be placed on the CLASSPATH
.
Note: Include the license.bea
file in the CLASSPATH
.
Figure 2-1 Personal Messaging API Software Components
The schema is an insulating layer between the application and a specific provider implementation. For example, because an application uses the groupware
schema, rather than an Exchange implementation directly, the same application can be used with Domino simply by switching provider implementations.
Your Java application uses a schema to access functionality and can leverage the groupware
schema, exchange
schema, or domino
schemas—or some combination of all of them. The schema is backed by a provider implementation, which is chosen when the programmer creates a com.compoze.collab.ISession
using the API. For more information on providers, see Providers.
Schemas consist of a hierarchy of abstract items and containers. Each item contains one or more properties, which are key/value pairs. Containers hold both items and other containers. Root containers are obtained available from ISession
, which is instantiated with a particular service provider. Specific item classes exist for the different entities in the schema. For example, the groupware
schema contains item classes for tasks, appointments, contacts and mail messages. Regardless of what item class you are using, the programming interface for manipulating its properties it is the same.
The main schemas are the groupware
, exchange
and domino
schemas. All inherit from the messaging
schema. To say that a schema inherits from another schema means that it has all of the same item classes and container classes, plus additional ones. Providers may also contain their own schema extensions. For example, the exchange
schema extends the groupware
schema to add Exchange-specific groupware functionality. The domino
schema extends the groupware
schema to add Domino-specific groupware functionality.
Figure 2-2 shows several of the schema-related API classes and their functions.
Figure 2-2 Schema-Related API Classes
The packages and classes for the groupware
and messaging
schemas are found in the collab.jar
file. Schema definitions are stored in the collab.xml
file. For more information, see The collab.xml File.
A provider is an implementation of one or more schemas that makes that schema interact with a specific back-end system. For example, the Exchange/MAPI Provider is an implementation of the groupware
schema that connects to a MS Exchange server.
Providers often implement extended schemas for access to the higher-level schemas that the extended schema implements. For example, the exchange schema contains additional item classes that are MS Exchange specific and thus not supported in the groupware schema. However, because the exchange schema extends the groupware schema, the Exchange/MAPI Provider still fully supports the groupware schema.
Table 2-1 lists the available providers. For more information, see Exchange Providers.
Groupware system: Lotus Domino For more information, see Domino Provider |
|
Groupware system: Microsoft Exchange Extends schema: For more information, see Exchange/MAPI Provider. |
|
Extends schema: Internal Name: For more information, see Exchange/WebDAV Provider. |
Note: There are multiple providers that support connectivity to MS Exchange, see Exchange Providers on page 3-1.
Each provider has an internal name, which is a string representation of that provider. When viewing the output log and the collab.xml
file, you will encounter references to the provider by internal name.
Each WebLogic Personal Messaging API JAR
file that contains providers and schemas contains a collab.xml
file in the META-INF
directory. The collab.xml
file contains sections for schemas and providers depending on what the JAR
file contains.
For the accurate information on what configuration information is stored in the collab.xml
file, see the collab.dtd
file in the META-INF
directory of collab.jar
. This Document Type Definition (DTD) is used for collab.xml
validation and has comments that describe each of the nodes in a collab.xml
file.
Note: Editing the collab.xml
file is not required to run the WebLogic Personal Messaging API.
The WebLogic Personal Messaging API version may be determined by executing any of the delivered JAR
files, such as collab.jar
or collab_all.jar
. Alternatively, run the class com.compoze.collab.version.Version
. The version of the product in the form X.Y.Z
will be printed to System.out
and displayed in a Swing dialog. For maximum compatibility, all versions of the JAR
files should be the same or c
ollab_all.jar
should be used.
In production environments, the WebLogic Personal Messaging API can run in a virtual machine with the Java security manager enabled. The code in Listing 2-1 contains a section for java.policy
(or similar) is the minimum needed to run.
Listing 2-1 Sample Code for java.policy
// WebDAV, MAPI Remote and Domino providers all need either or both of these,
depending on whether SSL is used or not
permission java.net.SocketPermission "*:80", "connect";
permission java.net.SocketPermission "*:443", "connect";