GroupWise 5 Architecture: GroupWise Is Messaging

Articles and Tips: article

GROUPWISE 5
DEVELOPMENT TEAM

01 Sep 1996

Discusses synchronization of the GroupWise Directory with NDS, compatability with domains on NetWare 3.x servers, and the architecture implemented with the Windows 95 and Windows NT clients. Also presents a list of GroupWise 5 APIs and customer third-party object interfaces.

Introduction
Architecture
GroupWise Administration and Management
Message Store System
Message Transfer System
Gateways
Clients
Third-Party Interfaces

Introduction

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

The GroupWise architecture enhances communication by treating any electronically captured information as a basic element called a message- regardless of its format. With GroupWise, the way information is captured is not an issue. The key to making that information valuable lies in how it can be easily organized, shared, preserved, and accessed. That's why GroupWise is built on a messaging architecture. And that's why GroupWise is messaging.

Architecture

You can better understand GroupWise if you understand the terms used within the architecture.

Administration and Management is responsible for directory and system administration tools to maintain the system Address Book and configuration informationabout your GroupWise installation.
The message store system is a series of post offices on the network. It securely houses your information in the form of calendars, messages, documents, indexes, and folders.
The message transfer system is composedof message transfer agents (MTAs) which route messages between the post offices, gateways and directory agents.
GroupWise gateways seamlessly link yourGroupWise system with non-GroupWise systems.
The client provides the user interface to the services 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 your GroupWise system.

GroupWise Administration and Management

Administrating GroupWise 5 is easy because it uses NetWare Directory Services (NDS) as its master directory. This means GroupWise can use data which has already been defined in the system, eliminating the need to enter common user information more than once. The administration user interface has been integrated with the NetWare Administration program to give users a single point of administration.

A simple GroupWise system is a collection of data storage areas and agent programs. Understanding GroupWise data storage and agent relationships is important to understanding how a GroupWise system is administered.

Data Storage

User data is generated when a user creates a message (mail, calendar, notes) or document and is stored at a GroupWise post office and moved through the system by the message transport subsystem. (See Message Store System and Message Transfer System below.) 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.

The GroupWise Directory refers to all administrator data in a GroupWise system. A copy of the administrator data is stored at each post office and domain in the system. The GroupWise Directory is secondary to the global Directory, NetWare Directory Services (NDS). A subset of the information available in NDS is replicated to the GroupWise Directory which is indexed at each access point to enable fast lookup of information.

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), and the Administration Agent (ADA). Each agent is available on a variety of operating system platforms.

Administration Object Model

The administration of GroupWise is concerned with manipulating the objects in the system. Each major object class in GroupWise is described below.

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.
Post Office	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 post office.
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 resource objects.
Distribution List	Alist of users and/or resources which receiveany message addressed to the distribution list.
Library	A storage location for documents with an associated access list and profile attribute set. Anattribute defines the locations where the documents will be stored.
Agent	Aprocess that works on a specific set of GroupWise data. The Post Office Agent delivers messages to the user data store, the Message TransferAgent transports messages between domains and post offices, and the AdministrationAgent replicates information between the GroupWise directory databases and NDS.
Connectivity Agent	An agent that provides conversion from GroupWise to another message or communication protocol.

GroupWise and NWAdmin

The user interface for GroupWise administration is the NetWare Admin program (NWAdmin). Because NWAdmin is familiar to the NetWare administrator, there is no new paradigm to learn. And because administrative information is stored in NDS and is drawn from a global directory, it only needs to be entered once.

The GroupWise Admin Snapin lets you edit GroupWise-specific objects and attributes in NDS. NWAdmin is written to allow applications to "snap in" and extend the NWAdmin User Interface to support extensions to NDS. The GroupWise Admin Snapin adds interface for all of the GroupWise object classes previously described. Also, the Snapin allows many GroupWise utilities to be accessed from the tools menu in NWAdmin.

Directory Replication and Synchronization

The GroupWise Directory is synchronized with NDS. GroupWise replicates the Address Book information from NDS into the GroupWise Directory. The fully replicated indexed database on which the GroupWise Directory is built provides fast lookups for the GroupWise Address Book.

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 can participate fully in the GroupWise system. This means that existing domains on NetWare 3.x servers and on other NOS platforms function as they have in the past.

In this replication, NDS is the "master directory" and pertinent data is replicated from NDS to the GroupWise Directory. Data is never pushed from the GroupWise Directory-it is read from NDS and written to GroupWise.

Administrator data is propagated from a domain's 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 domain in an interconnected system and allows a GroupWise system to span NDS and non-NDS network nodes.

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

In the second method, the Administration Agent (ADA) checks NDS for changes that 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 Snapin,
changes made by any application which writes directly to NDS.

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

Replication Between GroupWise Domains. A GroupWise domain can be a primary, secondary, external, or foreign domain. The domain's type determines how it participates in the replication of directory data. The domain types are described below.

GroupWise Domain Types
Primary	Thereis only one primary domain in a GroupWisesystem. All directory updates must pass throughthis domain. Every change is sent to theprimary domain from the originating domain.The primary domain then propagates the changeto the rest of the system.
Secondary	Asecondary domain participates fully in thereplication of administrator data, but allchanges made at the secondary domain aresent to the primary domain for propagation.
External	Anexternal domain is considered a separateGroupWise system, and by default, receivesno Administration data but can be configuredto participate in a system's directory synchronization.The GroupWise administrator specifies whichobjects to replicate from the external domain,and the administrator of the external domainspecifies which objects can be replicated.
Foreign	Aforeign domain is an external system thatis not GroupWise. GroupWise does not replicateforeign domains because directory formatis unknown. Many foreign domains can participatein directory information exchange througha gateway to GroupWise. Foreign domains areprovided so addresses from outside systemscan be published in the GroupWise Address Book.

Administrator Features

Administrator features include the following:

GroupWise View. The GroupWise Admin Snapin adds a new browser view called the GroupWise view which makes it easy for an administrator to see only those objects which belong to the GroupWise system.

Maintenance Utilities. The following utilities are important to managing a GroupWise system and are accessible through the GroupWise Admin Snapin:

System Connection allows the administrator to switch between GroupWise systems.
Import/Export permits the importing and exporting of GroupWise and NDS data to an ASCIIdelimited 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. 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 the Agents. GroupWise 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 defines the domains in which the agent is responsible for synchronizing GroupWise with NDS. Keeping the configuration in the NDS directory allows configuration files to be modified from the administration interface, eliminating the need to manually edit configuration files at each agent.

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

GroupWise Administration of GroupWise 4.1 Systems

A GroupWise system is migrated one domain at a time. As a domain is migrated, the objects in that domain are moved into NDS and must be managed through the GroupWise Admin Snapin 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 auto upgrade when users enter GroupWise.

Message Store System

The Message Store System 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.

The Post Office

Your 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. Physically, a post office is a directory structure on a network file server. The directory structure contains subdirectories, files, and databases. The message store system is comprised of one or many such post offices configured on your network.

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 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 Agent

The post office agent (POA) captures and orders information for you. When information arrives at or is sent from 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 without user interaction. Multiple execution threads at the POA are launched on demand to maximize throughput and keep response time quick even under high load.

Retrieving Information

The various objects (such as E-mail, voicemail, documents, and appointments) that are stored, ordered, and linked together at the post office make it a valuable single access point for information, especially with the searches, filters, and query folders performed by 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.

Sharing and Replication

Your organization can easily and efficiently share information through the unique replication technologies of the POA. A user can share a folder with other users and grant them read/write access to it. The POA evaluates the access list, the folder contents, and the location of the users sharing a folder when new items are added to the folder.

If users on multiple post offices are sharing a folder, the POA checks database records and documents that meet the sharing criteria and replicates them where needed. Shared users can place a shared folder in their folder hierarchy without regard to the folder structure of the owner.

GroupWise replication technology is quick and efficient. The minimum amount of data is replicated using transaction replication algorithms. Changed records and transactions are replicated-not entire indices or databases. 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. Replication techniques recognize if data exists previously at a post office, and if that is the case the data is referenced and not restored.

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. Today's SMP servers can work at speeds that are much faster than the networks to which they are connected.

GroupWise takes advantage of this power to compress network traffic on client/server sessions to increase overall throughput and extend the life of your network infrastructure. QuickFinder highspeed index traversal algorithms are used for messages and documents. Multiple POAs on a single post office may be run for redundancy as well as load balancing.

Scalabilty

You can use the flexibility and scalability of the message store system to fit your organizational needs and take advantage of your current network infrastructure. A single post office can have several thousand users configured on it. This lets you run GroupWise in a centralized model where all or many of your users access one or a few large post offices using the power of SMP servers.

Practical network concerns such as sub-nets, backbones and routers will guide your configuration. However, GroupWise lets you locate your information close to your users. For organizations that are more spread out, several distributed medium or small post offices of a few to a few hundred users residing on many file servers on your network may be more efficient to operate.

Compression

The message store system optimization technologies give you 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.

