Novell is now a part of Micro Focus

GroupWise 5 Architecture Overview

Articles and Tips: article

GROUPWISE 5
DEVELOPMENT TEAM

01 Mar 1997


Novell's GroupWise 5 features a host of ways to enhance communication in a networked environment. This AppNote gives you a look under the hood of this powerful messaging architecture.

Introduction

Communication is essential for an organization to succeed. In today's business world, information can be communicated in various ways: by simple memos, sticky notes, and E-mail messages; or through large and complex documents, data, graphics, audio, and video files. But information is of little value if the way it is captured makes it difficult to organize, preserve, and access.

With Novell's GroupWise 5, the way information is captured is not an issue. The GroupWise architecture enhances communication by treating any electronically captured information­regardless of its format-as a basic element called a message. The key to making information valuable is making it easy to organize, share, preserve, and access when needed. That's why GroupWise is built on a messaging architecture.

This AppNote is intended to help communicate a basic understanding of the GroupWise messaging architecture. It describes the following components:

  • Administration and management

  • Message store system

  • Message transfer system

  • Gateways to foreign mail systems

  • GroupWise clients

  • Third-party interfaces

This information is adapted from an online document entitled "GroupWise 5: Architecture Overview" that can be found at http://www.novell.com/products/groupwise/encyclopedia/g5arch9.html

Overview of the GroupWise 5 Architecture

This discussion of the GroupWise 5 messaging architecture will focus on these basic components:

  • Administration and Management is responsible for directory and system administration tools to maintain the system address book and configuration information about your GroupWise installation.

  • The message store system is a series of post offices on the network. This system securely houses your information in the form of calendars, messages, documents, indexes, and folders.

  • The message transfer system is composed of message transfer agents (MTAs) which route messages between the post offices, gateways and directory agents.

  • GroupWise gateways seamlessly link your GroupWise system with non-GroupWise systems.

  • The GroupWise client provides the user interface to the services available in GroupWise.

  • Third-party interfaces consist of GroupWise implementations of industry standard APIs and GroupWise-specific APIs to support developers who extend the functionality of the GroupWise system.

GroupWise Administration and Management

GroupWise 5 uses Novell Directory Services (NDS) as its master directory. This means GroupWise can use data which has already been defined on the network, eliminating the need to enter common user information more than once. In addition, the administration user interface for GroupWise has been integrated with the NetWare Administrator (NWAdmin) utility. This gives users a single point of administration with an intuitive interface they are already familiar with.

A simple GroupWise system consists of a collection of data storage areas and agent programs. These play an important part in the administration of a GroupWise system.

Data Storage

There are two types of data in a GroupWise system: user data and administrator data. User data is generated by users when they create a message (mail, calendar, notes) or document. This data is stored at a GroupWise post office and moved through the system by the message transport subsystem (as will be explained later in this AppNote).

Administrator data defines the system's organizational structure, its users, and various grouping and naming objects. Configuration information for agent programs is also found in the administrator data. Although administrator data is created by an administrator, it is used by both users and administrators.

Together, all of the administrator data in a GroupWise system is referred to as the GroupWise Directory. A copy of the administrator data is stored at each post office and domain in the system.

Agents

GroupWise has a set of processes, called agents, which manipulate the system's data so it can be properly stored and accessed. There are three distinct types of agents:

  • The Post Office Agent (POA)

  • The Message Transfer Agent (MTA)

  • The Administration Agent (ADA)

Each agent is available on a variety of operating system platforms.

GroupWise Objects

The administration of GroupWise is concerned with manipulating various objects in the system. The table below describes each major object class present in a GroupWise system.


GroupWise Object Classes

Domain

Adirectory object that contains a set of postoffices, agents, and connectivity agents,and information about the way they link (passdata) to other domains in the system. A domainis the topmost object in the GroupWise objecthierarchy. An important attribute of thedomain is the path to the location of theadministrator data file.

PostOffice

Thelocation where user data is stored and accessed.An attribute of the post office object isthe path to the location of the message databasesand subdirectories. Another attribute identifiesthe users who access their data at the postoffice.

User

Aperson who is authorized to use the GroupWisesystem. Each user object has a distinguisheddirectory name and a GroupWise address whichconsists of the domain and post office theuser belongs to and the user's name.

Resource

Anon-user object which can be scheduled. Meetingrooms and equipment are examples of resourceobjects.

DistributionList

Alist of users and/or resources which receiveany message addressed to the distributionlist.

Library

