 |
Claims  |
|
|
What is claimed is:
1. A method of electronically messaging between computers by heterogeneously and universally interfacing distributed applications and processes residing in a wide variety of
differing computer platforms and communications transport facilities of various types, that comprises:
providing a set of single-function software modules controlled by a preselected set of module verbs that together provide a single consistent application programming interface between the applications/process and the communications facility and
through which application programs/processes can directly access the electronic messaging;
under the control of the set of module verbs, first queuing and routing messages and data flowing from and to the sending and recovering computer applications/processes and monitoring the delivery status thereof, and then communicating the routed
messages and data through a communication agent for each communications transport facility, including the steps, performed by a receiving entity having a queue, of
on receiving a given message from a sending entity having a queue, placing the given message and associated data in the receiving entity's queue,
determining whether the given message specifies an acknowledgment, and if so, sending an acknowledgment message to the sending entity, the acknowledgment message specifying that the sending entity can remove the given message from the sending
entity's queue,
sending the given message to a destination entity, specifying an acknowledgment, and
on receiving an acknowledgment from the destination entity, releasing the given message and associated data from the receiving entity's queue, thereby supporting the ability of one of the application programs/processes to specify that delivery
for the given message is to be guaranteed, regardless of whether the communications transport facility that carries the given message supports guarantee delivery; and
providing common messaging functions for all communication agents independently of and without user concern for the specifics of the various communications transport facilities and their characteristics.
2. A method as claimed in claim 1 and in which the module verbs are used to provide for message transfer and receipt, message managing and queuing, and environment resource allocating and deallocating.
3. A method as claimed in claim 2 and in which the managing of the data/message comprises managing queues for routing outgoing and incoming data/message transmission and delivery, and notifying applications of message status changes.
4. A method as claimed in claim 3 wherein:
on startup, queues for the data/messages are rebuilt from saved files; and
on shutdown, data/messages which have not been completed and are saveable are entered into such saved files.
5. A method as claimed in claim 3 and in which, if the application for a designated user is not active, the application process is started to deliver the incoming data/message.
6. A method as claimed in claim 1 and in which each said communication agent manages the passing of data/messages to and from its communications transport facility.
7. A method as claimed in claim 1 and in which data/messages, particularly of substantial length, are segmented for sending and are reassembled upon receipt, with segment length optimized in accordance with the particular communications
transport facility.
8. A method as claimed in claim 7 and in which a message header is applied between the application/process and the module-verb interface to encapsulate prefix header control data with the message to identify the ultimate destination of the
data/message and to provide a tag or name for selecting the data/message.
9. A method as claimed in claim 8 and in which there is included in the message header all data needed to route, acknowledge or confirm, and recover the data/messages as they move from sender to destination.
10. A method as claimed in claim 9 and in which the message header data controls how the data/message is to be handled and further enables adding and dropping information as and when needed or no longer required, including by the communications
facility.
11. A method as claimed in claim 7 and in which the message segments are subdivided into message packets corresponding substantially to the maximum handlable by the particular communications facility.
12. A method as claimed in claim 11 and in which the message packets are combined in preselected frames prior to sending over the communications facility.
13. A method as claimed in claim 2 and in which the particular one of the module verbs is COMMIT, actuation of which informs the routing that a complete message has been successfully received and processed as required and that the message and
its related queue data may be released.
14. A method as claimed in claim 2 and in which one of the interface module verbs is DELETE, actuation of which enables removal of one or more selected messages from a specified queue regardless of priority, pending or active state, or whether
receipt has yet been acknowledged.
15. A method as claimed in claim 2 and in which one of the interface module verbs is FREEBUF, actuation of which releases data storage and queue entries when no longer required.
16. A method as claimed in claim 2 and in which one of the interface module verbs is GET BUF, actuation of which allocates resources such as internal memory needed to support message sending and status services.
17. A method as claimed in claim 2 and in which one of the interface module verbs is INITIALIZE, actuation of which connects the calling application or process for electronic messaging by creating and initializing one or more routing message
queues, such as a send queue and a receive queue, for the calling process.
18. A method as claimed in claim 2 and in which one of the interface module verbs is PURGE, actuation of which removes all of the messages from any local queue regardless of priority and pending or active state.
19. A method as claimed in claim 2 and in which one of the interface module verbs is RECEIVE, actuation of which effects delivery of an incoming message to the destination application and queues the message traffic awaiting delivery and priority
to such destination.
20. A method as claimed in claim 2 and in which one of the interface module verbs is SEND, actuation of which places a message into routing queue for eventual sending to the specified destination.
21. A method as claimed in claim 2 and in which one of the interface module verbs is STATE, actuation of which enables inquiry about or alters the state of any local routing message queue.
22. A method as claimed in claim 2 and in which one of the interface module verbs is STATUS, actuation of which enables inquiry about or alters the status of any message in the named message sending queue and obtains the number of messages in
such queue.
23. A method as claimed in claim 2 and in which one of the interface module verbs is TERMINATE, actuation of which, before application exit, resolves latent messages and then terminates the application connection to its routing message queue.
24. An electronic messaging system for communicating between computers and the like with heterogeneous and universal interfacing between distributed applications and processes residing in a wide variety of differing computer platforms and
communications transport facilities of various types, having, in combination:
means for providing between an application/process and a communications facility a set of single-function software modules controlled by a preselected set of verbs that together provide a single application programming interface through which
application programs/processes can directly access the electronic messaging by an interface control block;
message routing means controlled by the application programming interface control block for staging messages and data flowing from and to the sending and receiving computer applications/processes by a router control block for determining message
handling and communications transport facilities, and monitoring the message delivery status, said message routing means including
means for determining whether a particular message is too large to be handled by a particular communications transport facility, and if so, segmenting the particular message into segments sized to be accommodated by the particular communications
transport facility,
means for maintaining a given message and associated data in a queue, and
means, responsive to a particular verb from one of the receiving computer applications/processes that received the given message, for (a) generating an acknowledge message and communicating the acknowledge message to one of the sending computer
applications/processes, and (b) releasing the given message and any queue data, said particular verb thus supporting the ability of one of the sending computer applications/processes to specify that delivery for the given message is to be guaranteed,
regardless of whether the communications transport facility that carries the given message supports guaranteed delivery; and
communication agent means, one corresponding and connected to each communications transport facility, controlled by common communication management means connected to the routing means and responsive to its said router control block to control
the message flow from each communication agent means to its corresponding communications transport facility independently of and without user concern for the specifics of the various communications facilities and their characteristics.
25. An electronic messaging system as claimed in claim 24 and in which the application programming interface verbs comprise a set for message transfer and receipt, a set for message managing and queueing, and a set for environment resource
allocating and deallocating.
26. An electronic messaging system as claimed in claim 25 and in which means is provided controlled by the communications management means for providing the message with a header containing data needed to route, acknowledge or confirm, and
recover the electronic data/messages as they move from sender to destination.
27. An electronic messaging system as claimed in claim 26 and in which the header providing means further provides information to control how the data/message is to be handled and enables adding and dropping information as and when needed or no
longer required, including by the communications facility.
28. An electronic messaging system as claimed in claim 24 and in which means is provided for segmenting the data/messages for sending and for reassembling upon receipt, with segment length substantially optimized in accordance with the
particular transport communications facility.
29. An electronic messaging system as claimed in claim 28 and in which means is provided for subdividing the message segments into message packets.
30. An electronic messaging system as claimed in claim 29 and in which means is provided for combining the message packets in preselected frames prior to sending over the communications facility.
31. An electronic messaging system as claimed in claim 24 and in which means is provided for enabling the verbs of said application programming interface modules selectively to effect one or more of the following functions:
(1) to inform the routing means that a complete message has been successfully received and processed as required, and that the message and its related queue data may be released;
(2) to remove one or more selected messages from a specified queue regardless of priority, pending or active state, or whether receipt has yet been acknowledged;
(3) to release data/storage and queue entries when no longer required:
(4) to allocate resources such as internal memory needed to support message sending and status services;
(5) to connect the calling application or process for electronic messaging;
(6) to remove all of the messages from any local queue regardless of priority and pending an active state;
(7) to deliver an incoming message to destination application and to queue the message traffic awaiting delivery and priority to such destination;
(8) to place a message into routing queue for eventual sending to the specified destination;
(9) to inquire about or alter the state of any local routing message queues;
(10) to inquire about or alter the status of any message in the named message sending queue and to obtain the number of messages in such queue; and
(11) to resolve latent messages before application exit and then terminate the application connection to the routing message queue.
32. An electronic messaging system for communicating between computers and the like with heterogeneous and universal interfacing between distributed applications and processes residing in a wide variety of differing computer platforms and
communications transport facilities of various types, having, in combination:
means for providing between an application/process and a communications facility a set of single-function software modules controlled by a preselected set of verbs that together provide a single application programming interface through which
application programs/processes can directly access the electronic messaging by an interface control block;
message routing means controlled by the application programming interface control block for staging messages and data flowing from and to the sending and receiving computer applications/processes by a router control block for determining message
handling and communications transport facilities, and monitoring the message delivery status;
communication agent means, one corresponding and connected to each communications transport facility, controlled by common communication management means connected to the routing means and responsive to its said router control block to control
the message flow from each communication agent means to its corresponding communications transport facility independently of and without user concern for the specifics of the various communications facilities and their characteristics; and
means for enabling the verbs of said application programming interface modules selectively to effect one or more of the following functions:
COMMIT, to inform the routing means that a complete message has been successfully received and processed as required, and that the message and its related queue data may be released;
DELETE, to remove one or more selected messages from a specified queue regardless of priority, pending or active state, or whether receipt has yet been acknowledged;
FREEBUF, to release data/storage and queue entries when no longer required;
GET BUF, to allocate resources such as internal memory needed to support message sending and status services;
INITIALIZE, to connect the calling application or process for electronic messaging;
PURGE, to remove all of the messages from any local queue regardless of priority and pending an active state;
RECEIVE, to deliver an incoming message to destination application and to queue the message traffic awaiting delivery and priority to such destination;
SEND, to place a message into routing queue for eventual sending to the specified destination;
STATE, to inquire about or alter the state of any local routing message queues;
STATUS, to inquire about or alter the status of any message in the named message sending queue and to obtain the number of messages in such queue; and
TERMINATE, to resolve latent messages before application exit and then terminate the application connection to the routing message queue;
said routing means including
means for maintaining a given message and associated data in a queue,
means, responsive to said COMMIT verb from one of the receiving computer applications/processes that received the given message, for (a) generating an acknowledge message and communicating the acknowledge message to one of the sending computer
applications/processes, and (b) releasing the given message and any queue data said particular verb, thus supporting the ability of one of the sending computer applications/processes to specify that delivery for the given message is to be guaranteed,
regardless of whether the communications transport facility that carries the given message supports guaranteed delivery. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
The present invention relates to electronic messaging systems and
techniques for providing messaging services between applications and processes, being more particularly concerned with providing a universal or generic approach for interfacing distributed applications and processes residing in a wide variety of
computing platforms, and enabling communicating over one or more transport facilities as desired--providing for use within a multimedia, multi-platform and multi-network computing and communications environment.
BACKGROUND OF INVENTION
Though the term "electronic messaging" has come often to be interperted as synonymous with "electronic mail", in the context of the present invention and this application, the term "messaging" is used in a much broader sense encompassing also any
type of content; namely, the encapsulation of any data objects--text, graphics, data, digitized voice or image or the like--together with delivery, utilization and identification information that is needed to produce at each final destination, those
activities specified by the encapsulated content.
Heretofore, individual and specially tailored software has been required for interworking and integrating distributed applications and processess and linking stand alone applications. The different computer platforms have required differently
designed data/message transfer treatment and linking programs and processes running in a variety of environments and with a variety of communications types or media, all specifically tailored to the particular equipment networks and protocols--and each
being restricted to and useful for its environment only.
Underlying the present invention is the surprising discovery that despite such wide and often disparate variety of equipments, networks, protocols, platforms and communications techniques and environments, each requiring its individualized
treatment, there can be a universality or generic approach to the programmatic interfacing or underlying message/data transport and recovery services that can indeed provide consistent, seamless and transparent connectivity betweeen applications and for
processes residing in widely different computer platforms linked by a variety of different networks and protocols. This is referred to herein as heterogeneous connectivity for distributed applications and processes, with the electronics messaging
systems concept of the invention being referred to as "EMS".
The highly novel approach of the present invention to attain this seemingly impossible task resides, in part, in an integrated set of software lower-level programs and routines that handle specific services-message/data recovery, security,
directory services, etc., available from applications and processes within varied complex computing and communications environments, and without having to deal with the idiosynchrasies of differing networks, protocols, devices, multiple "standards",
routing, recovery and other transport difficulties and differences. This is effected in EMS, by isolating applications and processes from the increasingly confusing and fast-changing communications environment, as well as from differences in varying
computer operating systems, and platforms and hardware.
The inherent problems underlying implementing communications programs between computer systems, make it very difficult to handle all of the idiosynchrasies of different hardware, operating environments, protocols, and networks. Maintaining
appropriate software as operating systems are upgraded and new communications features come to market is nearly impossible--especially when communications are embedded in application programs.
To obviate these difficulties, EMS has undertaken to provide:
a) message/data queuing and communications services separated from application programs and processes;
b) specifics of hardware and operating environment handled completely and transparently by the communications services facility; and
c) stable, consistent interface between applications and the communications environment that does not change every time a network or computing platform is added, changed or removed.
The invention achieves a solution to this increasingly common, complex and costly problem through insulating both the developer and the user from the vagueries of the communications facilites and networks and from the specifics of the operating
environment and hardware. EMS also provides access to the widest variety of communication facilities. In addition, EMS tracks the status of a message, and, depending on the facilites on the receiving side, can guarantee delivery to the destination
application.
Through the novel approach of the EMS technique, a middleware toolkit is provided consisting of a programmatic interface and underlying message/data transport and recovery services that together provide the before-described consistent, seamless
and transparent connectivity between applications and/or processes that reside in different computer platforms linked by different networks and protocols. The term "middleware" is used to connote a layer of software located between the networks,
protocols and transport facilities available on a computing platform, and the applications or processes that require transport of messages and data to and from applications and processes on different computing platforms. The integrated set of
lower-level programs and routines that handle specific services-message/data recovery, security, directory services--within a complex computing and communications environment and that constitutes the "tool kit", enable
Guaranteed data/message transfer--managing the transmission and receipt of messages and data so as to ensure absolutely that these are received by the intended destination;
Most communications media supported--types of communication; media supported range from asynchronous dial-up modem communications to wireless RF services, such as ARDIS and RAM. Where there is a choice of media to use, EMS assists in deciding
which one to employ.
Most popular computing platforms supported--EMS software runs on most of the popular computing platforms to enable developers to link programs and processes running in a variety of environments.
Present day data communication systems mandate one type of protocol to get all the data across. The present invention, on the other hand, provides a scheme at the communication layer that allows for the management of multiple communication
facilities simultaneously. Upon losing one communication facility type, another communication facility type can be picked up to continue the sending of information. A management facility that manages what is called communication agents, attached to
each type of communications facility, recognizes when and what is available to be able to transmit data. It takes a packet of information, regardless of whether it all belongs to one message or is in different messages, stages it for delivery, and hands
it off to the proper communication port that is available at that point in time, moving the data through in a continuous pipe or stream. By segmenting the message into logical units of data related to one another by headers, if a communications
facility, (for example TCPIP) is lost after one segment is sent, any other routes or communication facilities available to the environment are identified, and the next piece of data will accordingly be sent along such, following preset guide-lines. An
upper layer protocol recognizes that data is related, but that it has been fragmented, sometimes oddly. It must be interperted, extracted and fitted together. Just as when analyzing proteins in genetics, when fracturing, it is desired to know what is
missing from the chain so as to rebuild the chain to create the gene. In similar fashion,in acccordance with the invention, a piece of missing data that fits in somewhere within the data chain can be requested by the receiving end from the transmiting
end, no matter what the protocol that is being used, enabling interdisbursement of the movement of information or packets that belong to a single unified piece of information--and across multiple paths and communication types, from end to end, and
without the application having to know anything about the communications facilities. Additionally, the present invention can run on multiple operating systems with exactly the same interface being presented to the application or the process or the user
of the system. All of the specific devices, communications facilities and memory management are hidden from the users, providing a novel minimal consistent communication environment sitting on top of the operating system and facility.
OBJECTS OF INVENTION
An object of the present invention, accordingly, is to provide a new and improved method of and system or apparatus and controlling software for electronic messaging that provides heterogeneous connectivity and a measure of universal or generic
interfacing for distributed applications and processes residing in a wide variety of different computing platforms, communicating over one or more different transport facilities.
A further object is to provide such universal connectivity through the technique of isolating applications and processes from the communications environment with an integrated set of lower-level programs and routines that handle specific
services-message/data recovery, security, directory services, etc.--within complex computing and communications environments without dealing with the idiosyncrasies of differing networks, protocols, devices, multiple "standards", routing, recovery and
other transport problems.
Other and further objects will be explained hereinafter and are more particularly delineated in the appended claims.
SUMMARY
In summary, however, from one of its broader aspects, the invention embraces a method of electronically messaging between computers by heterogeneously and universally interfacing distributed applications and processes residing in a wide variety
of differing computer platforms and communications transport facilities of various types, that comprises, providing a set of single-function software modules controlled by a preselected set of verbs that together provide a consistent application
programming interface between the application/process and the communications facility and through which application programs/processes can access the electronic messaging; under the control of the set of module verbs, first queuing and routing messages
and data flowing from and to the sending and receiving computer applications/processes and monitoring the delivery status thereof, and then communicating the routed messages and data through a communication agent for each communication transport
facility; and providing common messaging functions for all communication agents independently of and without user concern for the specifics of the various communications facilities and their characteristics.
Preferred and best mode designs and details of system construction and operation and modified forms thereof are later presented.
DRAWINGS
The invention will now be described with reference to the accompanying drawings, FIG. 1 of which s a block diagram schematically illustrating the EMS messaging services and functions in accordance with a preferred embodiment of the invention;
FIG. 2 is a similar diagram illustrating the messaging system of the invention within a communications environment;
FIG. 3 is a messaging process diagram tracing from (1) start-up and initialization of the EMS systems, through (2) sending messages, (3) checking status, and (4) receiving messages;
FIG. 4 is a diagram similar to FIG. 2, but showing the message header (EMH), router control block (RCB) and interface control block (ICB) locations;
FIG. 5 is a block diagram showing the sending receiver computer messaging through a network or other transport facility;
FIG. 6 is a combined apparatus and flow diagram illustrating the outgoing messaging process and steps;
FIG. 7 diagram of the incoming message processing;
FIGS. 8 through 17 are operational flow charts of steps carried out by the software in effectuating the API control verbs COMMIT, DELETE, FREEBUF, GETBUF, INITIALIZE, PURGE, RECEIVE, SEND, STATUS and TERMINATE, respectively; and
FIG. 18 is a chart summarizing the current heterogeneous connectivity features of the present constructions of the invention for a variety of existing commercial platforms and communication protocol/ network systems.
DESCRIPTION OF
PREFERRED EMBODIMENT(S) OF INVENTION
It is now in order to describe how the novel results of the present invention are attained in integrating into each application that will use EMS messaging services three main steps. First, designing a messaging user interface to each particular
application/process that satisfies the requirements of its users, and which determines how the particular programs will utilize EMS messaging capabilities. Secondly, integrating EMS into each application/process using EMS automatic programming interface
(API) verbs. In general, this requires only the loading of a data buffer with message and message processing instructions and calling the appropriate verb, with linking procedure on the particular platform providing access to the EMS automatic
programming interface API verbs. Thirdly, configuring and testing EMS, using appropriate testing guidelines. In general, the manner in which EMS is used will be the same across all platforms and environments, differing only where platform requirements
make such differences unavoidable.
The technique or method underlying the invention provides all of the tools needed for intelligent delivery of data between applications and processes by a simple, consistent programmatic interface rather than dozens of network, protocol and
device complexities. If communicating applications or processes change from mainframe to a Unix box, no change is required for applications and processes. EMS simply uses the change in address to redirect data and messages through the new set of
interfaces.
A full range of queuing, communications and related services are accessible through EMS, but these can be selected and used only as needed. In each computing environment, the EMS API calls remain the same, so that no changes to the calls are
required when migrating from one platform to another. The invention, moreover, supports most of the major wireless services, media and protocols as well as those on wireline networks, allowing developers to use EMS as a tool for integrating applications
and processes that communicate across multiple networks.
More specifically, EMS provides a single, consistent programmatic interface to access the queuing, communication and related services for multiple external and internal communication networks, protocols and transport facilities. Neither the user
nor the application developer needs to be concerned with the specifics of various communications and network protocols and the characteristics of hardware devices. EMS, indeed, supports both wireline (dial-up, dedicated line, and LAN) and wireless
(radio frequency--RF and cellular) connection devices. These interfaces may be internal to the user organization or to public or private networks. Communication among processes on the same computer are always supported. The communications interfaces,
moreover, may be installed in any combination for which they are available in that environment, supported by the hardware and operating system, and providing a unique commmon message switching application across this breadth of operating environments.
EMS automatically selects the proper communications medium to use, although the user may override the default section. In either case, EMS takes care of all the message and network-level protocols on behalf of the user and/or application, providing
transparent communications selection and operation.
As before stated, the invention handles both outgoing and incoming queuing of data or messages on behalf of the application or process. This means that the user does not have to wait for a communications mechanism or facility to become available
to send data or messages. Similarly, data/messages can be received in background while this or other applications and processes are running. As appropriate, both memory and disk queuing are supported to provide for automatic restart.
EMS, furthermore, is configured at installation time with various defaults. It may be reconfigured at any time without shutting down either the application or process or EMS itself.
Referring to FIG. 1, EMS is shown installed in a simple system with two different environments I & II communicating across three separate network/protocol facilities 1, 1' and 1'. The basic internal structure of EMS, interfacing multiple
applications or processes, so labelled, and various communications facilities A,B and C, is shown comprising multi-media messaging, multi-network protocol, security services, full recovery, multi-platforms, directory services, guaranteed delivery,
encryption/decryption and compression functions, later more fully described.
As previously mentioned, the EMS for each environment consists of a set of toolkit modules tailored specifically for that environment. As more particularly shown in FIG. 2, the basic EMS modules are the following:
Application Programming Interface labelled (API)--a set of single-function software modules, or verbs, that together provide a consistent interface through which application programs/processes can access the EMS communications services.
Queue Manager/Router ("Queues"/"Router")--stages messages and data flowing to and from the application/process and monitors the delivery status of each.
Communication Agents ("Comm. Agent" or "CA")--one for each different network, protocol or communication transport facility. (shown as "Communication Network" "A" "B" & "C").
Communication Manager ("Comm. Manager" or "CM")--provides common messaging functions for all the communications agent present.
Configuration Manager ("Config. Mgr." or "CFM")--supports dynamic reconfiguration of EMS; automates the decisions for which communication medium and port to use and monitors availability of communications facilities.
Configuration Utility ("Config.")--assists in software set-up and installation.
User Status Utility ("USU")--allows the user to view queues and other status. User Configuration Utility ("UCU")--allows user to manage available communications resources. Any number of nodes may be linked by communications networks and
facilities using the EMS of the invention.
Considering, now, each of these modules in more detail, the application programming interface API, as before stated, consists of a set of verbs provided as callable routines for user programs. There are preferably three basic verbs in the API
corresponding to the three main functions required to handle message transfer and receipt:
SEND
RECEIVE
COMMIT
The function of the COMMIT verb is to finalize the message receive process once all segments of the message have been confirmed as received by the destination EMS. In addition, four message utility verbs are provided to help manage messages and
message queues:
PURGE
DELETE
STATE
STATUS.
A final set of four environment utility verbs handle essential functions related to resource allocation and deallocation:
INIT
TERM
GETBUF
FREEBUF
Together, these few verbs are able to provide a powerful, flexible and consistent programmatic interface across multiple environments.
The Router of FIGS. 2 and 4 is a background process which runs in support of API calls for data and message transmission, delivery and status, and as a server for the User Status Utility. The Router manages both disk-based and memory-based
queues (for outgoing and incoming data/messages) and sets event flags, depending on the environment, to notify applications of message status changes. It also manages timed events for messages in progress, again depending upon the environment.
On startup, it rebuilds its queues from the disk-based save files. On shutdown, it stores messages which have not been completed and which have been designated as saveable to the disk save files.
For incoming messages, if the application for the designated user is not active, the EMS Router may request the EMS Configuration Manager CMF to start the application process so that the incoming message can be delivered.
Each Communication Agent (CA), FIG. 2, is specific to the communications hardware and network to which it will attach and to the particular EMS operating environment. Each CA is structured in similar manner to handle the line, RF device or other
transport facility. On the EMS side, it passes messages to and from the Communications Manager (CM). Each CA, moreover, may operate as a driver or as an independent process, depending on the operating environment.
As for the Communications Manager (CM), this component provides a set of common routines or independent processes used by all of the communication agents. The CM strips or adds any required control data for the environment to the received
message (may contain network control data and message contents). The CM, furthermore, may be an independent process or a library (i.e. a Dynamic Link Library--DLL) depending on the environment in which EMS is installed.
The User Configuration Utility (UCU) of FIG. 2 provides an environment-specific process for the person maintaining EMS to install and maintain the various parameters EMS employs to manage the communication resources available. UCU is run as a
major part of the installation procedure to provide the initial defaults to the system. It may then be run on demand to up-date the defaults and to introduce new facilities and routing.
Lastly, Configuration Manager (CFM) is a background process (or common library routines, depending on the platform) which runs in support of the Router, the User Status Utility (USU), and the User Configuration Utility (UCU). The CFM accesses
configuration file(s)to determine service and communication agent to use for the delivery of a message, and other default parameters. It is also a server process for the environment-specific user utilities. The CFM, indeed, is the "start up" process
for EMS, starting up all of the other background proce | | |