Reliability

The POA uses database roll back logging to insure reliability. The databases are monitored for integrity on every read and write transaction by using check-sums and index consistency calculations. Necessary adjustments are made automatically while the system is online.

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.

Security

Your 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. Client/server sessions, databases, attachments, documents, and indexes are all encrypted with the 64-byte DES-like algorithm which is approved for export.

Archiving Documents

The POA monitors libraries and creates a list of documents that are infrequently accessed. The administrator can 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.

Extending the Post Office

The message store system is equipped to handle user-defined fields. The user or developer can add a variety of objects using the object API, personal Address Book, MAPI and CMC. The POA stores additional fields in the post office. The user can then sort, filter, and search on the new fields like any GroupWise field. The post office is a full MAPI store service provider.

Client Access

Even though GroupWise supports TCP/IP based client/server access, the drive map access was not removed. The different access methods are compatible, and though administrators may choose to limit how users access the post office, they are not forced by the architecture to do so. The 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 (drivemap)
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

Message Transfer System

The message transfer system is comprised of message transfer agents (MTAs) which route messages among the POAs, ADAs, and connectivity agents. If your organization uses more than one post office in a domain, then the MTA moves messages between the POAs. If your organization has more than one domain, then multiple MTAs will route messages between domains.

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

Store and Forward

Messages are transferred from MTA to MTA using store and forward techniques. Store and forward ensures reliable transfer of messages. The MTA uses a system of temporary holding directories on the network to receive and transmit messages. The sending MTA gets acknowledgment from transport module (TCP/IP or File Copy) and logs the transfer before it deletes the temporary storage of the message. 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 the messages. File copy (drive mapping) and TCP/IP modules are included with GroupWise. The file copy transport uses drive letters or UNC paths to access directories shared between MTAs. File copy transport is independent of the network protocol being used to access the shared directories. example: IPX and NetBUI. The TCP/IP transport module uses native TCP/IP calls and a proprietary protocol to transfer the messages. The MTA allows you to write and "plug in" other transport modules and lets you run natively on other protocols.

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 on 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.

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 simultaneously communicates 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. By handling multiple connections, small messages can move around larger messages that take a long time on slow links.

Message Order

Your messages are prioritized and ordered to insure efficient and robust 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. Several features such as a 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. However, messages that are not order dependent flow freely according to priority and availability of network bandwidth.

Dynamic Links

You can control your communications costs by using the link scheduling capabilities of the MTA. Connections between other MTAs can be scheduled based on the needs of your 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 you control over the use of the system when needed.

Message Logging

You can monitor the message traffic in your organization and measure the throughput and link utilization of the system by using the MTA logging feature. Information about each message processed by an MTA is kept in the logging database. An API is provided to access this information so that each organization can build customized applications for billing and statistical analysis.

Platform Independent Architecture

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

Gateways

Because communicating with foreign mail systems is a key requirement for any product to be widely accepted, the GroupWise architecture includes a rich set of external connectivity capabilities. At the core of the architecture is common piece of code designed to address issues that are similar to all foreign mail systems.

These gateways are built on that code and are available and work with either GroupWise 5 or GroupWise 4.1 to provide connectivity to foreign messaging systems: SMTP/MIME, X.400, PROFS/VM, AS/400, Lotus cc:Mail, Lotus Notes, and MHS. In addition, gateways derived from the same code base are available to work with either GroupWise 5 or GroupWise 4.1 with telephones, fax machines, pagers, async dial-up, 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. This means that an organization can configure one SMTP/MIME gateway, for example, and have it service an entire company's Internet E-mail connectivity. Since the NLM-based SMTP/MIME gateway can process about 20K message per hour, throughput is not a major concern.

Clients

When possible, GroupWise clients built by Novell use common code bases and infrastructures. The discussion below describes the architecture used within the Windows 95 and Windows NT clients.

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 1994, Novell published the Collaborative Computing Environment (CCE) architecture to describe its long-term direction and strategy for building upon the strengths of Novell 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, allowing more flexible, customer-based solutions. The GroupWise 5 client architecture is based on this vision and is the first step to the full CCE implementation.

GroupWise 5 utilizes a component-based architecture, breaking apart the historical GroupWise 4.x client into multiple components. These components will fully interoperate and appear as a single program to the end user, continuing to provide ease-of-use, while also supplying a rich environment in which third-parties and partners can easily extend and replace components to provide customized solutions.

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 platform, CPU, and machine independent. It is this engine that communicates with the GroupWise store and messaging system. To build a GroupWise client for a specific platform, Novell first compiles the engine specifically for the platform by providing platform-specific input/output routines, memory routines, etc. The core engine code is never changed.

The Engine component for the Windows platforms exists in the form of a DLL. A single instance is maintained and used by all other GroupWise client components. The engine provides connectivity to the GroupWise messaging infrastructure either through client/server protocols such as TCP/IP or through direct access. Because all components use this single connection point to the GroupWise infrastructure, the Engine can perform economies on the network connection and eliminate excessive traffic and connection management.

Client/Server connections are established and maintained by the Engine. The Engine utilizes the NetWare Directory Services (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 mechanism-not the components behind the product. They want quick performance and full integration, things which typically compete with the concept of components. To provide this environment, GroupWise utilizes a Component Manager which 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 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.

Once initialized, Components may request component objects (or interface specifications) for any GroupWise component they need. For example, the Client component needs to communicate with the Address Book before sending a message. 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 the component.

Once initialized, the Component Manager returns an Address Book object (or interface specification) to the Client. The Client can then use this object 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.

Address Book User Interface (ABUI)

The Address Book is a new GroupWise 5 component which extends the GroupWise 4.x Address Book functionality to include personal Address Books. This component is based on Microsoft Messaging Application Programming Interface (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. This architecture allows the GroupWise Address Book user interface to use any MAPI-compliant provider, whether it is a GroupWise provider or a provider included with Windows95 and Windows NT.

To ensure a single session and authentication for all components, the Address Book UI 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. This means that 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.

Address Book Providers are true GroupWise 5 components and 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. 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 MAPI-compliant applications with full accessibility to GroupWise services, 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.

The GroupWise Message Store, Transport, and Address Book providers work together to allow a MAPI-compliant application, such as the Microsoft Exchange client, to participate with the robust 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, Transport, and Address Book 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.

Client

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 will be 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 PerfectFit subsystem is no longer included with the GroupWise 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 also included in the Client component. The Client will automatically detect 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, will automatically enter a disconnected mode, allowing the user to work in an offline mode. There is no need for the end user to define a specific icon or startup parameter to enter a 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, or 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. This component 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.

Notify

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 rich 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.

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.

Macintosh Clients

A fully featured Macintosh client for both 68000 and PowerPC chips will be available with the GroupWise 5 system. While it will have all the functional components of the Windows client, it will not be divided into as many components as the Windows client for the initial release. Some of this is due to missing OS subsystems (such as MAPI) on the Macintosh platform.

The Macintosh client uses Code Fragments, a new Macintosh concept that provides dynamic loading of libraries and shared code. This concept is similar to DLLs on the Windows platforms. Using Code Fragments allows the multiple components of the Macintosh client to share functionality and components, such as the Engine. This capability ensures that common authentication and session management is used. It also enables GroupWise to funnel all communication with the messaging infrastructure through a single connection point, reducing the amount of required network traffic.

Windows 16-bit Clients

A "light" GroupWise 5 client for Windows 3.x systems will be 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.

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. Through the implementation of components, standards, and extension interfaces, GroupWise 5 embodies the CCE vision.

The GroupWise 5 SDK participates in Novell's Net2000 initiative. Net2000 is an effort to develop an open set of APIs to expose the rich functionality of network services to developers building distributed network applications. A primary Net2000 objective 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 the Net2000 initiative. The following table contains a summary of the GroupWise 5 APIs.

GroupWise 5 APIs
MAPI1.0	Windows-basedE-mail API from Microsoft.
ODMA 1.0	Documentmanagement API from the ODMA committee of AIIM.
ODMAWF 1.0	WorkFlowAPI from the ODMA committee of AIIM.
CMC 1.0	E-mail API from XAPIA.
CSA 1.0	Calendaring/SchedulingAPI from XAPIA.
SNMP - MADMAN MIB	Anadminstrative interface for server administration and monitoring.
Token Interfaces	Thisis the macro interface into the GroupWise 5 Client.
GroupWise Object API	Accessto the GroupWise 5 store.
C3PO Interfaces	GroupWise5 Client extension interfaces.
MTAMessage Logging API	ThisMessage Transfer Agent API gives access toinformation about the messages handled by the MTA.
MTA Transport API	ThisAPI allows the MTA communication protocols to be extended.
Address Book OCXs	Thesetwo OCXs expose the Address Book and the Name Completion Control interface into theAddress Book.

The GroupWise 5 notion of a Custom 3rd-Party Object (C3PO) is an excellent example of the extensibility and openness of GroupWise 5. The C3PO specification describes how new object types can be added to the GroupWise 5 store and how new behaviors for these (and existing) objects can be added to the GroupWise 5 Client. The GroupWise Object API and the C3PO interfaces, which provide the basis for such extensions, are described below.

The GroupWise Object API provides rich, data-level access to the GroupWise 5 store. Unlike MAPI, which provides an E-mail-centric view of data, the Object API exposes all of the object types in the GroupWise store, including E-mail, appointments, notes, tasks, phone messages, voice mail, and documents. Developers can also extend the GroupWise store to handle new object types and access them through the Object API.

The Object API gives a user-perspective access to GroupWise 5 data. From its OLE Automation interface, a Visual Basic, Delphi, or other OLE Automation tool, a programmer can navigate a user's folders, messages, Address Books, document libraries and documents. The C++ developer can use either the OLE Automation interface or COM interfaces. New folders, messages, documents, and other items can be created. Existing items can be read and modified. The Object API allows additional properties to be associated with both existing items and new items.

When used with the C3PO interfaces, the Object API lets you implement new, unique objects within GroupWise 5. (See the "Object API" article in this periodical for a model.) Another new interface is the Custom 3rd-Party Object (C3PO) interface which lets developers extend the GroupWise 5 Client. Using this interface, you can implement new objects with unique behavior in the GroupWise environment. You can also extend or modify the behavior and properties of existing objects. The individual interfaces that comprise the C3PO interface are summarized below.

Custom 3rd Party Object Interfaces
CmdCtx	GivesC3POs an interface into the GroupWise 5 Clientwhich provides user-interface context forthe current operation.
Delivery	Calledwhen associated data types are delivered to the GroupWise box.
DoCommand	Respondsto commands invoked against the C3PO.
DropTarget	Allowsa C3PO to support the drag-and-drop operation for custom data.
Icons	Retrievesicons that represent the state of C3PO data types.
Init	Required.Initializes the C3PO.
Ready	Calledduring the GroupWise 5 Client initialization procedure.
SetupCommands	Definesmenu and toolbar changes.
SetupContainer	Notifiesa C3PO whenever a container for a data type is displayed.
Enum	Iteratesamong the C3PO servers in the system. Servesas the basis for navigating type hierarchy, installation lists, etc.
Man	Thisinterface, along with ManCommand and ManMessage are interfaces into the C3PO Manager. Togetherthey provide access to C3PO functionality outside of the GroupWise 5 Client.
ManCommand	TheC3PO Manager's command interface.
ManMessage	Theaggregated C3PO Manager interface for the GW.APPLICATION.BROWSER registered C3POs.

These interfaces, coupled with the Object API, make the GroupWise 5 product a robust, extensible platform for developing collaborative applications. The GroupWise 5 SDK contains a Customer Tracking System built with the C3PO interfaces and Object APIs. This sample application, complete with its source, creates three new data types: a Company object, a Contact object, and an Action object. Behaviors for these new objects are implemented through the C3PO DoCommands interface, with the Object API used to read and write the data to the store.

Other behaviors are inherited from the GroupWise 5 Client. The C3PO SetupCommands interface is used to extend the File|New submenu to include Company, Contact, and Action as objects that can be created. The Customer Tracking C3PO uses the Icons interface to associate appropriate icons with these new objects.

This application looks and feels like a native part of GroupWise 5. Because it is integrated into the user interface as well as the store, the user cannot detect where GroupWise product code ends and the new application begins.

Key subsystems of GroupWise 5 have been implemented as components: the Address Book, the Conversation Place, GroupWise Notes, and the Object API have all been implemented to run either independently of the GroupWise 5 Client or integrated with the Client.

This lets users access key functionality without running the Client. For developers, OCXs have been provided which provide access to the Address Book and the Name Completion Control (an interface to the Address Book). This enables developers to create their own applications which take advantage of these GroupWise 5 components.

In support of standard and defacto standard APIs, GroupWise 5 implements MAPI 1.0, ODMA 1.0, ODMAWF 1.0, CMC 1.0, CSA 1.0, all of which provide standards-based access to GroupWise.

GroupWise 5 also lets you use your favorite scripting tool to script Client behavior. Historically, GroupWise contained a proprietary scripting language, PerfectScript. But GroupWise 5 exposes scriptable tokens to tools like Visual Basic and Delphi via OLE Automation. The token set encompasses the power of the GroupWise 5 Client.

Through APIs, components, and interfaces, GroupWise 5 and its SDK form the basis of Novell's Collaborative Computing Environment. GroupWise 5 is an environment that facilitates the development and deployment of collaborative applications.

* 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.