Astorage location for documents with an associatedaccess list and profile attribute set. Anattribute defines the locations where thedocuments will be stored.

Agent

Aprocess that works on a specific set of GroupWisedata. The Post Office Agent delivers messagesto the user data store, the Message TransferAgent transports messages between domainsand post offices, and the AdministrationAgent replicates information between theGroupWise directory databases and NDS.

ConnectivityAgent

Anagent that provides conversion from GroupWiseto another message or communication protocol.

The NWAdmin utility is written to allow applications to "snap in" and extend the utility's user interface to support extensions to NDS. The GroupWise Admin snap-in adds the interface for all of the GroupWise object classes described above. It lets you edit GroupWise-specific objects and attributes in NDS and allows many GroupWise utilities to be accessed from the Tools menu in NWAdmin.

Directory Replication and Synchronization with NDS

The GroupWise Directory is secondary to the global Directory provided by NDS. In other words, a subset of the information available in NDS (the GroupWise address book information) is replicated to the GroupWise Directory and is kept synchronized with NDS. The fully replicated GroupWise Directory is built on an indexed database to provide fast lookups for the GroupWise address book.

In this model, NDS is the "master directory" and pertinent data is replicated from NDS to the GroupWise Directory. Data is never pushed from the GroupWise DirectoryCit is always read from NDS and written to GroupWise (see Figure 1).

Figure 1: Relationship between NDS and the GroupWise Directory.


Note: The ADA is configurable to synchronize objects from either the domain the databasebelongs to, specified domains, or a specified set of NDS Organizational Units.

There are two methods by which information is synchronized from NDS to a domain database. The first method is used when information is changed through the NWAdmin utility with the GroupWise Admin snap-in running. In this case, the GroupWise snap-in simultaneously writes changes to both NDS and to the domain database.

In the second method of synchronization, the Administration Agent (ADA) checks NDS for changes that have occurred but are not reflected in the GroupWise Directory. When a difference is detected, the data in NDS is used to update the GroupWise Directory. This method detects changes made by NetWare administration products that are not using GroupWise Admin snap-in. It also detects changes made by any application that writes directly to NDS.

When an ADA is configured, the administrator defines the domains in which the ADA will perform GroupWise and NDS synchronization. Only ADAs that run on platforms with NDS access are able to participate in the GroupWise-to-NDS synchronization, but all ADAs participate in the GroupWise-to-GroupWise synchronization.

Administrator data is propagated from a domain's GroupWise Directory database to the system's other domain and post office databases. This model allows for simultaneous operation of GroupWise 4.x and GroupWise 5 domains in an interconnected system. It also allows a GroupWise system to span NDS and non-NDS network nodes.

Because the GroupWise Directory is replicated around all of the domains and post offices in the GroupWise system, domains can exist on platforms where NDS is not available and still participate fully in the GroupWise system. This means that existing domains on NetWare 3.x servers and on other network operating system platforms can continue to function as they have in the past.

GroupWise Domain Types

A domain's type determines how it participates in the replication of GroupWise Directory data. A GroupWise domain can be a primary, secondary, external, or foreign domain. The function of these domain types are as follows:

  • There is only one primary domain in a GroupWise system. All directory updates must pass through this domain. Every change is sent to the primary domain from the originating domain. The primary domain then propagates the change to the rest of the system.

  • A secondary domain participates fully in the replication of administrator data, but all changes made at the secondary domain are sent to the primary domain for propagation.

  • An external domain is considered a separate GroupWise system. By default, it receives no administration data but can be configured to participate in a system's directory synchronization. The GroupWise administrator specifies which objects to replicate from the external domain, and the administrator of the external domain specifies which objects can be replicated.

  • A foreign domain is an external non-GroupWise system. GroupWise does not replicate foreign domains because directory format is unknown. Many foreign domains can participate in directory information exchange through a gateway to GroupWise. Foreign domains are provided so addresses from outside systems can be published in the GroupWise address book.

Other Administration Features

Other notable GroupWise administrator features include the following:

  • A new browser view called the GroupWise View is added by the GroupWise Admin snap­in to make it easy for an administrator to see only those objects which belong to the GroupWise system.

  • Several maintenance utilities are accessible through the GroupWise snap­in:

    • System Connection allows the administrator to switch between GroupWise systems.

    • Import/Export permits the importing and exporting of GroupWise and NDS data to an ASCII delimited file.

    • Migration provides the ability to push information from an existing GroupWise system into NDS and create the correct objects so the system can be administered in NWAdmin.

    • Link Tool allows the administrator to easily view and manage the definition of links between domains.

    • Database Management provides the ability to validate and maintain the administrative databases.

  • Administrative access control is available. In general, GroupWise administrative functions are intended to be executed from a privileged account and accessed through NWAdmin. A user's access to GroupWise administrative functions is determined by that user's NDS access rights to GroupWise objects and attributes.

  • Administration of GroupWise agents. These agents are defined as objects in NDS and are configured using NWAdmin. Each agent type has its own set of configuration settings. The configuration of the Administration Agent (ADA) defines the domains in which the agent is responsible for synchronizing GroupWise with NDS. Storing the configuration in NDS allows configuration files to be modified from the administration interface, eliminating the need to manually edit configuration files at each agent.

  • Monitoring of GroupWise agents. Each GroupWise agent is SNMP-enabled and the MADMAN MIB is supported to allow you to monitor GroupWise agents with any SNMP monitor program. GroupWise also provides an SNMP monitor that can be snapped into Novell's ManageWise. This monitor displays each GroupWise agent and information about its current operating status.

Migrating GroupWise 4.1 Systems to GroupWise 5

A GroupWise system is migrated from GroupWise 4 to GroupWise 5 one domain at a time. As each domain is migrated, the objects in that domain are moved into NDS and must be managed through the GroupWise Admin snap­in in NWAdmin. The first domain migrated must be the primary domain. You can continue to manage GroupWise 4.1 domains through the DOS-based AD.EXE program.

Once a domain is migrated, the GroupWise 5 MTA and ADA must be run on that domain. Each post office in the domain can be individually migrated as time permits. Once the post office is migrated, the client must be upgraded before people will be able to access the post office. Placing a new client at the post office will trigger the automatic upgrade when users enter GroupWise.

The Message Store System

The Message Store System in GroupWise provides secure, flexible, and reliable storage of your information in the form of calendars, messages, documents, indexes, and folders. It also performs several functions and services to help manage and share information, as explained in this section.

The Post Office

Information is stored on the network at a post office in the form of messages, documents, notes, calendars, personal address books, tasks, and group events. The message store system is comprised of one or many post offices configured on your network.

Physically, a post office is a directory structure on a network file server. The directory structure contains subdirectories, files, and databases. The post office directories contain user and message databases, the system address book, dictionaries, indexes, full text document indexes, document libraries, and language resource files. Each user is assigned a database that holds calendars, rules, personal address books, personal notes, folders, and preferences, as well as references to the location of shared items that are stored once.

The message databases contain messages, attachment references, status records, distribution lists and distributed query data. Large message attachments are stored in an array of compressed and encrypted subdirectories. Document databases and text indexes are each stored in separate subdirectories. For scalability and manageability, document libraries can be located on the file server where the post office resides, or on another volume or network server.

The post office is where various objects (such as E-mail, voice mail, documents, and appointments) are stored, ordered, and linked together. This makes it a valuable single access point for information, especially with the searches, filters, and query folders that are available in GroupWise. It is easy to set up and perform a single search and filter of all data types and combinations with boolean operators. Search and retrieval algorithms called queries uniquely combine database queries, full-text searches, and filters of the post office data. You can optionally save queries and query results in a query folder. Queries are performed and updated on demand, or the query folder can be configured to perform the query when it is opened. Filters can be saved separately, and once a filter is applied, all incoming data is evaluated using the filter.

The Post Office Agent

The post office agent (POA) captures and orders information for users. When information is sent from or arrives at the post office, it is stored, date-stamped, database-indexed, full-text indexed, conversation- threaded, compressed, and encrypted by the POA running on your network. Nested messages and message attachments are full-text indexed as well.

The POA performs notification, updates databases, sets references, does local sharing, replicates shared folders, and executes user-defined rules­all without user interaction. Multiple execution threads at the POA are launched on demand to maximize throughput and keep response times quick even under high load.

