CHAPTER 1

Sun Messaging Connectivity Services Overview




Sun Messaging Connectivity Services provides batch-mode connectivity to the Lotus cc:Mail proprietary messaging system.

Sun Messaging Connectivity Services connects the Sun Internet Mail Server to proprietary mail systems and supports integration of users from those systems to native internet.


Overview of Sun Messaging Connectivity Services Architecture

Sun Messaging Connectivity Services is composed of a backend server and messaging frontend systems that talk to the proprietary mail clients.

The Administration Console contains components to help you configure the server and monitor your client and server linked by channels. Channels perform the message format conversions and coordinate the flow of messages between the SIMS server and cc:Mail client. Each channel converts the inbound message to the canonical format, then sends the message to the router.

The router reads the canonical address to determine the destination and passes the message to the channel associated with the recipient's local mail network. The outbound message is then converted to the outbound channel's message format and passed to the outbound channel's transport for delivery into the client mail agents.


Channels

A channel is an interface with another Sun Internet Mail Server (SIMS) 3.5 component, another mail system, or mail user agent. The actual hardware connection or software transport or both may vary widely from one channel to the next.

Each channel consists of up to two channel programs and an outgoing message queue for storing messages that are destined to be sent to one or more of the interfaces associated with the channel. Channel programs perform two functions:

They transmit messages to other interfaces, deleting them from their queue after they are sent.
They accept messages from other interfaces, placing them or enqueueing them into channel queues. Note that while a channel program only removes messages from its own queue, it can enqueue messages in any queue, including its own.
A channel program that initiates a message transfer to another interface on its own is called a master program. A program that accepts transfers initiated by another interface is called a slave program. A channel can be served by a master program or a slave program.


Transports

Transports are background programs that transfer messages between networks. Some channels have a client component that interfaces between the server and the local computing environment. Others, such as SMTP/MIME, act as full peer message transfer agents (MTAs). Each transport program supports multiple channels.


SPX Transport

This type of transport provides an Ethernet-based method for transferring messages with a PC-based SPX client program. This type of transport communicates directly with the cc:Mail client for message transfer.


Filesharing Transport

This type of transport moves messages between the UNIX operating system and the PC running a client through a shared file system available to both platforms. When a channel is configured to use filesharing transport, you must specify the shared directory to use for the file exchange.


Directory Synchronization

There are two types of directories that participate in the directory synchronization process - a central directory and several secondary directories.


Central Directory

The central directory is a fully LDAP-compliant directory that stores and maintains a wide range of user and system information, including component configurations, message routing data, and end-user records. The central directory also organizes and facilitates access to information needed to convert and route messages. It provides users inside and outside the organization the ability to locate people and access a variety of information about them.


Secondary Directory

The secondary directories are separate directories maintained by each mail system, which the central directory must coordinate and communicate with to provide transparent connectivity among mail systems. The information stored in the secondary directories must be synchronized with other directories so information is consistent across all directories.

Within SMCS, every user data change is owned and administered through secondary directories and propagated to the Central directory.




Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved.