Administration Guide

Architecture and Concepts

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:

Software Components

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

Personal Messaging API Software Components

Schemas

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

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.

Providers

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.

Table 2-1 Providers

Provider	Description
Domino Provider	Groupware system: Lotus Domino Implements schema: `domino` Extends schema: `groupware` Internal Name: `domino` For more information, see Domino Provider
Exchange/MAPI Provider	Groupware system: Microsoft Exchange Implements schema: `mapi` Extends schema: `exchange`, `groupware` Internal Name: `exchange_mapi` For more information, see Exchange/MAPI Provider.
Exchange/WebDAV Provider	Groupware system: MS Exchange Implements schema: `webdav` Extends schema: `exchange`, `groupware` Internal Name: `exchange_webdav` 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.

The collab.xml File

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.

Determining the Version Number

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 collab_all.jar should be used.

Minimal Java Security Policy

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";