Following are some highlights of how the GroupWise POA works:

  • Replication. Organizations can easily and efficiently share information through the POA's unique replication technologies. A user can share a folder with other users and grant them read/write access to it. When new items are added to the folder, the POA evaluates the access list, the folder contents, and the location of the users sharing the folder. If users on multiple post offices are sharing a folder, the POA checks the database records and documents that meet the sharing criteria and replicates them where needed. Participating users can place a shared folder in their own folder hierarchy without regard to the folder structure of the owner.

  • Transaction algorithms. In GroupWise, the minimum amount of data is replicated using transaction replication algorithms. Only changed records and transactions­not entire indices or databases­are replicated. The records move through the message transfer system in high priority queues. The "late binding" capabilities of the database insure that replication is consistent throughout the message store system, even if slow store-and-forward links exist between domains. When GroupWise recognizes that data already exists at a post office, the data is referenced, not stored in multiple locations.

  • Performance. The POA is optimized for throughput and response time. A POA uses multi-threaded re-entrant database and client-server technology to make maximum use of your system resources. Database records are available to be read even during updates. GroupWise takes advantage of the power and speed of today's SMP (Symmetric MultiProcessing) servers to compress network traffic on client-server sessions, thus increasing overall throughput and extending the life of existing network infrastructures. QuickFinder high-speed index traversal algorithms are used for messages and documents. Multiple POAs on a single post office may be run for fault tolerance as well as for load balancing.

  • Scalabilty. The message store system is flexible and scalable to fit any organization's needs and to take advantage of the current network infrastructure. A single post office can have several thousand users configured on it. This lets GroupWise run in a centralized model where all or many users access one or a few large post offices that are using the power of SMP servers. Of course, practical network concerns such as sub-nets, backbones and routers will guide the configuration. For organizations that are more spread out, it may be more efficient to operate with several distributed medium-size or small post offices of a few to a few hundred users residing on many file servers on your network. Whatever the configuration, GroupWise lets information be located close to its users.

  • Reliability. The POA uses database roll-back logging to ensure reliability. On every read and write transaction the databases are monitored for integrity by using checksums and index consistency calculations. Necessary adjustments are made automatically while the system is online.

  • Security. The organization's data is kept secure both at the post office and while crossing the network. The post office can be completely shielded from direct file access with the TCP/IP client server option for the client to connect to the post office. Client-server sessions, databases, attachments, documents, and indexes are all encrypted with a 64-byte DES-like algorithm which is approved for international export.

Storage Space Savings

The message store system's optimization technologies provide the ability to store information efficiently and save disk space. In addition to compressing network traffic, compression algorithms are used to minimize message and document size in the post office. Further, only one copy of a message is stored at a post office, even if multiple users receive it. The QuickFinder text indexing technology creates exceptionally small full text indices.

To manage disk space proactively, the administrator can set disk space low and high thresholds for the POA to use when examining disk space availability. When the high threshold is reached, a warning is sent to the administrator. When the low threshold is reached, the POA will restrict the flow of new information until the issue is resolved.

The POA monitors libraries and creates a list of documents that are accessed infrequently. The administrator can choose to archive the documents that are on the list. Archived documents are moved to an archive location and can then be loaded to off-line storage. The documents remain in the index so that the information they contain is still available for user references and searches. If a user wants to access a document in the archive location, the POA restores it to the post office and library of its origin. If the document has been moved to off-line storage, a message is sent to the administrator requesting that the document be restored and placed in the archive location.

Client Access to the Post Office

A GroupWise 5 post office can be accessed in the following ways:

  • Client-server access to the POA (TCP/IP)

  • Client read/write direct access to the PO (drive map)

  • Client read direct from PO (drive map) / write indirect to POA (shared drive map)

  • Remote Client indirect access to POA

  • PhoneAccess server direct access to PO

  • WebAccess server direct access to PO

Note that although GroupWise 5 supports TCP/IP-based client-server access, support for drive map access is still available. These different access methods are compatible. Administrators may choose to limit how users access the post office, but the architecture does not force them to do so.

Extending the Post Office

The GroupWise post office is a store service provider that is fully compatible with Microsoft's Messaging Application Programming Interface (MAPI). As such, its message store system is equipped to handle user-defined fields. The POA stores additional fields in the post office. Users can then sort, filter, and search on the new fields like they can on any GroupWise field. Users or developers can add a variety of objects using the personal address book, the GroupWise Object API, Common Messaging Call (CMC), and MAPI.

Message Transfer System

The GroupWise message transfer system is comprised of message transfer agents (MTAs) which route messages among the POAs, ADAs, and connectivity agents. In organizations that use more than one post office in a domain, the MTA moves messages between the POAs. In organizations that have more than one domain, multiple MTAs route messages between domains.

To reduce network traffic, messages sent to multiple recipients in different post offices move through the message transfer system as a single message instead of as multiple messages. The MTA separates the message for delivery to different POAs, ADAs, connectivity agents, and possibly different MTAs at the last possible moment.

Messages are transferred from MTA to MTA using store-and-forward techniques to ensure reliable transfer of messages. The MTA uses a system of temporary holding directories on the network to receive and transmit messages. Before the sending MTA deletes the temporary storage of a message, it receives acknowledgment from the transport module (TCP/IP or File Copy) and logs the transfer. The receiving MTA logs the reception of the message before transferring it to the next destination.

Transport Modules

The MTA uses "pluggable" transport modules to route messages. Two transport modules are included with GroupWise:

  • The File Copy (drive mapping) transport module uses drive letters or UNC (Universal Naming Convention) paths to access directories that are shared between MTAs. File Copy transport is independent of the network protocol being used to access the shared directories; for example, IPX and NetBEUI.

  • The TCP/IP transport module uses native TCP/IP calls and a proprietary protocol to transfer the messages.

The MTA allows developers to write and "plug in" other transport modules to run natively on other protocols.

Other MTA Features

Platform Independent Architecture. The GroupWise MTA runs on multiple platforms. MTAs on all platforms are built from the same source code and are completely compatible. This code is highly optimized for SMP and 32-bit hardware platforms running multi-threaded operating systems. Yet even an MTA on a single-CPU NetWare server performs exceptionally well in handling the message traffic for thousands of users.

Throughput. The message transfer system is optimized for quick response time and maximum throughput. The MTA is a 32-bit, multi-threaded, SMP-aware server application that can simultaneously communicate with several other MTAs. One MTA can route messages on behalf of many post offices and connectivity agents. For added throughput, each MTA can have multiple connections with another MTA. This allows small messages to "move around" larger messages that take a long time on slow links.

Message Prioritizing and Ordering. Messages are prioritized and ordered to ensure efficient communication. There are several priority queues for transmitting messages. High priority messages move through the message transfer system faster than normal and low priority messages. Features such as message retraction, status tracking, replication, and remote computing require ordered delivery for messages to and from individual users. Even with multiple threads and an SMP architecture, the MTA ensures that messages in the same priority queue and from the same source are processed in order. Messages that are not order-dependent flow freely according to priority and availability of network bandwidth.

Checkpoint Restart. The MTA is designed to move data reliably even if the underlying transport is intermittent, such as a dial-up connection between MTAs. If a connection is lost, the MTA will attempt to re-establish the connection or remount the mapped drive at a configurable retry interval until the connection is restored. If a message was being transmitted when a link failed or when the administrator stops an MTA, a checkpoint restart algorithm resumes the transmission of the message at the point where it was cut off .

Dynamic Links. Communications costs can be controlled through the link scheduling capabilities of the MTA. Connections between other MTAs can be scheduled based on the needs of the organization A connection to another MTA can be made conditional on the number of messages, their combined size, or the time that they have been queued. The queued time is specified per priority queue. This powerful but simple tool saves money on connect time charges and gives the administrator control over the use of the system when needed.

Message Logging. The MTA logging features allows the administrator to monitor the message traffic and measure the throughput and link utilization of the system. Information about each message processed by an MTA is kept in the logging database. An API is provided to access this information so that organizations can build customized applications for billing and statistical analysis.

GroupWise Gateways

Communicating with foreign mail systems is a key requirement for any messaging product to be widely accepted. Accordingly, the GroupWise architecture includes external connectivity capabilities. At the core of the architecture is a common piece of software designed to address issues that are similar among all foreign mail systems. Gateways are built on this code base and are available for either GroupWise 5 or GroupWise 4.1 to provide connectivity to the following messaging systems:

  • SMTP/MIME

  • X.400

  • PROFS/VM

  • AS/400

  • Lotus cc:Mail

  • Lotus Notes

  • MHS

In addition, gateways derived from the same code base are available to work with telephones, fax machines, pagers, asynchronous dial-up lines, X.25 connectivity, and flat-file API access.

The GroupWise architecture is designed to support and manage connectivity. Gateways are configured in the system through an MTA. Because the MTAs can communicate with each other over high-speed links, a gateway only needs to be configured once. For example, an organization can configure one SMTP/ MIME gateway and have it service an entire company's Internet E-mail connectivity. Since the NLM-based SMTP/MIME gateway can process about 20,000 messages per hour, throughput is not a major concern.

GroupWise Clients

In 1994, Novell published the Collaborative Computing Environment (CCE) architecture to describe its long-term direction and strategy for building upon the strengths of NetWare and GroupWise. The CCE architecture describes a component-based architecture which allows third-party extensibility to the GroupWise product. It also describes an architecture which allows "plug-and-play" mechanisms, letting customers mix and match GroupWise components with non-Novell components. The GroupWise 5 client architecture is based on this vision and is the first step to the full CCE implementation.

32-bit Windows Client

When possible, GroupWise clients built by Novell use common code bases and infrastructures. The discussion below describes the architecture used for the 32-bit Windows 95 and Windows NT clients. Differences in other platforms will be discussed at the end of this section.

The GroupWise 5 client is built upon the GroupWise 4.x code base to take advantage of its stability and industry-proven capabilities. Extensions to this code base have been made to expose new features of the GroupWise 5 product, such as client-server capabilities and document management functionalities.

In GroupWise 5, the GroupWise 4.x client has been split up into multiple components to take advantage of a component-based architecture. These components fully interoperate and appear as a single program to the end user. They also supply an environment in which third parties can easily extend and replace components to provide customized solutions (see Figure 2).

Figure 2: The GroupWise 5 client is component-based.

The GroupWise Engine. Much of the functionality present in GroupWise is encapsulated in a component called the Engine. The GroupWise Engine has been built to be fully independent of platform, CPU, and machine. It is this engine that communicates with the GroupWise store and messaging system. The core engine code is never changed. To build a GroupWise client for a specific platform, Novell compiles the engine specifically for the platform by providing platform-specific memory routines, input/output routines, and so on (see Figure 3).

Figure 3: The GroupWise Client Engine is based on cross-platform code.

The Engine component for the Windows platforms exists in the form of a DLL, thereby maintaining a single instance of the Engine that is used by all other GroupWise client components. Because all components use this single connection point to the GroupWise infrastructure, the Engine can make economic use of the network connection and eliminate excessive traffic and connection management.

The Engine provides connectivity to the GroupWise messaging infrastructure either through direct access or through client-server protocols such as TCP/IP. The Engine establishes and maintains client-server connections. It utilizes NDS to determine the TCP/IP address of the proper GroupWise Messaging Server, eliminating the need for manual configuration of each workstation.

Component Manager. GroupWise users want to see a single product, with a single authentication mechanismCnot the components behind the product. They also want quick performance and full integration, which typically compete with the concept of components. To provide this environment, GroupWise utilizes a Component Manager that is responsible for tracking components and ensuring smooth and quick interaction between them. This Component Manager is similar to an Object Request Broker in that it helps components find other components and assists in setting up communication between them.

The Component Manager has two primary responsibilities. First, it provides a single point of authentication and Engine session management. Second, it provides a place for components to register and find out about each other. The Component Manager utilizes Component Object Model (COM) protocols to assist in these responsibilities.

When a component is started, it first contacts the Component Manager through COM mechanisms to obtain authentication and session information. If the Component Manager has not been started, it will collect authentication information, begin a GroupWise session with the Engine, and return the resulting session object or interface specification to the caller. This object contains a table of function pointers that can be used to communicate with the Engine, allowing direct communication between any component and the Engine without intervention from the Component Manager.

If the Component Manager has already been started through another component, authentication will have already been performed and the Component Manager will return the existing session object to the component. This eliminates the need for multiple logon dialog boxes for the end-user and provides a single connection between the desktop computer and the GroupWise messaging infrastructure, regardless of the number of components on the system (see Figure 4).

Figure 4: The GroupWise Component Manager.

Once components are initialized, they may request component objects (or interface specifications) for any other GroupWise component they need. For example, before sending a message the Client component must communicate with the Address Book component. The Client asks the Component Manager if the Address Book is available and how to communicate with it. The Component Manager looks through its registered component table to find the Address Book. If the Address Book has not yet been initialized, the Component Manager loads and executes it. The Component Manager then returns an Address Book object (or interface specification) to the Client, which the Client uses to communicate directly with the Address Book. From this point, communication performance is enhanced because the Component Manager is not used for direct communication between the two components.

The Address Book User Interface (ABUI). The address book component in GroupWise 5 extends the GroupWise 4.x address book functionality to include personal address books. This component is based on MAPI and utilizes the MAPI subsystem provided by all Microsoft 32-bit operating systems. The ABUI component uses MAPI calls to communicate with the MAPI Address Book providers (see Figure 5). This architecture allows the GroupWise ABUI to use any MAPI-compliant provider, whether it is a GroupWise provider or a provider included with Windows 95 or Windows NT.

Figure 5: The Address Book User Interface (ABUI).

To ensure a single session and authentication for all components, the ABUI uses services provided by the Component Manager. The ABUI also extends the native OS by exposing a new Windows class that can be used by any other component or third-party application. This class allows other components or applications to easily integrate and communicate with the Address Book name completion control. Thus any component or application can provide a common look-and-feel for addressing and name lookup purposes. This same control is also exported as an OLE automation control (OCX).

Address Book Providers. GroupWise 5 contains two address book providers: the System Address Book Provider and the Personal Address Book Provider. These providers, which expose directory services and lookup functionalities, are MAPI 1.0-compliant and can be accessed by any MAPI-compliant application. The ABUI component exposes these services in behalf of the GroupWise 5 client.

As true GroupWise 5 components, Address Book Providers use the services of the Component Manager to ensure a single session and authentication framework. Both providers also use the Engine component to communicate with the GroupWise messaging infrastructure and directory repositories (see Figure 6).

Figure 6: Address Book Providers.

Address Book Providers are installed as part of the GroupWise client and are immediately available to all MAPI-compliant applications.

Message Store and Transport Providers. To provide full accessibility to GroupWise services to MAPI-compliant applications, GroupWise Message Store and Transport MAPI providers are also part of the GroupWise system. These providers allow MAPI-compliant applications to access or create information stored in the GroupWise messaging system without writing to GroupWise-specific interfaces. These providers allow for either a file map attachment or a client-server protocol connection to the GroupWise messaging infrastructure.

Working together, the GroupWise Message Store, Transport, and Address Book providers allow a MAPI-compliant application, such as the Microsoft Exchange client, to participate with the messaging infrastructure of GroupWise 5. Due to MAPI limitations, a MAPI client cannot take advantage of all GroupWise features (such as group scheduling and document management). However, the client can benefit from the scalable and reliable messaging infrastructure that GroupWise provides.

The GroupWise Message Store and Transport providers are installed as part of the GroupWise client and are immediately available to all MAPI-compliant applications. The GroupWise setup program automatically registers these providers with the MAPI subsystem.

The Client Component. This component replaces the GroupWise 4.x client program and provides the core functionality of the GroupWise client. It also provides the primary browser interface into the GroupWise repository. The Client exposes and provides easy access to the many features of the GroupWise messaging system, including group calendaring, shared folders, and document management. This component is the primary executable program that is presented to the end-user.

The Client also provides integration directly with the OS desktop, including the ability to:

  • Drag and drop items directly to printer icons located on the desktop.

  • Create "shortcuts" on the desktop for quick access to specific GroupWise objects.

  • Drag documents from the desktop into GroupWise folders for document management import purposes.

  • Right-click on any item on the desktop and select a "Send To" function, allowing documents and other objects to easily be sent through GroupWise messaging.

The Client provides extensive integration with the services provided by the Windows operating system. While most preference information is stored and maintained in the user's GroupWise database, allowing consistency no matter what machine is used, machine-specific preference information is stored in the Windows Registry. The WordPerfect Binary Information File (BIF) is not used by GroupWise 5.

The Client also integrates with and uses built-in functionality such as the Windows Rich Text Editor and Tree controls. This provides a common look-and-feel with other programs written for the Windows operating system, reducing training and support costs. It also eliminates the need for GroupWise to use the WordPerfect PerfectFit subsystem, substantially reducing the size and memory footprint of the client.

The Client uses the Component Manager for authentication and session management purposes, ensuring optimal use of network bandwidth. It also uses the Component Manager to initialize all communication mechanisms with the other components that make up the GroupWise 5 client, such as the Engine and Address Book components. This allows these components to be updated independently of the Client component itself.

Full remote (disconnected) functionality is included in the Client component. The Client automatically detects whether a network connection is available so that it can connect to the primary GroupWise repository. If a network connection is not available, the Client (if so configured) automatically enters a disconnected mode, allowing the user to work offline. There is no need for the end-user to define a specific icon or startup parameter to enter disconnected mode. When the Client connects to the network after a remote session, the Client will automatically detect that the session occurred and will synchronize the remote database and the GroupWise system, reducing the need for manual resynchronization.

The Client can also establish a remote (disconnected) database in preparation for a disconnected session. When the user requests the Client to "Hit the Road," the Client establishes and populates a remote database with the proper user information and dial-up configuration. This significantly reduces the amount of training and support required for remote users.

Custom 3rd-Party Objects (C3PO) Manager. To provide custom extensions to the GroupWise client, Novell has defined Custom 3rd-Party Objects, which allow for new, custom object types and handlers to be added to the GroupWise system. To manage these handlers, the C3PO Manager component is required. This component is registered with the Client component and is started when the Client is initiated. It maintains a registry of C3PO handlers that have been defined and installed and provides communication between the C3POs and the client.

When the Client performs certain actions, events are sent to the C3PO Manager. This component then determines, based on C3PO registrations, which C3POs to pass the event to for further possible processing. The C3PO Manager communicates with the C3POs using either COM or OCX mechanisms, depending on the type of C3PO that is registered.

Sticky Notes. "Sticky Notes" is a C3PO component that ships as part of the GroupWise 5 SDK. This component provides annotation capabilities for all GroupWise messaging objects. It is initialized via the C3PO Manager and uses the Component Manager to communicate with the Engine and Client components. The Sticky Notes component uses the same interfaces that Novell exposes for third parties to enhance and extend the GroupWise product.

The Notify Component. The Notify component historically has existed as a standalone application that did not interact with the rest of the GroupWise client, limiting its capabilities. In GroupWise 5, Notify fully utilizes services available within other components through the Component Manager and COM mechanisms. This allows Notify to remain small, yet provide more functionality, such as reading messages, common authentication, and interacting directly with the GroupWise store and servers.

Because Notify interacts with the Component Manager, it uses the same authentication and GroupWise session as the rest of the GroupWise product, eliminating customer confusion over which GroupWise piece is logged in as which user. Notify provides integration with the Windows status bar and allows the user to define the level of intrusiveness to use when notifying the user of new items or alarms.

The Conversation Place. The Conversation Place component adds telephony functionality to the GroupWise family, allowing telephone interactions to be controlled and tracked with the GroupWise system. Conversation Place uses either TSAPI servers or TAPI modems to provide its telephony features. It automatically detects which subsystem is in place and uses those services. It can also replace the default Windows dialer program for more complete integration with the OS desktop and applications.

This component fully interacts with the Component Manager, ensuring a single authentication and logon mechanism. It also utilizes the Engine component, enabling a single communication pipe to the GroupWise server. Conversation Place also integrates with the Address Book User Interface component, taking advantage of the same Address Books and functionality that the Client uses. This consistent integration allows users to quickly become familiar with Conversation Place, reducing training time.

Other Client Platforms

Windows 16-bit Clients. A 16-bit GroupWise 5 client for Windows 3.x systems is provided for those customers who have low-end machines or who are not ready to upgrade to the latest Microsoft 32-bit operating systems. This client is based on the GroupWise 4.1 code base and exposes only the functionality currently available through that client.

Macintosh Clients. A fully featured Macintosh client for both 68000 and PowerPC chips is available with the GroupWise 5 system. While this client has all the functional components of the Windows client, it is not divided into as many components as the Windows client for the initial release. This is partly due to OS subsystems (such as MAPI) that don't exist on the Macintosh platform.

The Macintosh client uses Code Fragments, a new Macintosh concept that provides dynamic loading of libraries and shared code(similar to DLLs on the Windows platform). Using Code Fragments allows the multiple components of the Macintosh client to share functionality and components, such as the Engine (see Figure 7).

Figure 7: The GroupWise Macintosh client architecture.

This capability ensures the use of common authentication and session management. It also enables GroupWise to funnel all communication with the messaging infrastructure through a single connection point, reducing the amount of network traffic required.

UNIX Clients. GroupWise 5 clients are provided for three UNIX platforms: Sun Solaris, HP-UX, and IBM AIX. These clients are based on the GroupWise 4.1 client code for UNIX and provide the same extensive support as GroupWise 4.1 for UNIX.

Third-Party Interfaces

As the first stage in Novell's implementation of CCE, GroupWise 5 has been architected to be open, componentized and extensible. The vision of CCE requires an open, extensible environment for developing and deploying collaborative applications. GroupWise 5 embodies the CCE vision through its implementation of components, standards, and extension interfaces.

The GroupWise 5 SDK is part of Novell's DeveloperNet 2000 initiative to develop an open set of APIs to expose the full functionality of network services for distributed network application developers. A primary objective of this initiative is to increase the value of Novell's network services to desktop component and object developers. The GroupWise 5 Object API, C3PO interfaces, and Address Book OCXs are among the first implementations of this initiative.

For more information about the GroupWise 5 APIs, see the September 1996 issue of Novell Developer Notes (call 800-394-5088 or 801-342-3451 for ordering information) or visit Novell's GroupWise web site at http://www.novell.com/products/groupwise.

Conclusion

This AppNote has presented a basic overview of GroupWise 5 to help network designers, integrators, and administrators better understand its underlying messaging architecture. Future AppNotes will cover the various aspects of installing, upgrading, and working with GroupWise 5 in greater detail.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates