GEMt is designed to provide a high level of visibility,
control and management of content-related activities. The system
is based on a model found, in one form or another, in most high-performance
publishing operations; the "work group". Publishing work
groups, consisting of perhaps 5 to 50 authors and editors dealing
with a common information challenge, have unique functional and
productivity requirements not seen in larger, more diffuse situations.
GEMt was designed to fully support these unique requirements within
work groups while maintaining the proper level of communication
and collaboration among work groups. In large organizations,
GEMt is deployed as a network of mini-systems, providing both
intense focus on the needs of each work group and a fluid, easily
managed global environment capable of easy. GEM's architecture was
designed directly from a thorough analysis of user/manager requirements,
not, as is usually the case, from a selected technology.
In its design, GEMt addressed a number of specific
architectural and operational goals including:
High level support for each user's editorial and production
requirements. GEM's design acknowledges that, in publishing, each
user group has a unique set of needs which must be fully supported
if the effort is to achieve its productivity goals. Moreover, authors
and editors are often the most critical and expensive resource an
organization possesses. To deliver highly targeted support to users
across a wide spectrum of environments and publishing challenges,
the GEMt architecture can be "tuned" to each set of needs
without major expense of reprogramming or modification.
Provision of a secure editorial environment
based on the "work group" as the primary organizational
and functional unit. GEMt bases all activity control and user access
on this basic unit. All privileges are set in three modes: data
owner, in-group user, and external user. The system provides for
"cross-group" communication through acceptance of access
requests by the called group. This ensures that control of data,
processes and user access always remains with the data owner.
Economical use of the user's system resources
to minimize both the potential for contention among users and groups,
and the incremental cost and risk of system expansion across multiple
staff organizations. GEMt operates on a "thin application"
model, requiring network connection and traffic only when actually
necessary. In addition, the GEMt server software can operate on virtually
any machine available to the work group and can even be moved during
operation without loss of control by connected users.
Minimum cost and risk associated with
maintenance and expansion through effective modular design, structured
coding and simple integration with other components of the user's
computing and network environment. Because GEMt is never the only
resource in the user's operation, it was designed for easy, transparent
interface to other components.
2. GEM'S Functional Design Basis;The
"Event":
The GEMt System and all of its component software
modules are designed on a single conceptual base; the "event".
Events in a GEMt environment are the combination of actions that
can occur, the users and data objects involved in those actions,
and the circumstances in which the actions are permitted. This section
provides a brief description of the event concept and the primary
ways it underlies the design of the GEMt System software and data
architecture.
Definition and Description of "events"
in the GEMt System:
The "event" is the basic unit of communication among GEMt
System software components. Events are generated whenever some action,
usually involving files and users, meets established criteria indicating
that it should be controlled and communicated to other parts of
the system. The normal model for events involves a request record
created by the initiating software and a response record, indicating
either success or rejection by the software process responsible
for its completion. All event request and completion records are
made up of some combination of the following elements:
All events, even those requested by client software,
are approved and monitored by GEM. When an event is completed in
this way, the system generates and stores (logs) a "completion
descriptor" record containing a combination of these data elements
appropriate to the type of event. In this way, a common path exists
for definition, creation and processing of all important events
and their resulting descriptions.
The Role of Events in GEMt System Architecture:
Events and their management play a major role in GEM's ability to
deliver a wide variety of needed functions to its users without
losing the benefits of a fully open systems architecture. By rigorously
defining events, their sources, destinations and processes contingent
on them, GEMt can be physically constructed as a series of loosely-integrated
software modules yet can function as if it were a single, tightly-coupled
system. In a GEMt architecture, virtually any process can be sited
on any machine, yet the system operates as if it were all on a common
machine.
The contents, pathways and processing points
for events are defined and modularized, simplifying system evolution
and minimizing risks. As new or different functions are required,
new or expanded events may be defined and new processes attached
to them without major modification to system software elements or
user interfaces.
Event Management Software (the GEM content
server): The GEMd content server operates in
either UNIX or Windows NT/2000 environments, providing equivalent
functions consistent with each. The GEMd has primary responsibility
for managing events in the GEMt System. Each work group in a system
environment has its own GEMd process and all communication among
groups is managed by links between these processes. The GEMd supports
six primary functions:
Controlling user and process privileges to initiate
events against files and other system contents. The GEMd has access
to all necessary data and configuration files to approve or reject
events requested by any user or external work group.
Receiving event requests and notifications from
work group client processes and external work groups, determining
what, if any, actions it must take and properly completing those
actions.
Recording and applying user privileges. The system
recognizes user privileges for each function at four distinct
levels:
access to files and functions in the user's home queue.
access to files and functions in other queues within the
user's work group.
access to files and functions within other groups.
access to files and functions anywhere according to granted
exceptions to the above privilege classes.
Maintaining a history of events, both in memory
and in a backup file, for use in monitoring production flow, bringing
newly logged users up to date, and in recovering from any interruption
in service.
Maintaining contact with other parts of the overall
system via a gateway function under which certain defined events
are communicated to one or more external work group GEMds.
Evaluating event completion characteristics against
defined Event Dependent Processes (EDPs) and, when appropriate,
initiating those processes.
Client Software: In the GEMt System, the "client"
is the editorial user at his or her workstation. "Client software"
operates in direct support of user activities and is directly controlled
by the user. There are two major types of client software employed
in the GEMt architecture. This section describes these software types,
the roles they play in user support and the interaction between
them and with other parts of the system:
The GEMt Client Module:
This software module operates with or within the selected editor
software in each client workstation. GEMt currently supports the
ADEPT or Epic editors from Arbor Text and can be expanded to work
with other full-function XML or SGML editing software. It is responsible
for the client's interaction with the local work group's GEMd
and with other parts of the GEMt system software that interact
with or are impacted by its GEMd operation.
The client software module provides the workstation with a single
point of control for all external interaction, simplifying the
editorial environment and making change and enhancement easier.
It performs the following specific functions in editorial operation:
Establishing communication with the GEMd at session
start and determining the proper group ID for use in file creation
and storage.
If the GEMd terminates and is restarted during
an editorial session, this software is also responsible for
location of the new GEMd location and reconnecting without loss
of control or user data.
Building and forwarding "event request"
records to request that the GEMd approve and complete various
events related to files open in the editor, including file creation,
command line initiated file edits, saves, stores and aborts.
Controlling workstation participation in restart
of the system after abnormal termination of GEMt operations.
The GEMt client maintains detailed backups of
editor activity and restores backed-up files in the event of
a system crash.
The GEMt Client Interface:
This sub-system, illustrated in Figure 2, provides the user with
primary support for group, queue and file-related functions. It
works with both the editor and downstream production processes
to allow the user to locate, access, monitor and operate on any
data in his or her group. In addition, the GEMt Window, through
interaction with its local GEMd, provides users with controlled
access to groups outside their own. The GEMt
Client Window software module is responsible for the following
major functions:
Establishing communication with the GEMd at
session start and determining the proper group ID for use
in file creation and storage.
Building and forwarding "event request"
records to request that its GEMd approve and complete various
file-related events, including file sends, file copies, file
renames, exports to external processes as well as reservations
and locks pending completion of these and other processes.
Receiving and filtering incoming communications
from its local GEMd, determining the proper disposition of
these communications and notifying the user of the results.
Establishing and maintaining communications
with the editor client software to monitor user activities
and submit user commands, initiated in the GEMt Client Window,
to the Arbor Text application.
Major GEMt User Functions:
The GEMt client supports all data and process related functions
required in newsroom operation. The most important of these are
summarized below:
Edit one or more files, locking them
to other users for all but read-only access.
Copy a file in the same queue, maintaining
file name uniqueness.
List the contents of selected queues
in various sequences and formats. This function can inspect
the contents of listed files, reporting data that exists in
the XML structure.
Switch the client process into a selected
queue.
Rename one or more files, maintaining
file name uniqueness.
Send the master copy of a file to another
queue.
Send a copy of a file to another queue,
maintaining file name uniqueness.
View the contents of a selected files
in formatted mode without editing the file.
List groups, queues and users in the
system.
Find a file anywhere in the system and
report it location and user privilege status.
These major functions are supported via button and
menus on the client window. Each
command may also be entered at the command line.
3. GMAT, GEM's Management Administration
Tool:
The GEMd Management Administration Tool (GMAT)
is a system-level utility application designed to provide visibility
and control of critical system elements and processes in the GEM.
The GMAT operates by "attaching" itself to any GEMt server
process in the systems environment. Because the GEM-System software
module is responsible for management of all activity in a system
group, GMAT is able, through this attachment, to gain access to
the major configuration files describing the group, its component
queues, files and users. Once this access has been established,
the GMAT can report status of all major processes in the group,
display the settings of all major configuration parameters and make
limited changes without making the system unavailable to users.
In addition, GMAT can monitor the operational status of every group,
queue and user, initiating corrective actions when needed without
interrupting the flow of work elsewhere in the system.
GMAT Functional Architecture Summary:
GMAT is available to users with the appropriate
administrative permissions. When the GEMt icon is clicked, the software
is in an "unconfigured" state, having selected neither
a function to be performed or group in which to operate. The body
of the panel lists all of the available functions in the GMAT application,
illustrated below:
Add a new group
Add a new queue to a selected group
Add a new user to a selected group
Modify an existing user's access privileges
Delete a user from a selected group
Manage (monitor, start, stop operation by
group) Groups
Monitor and clear file reservations by group
Monitor and clear file locks by group
Exit GMAT
The user may pick
any transaction option by clicking on it with the left mouse button.
The GMAT software then calls the appropriate series of modules to
start the desired function.
4. Event Logging and Management in GEM:
The GEMt editorial environment supports a high
level of inter-user and inter-group communication, including sharing
of file contents, dissemination of file copies, file renaming, etc.
In operation, these activities are managed by a series of software
modules, responsible for approving, completing and recording each
event. An important aspect of the overall process is the creation
of "event log records" by these software processes. Event
log records capture the important characteristics of every event
processed by the system, making it possible to recreate and analyze
system activity and to support effective management of work flow
and production status. In addition, log records form the baseline
data resource for implementation of extended applications including
content history, data object sharing and editorial workplace management.
Event log records are written to a common system
log file, using a simple data structure designed to enable indexing
and easy access to log data for processing and display. Each event
record includes a series of elements appropriate to the nature of
the event it describes.
Access to Log Data: As event log records are created by software
processes, they are collected and processed to make them available
to the applications that provide visibility into system activities.
This section summarizes that collection and processing. The GEMt
System supports two major modes of log data access:
User access: This mode of access is designed to provide
system administrators with visual and logical access to the contents
of a log database for the purpose of analysis and activity monitoring.
Accordingly, the user access applications are designed around
interfaces supporting the designation of data and display modes
to be employed.
Application software access: This access mode is provided for system
applications to query the log database for specific data elements
to be used in processing. Application access to log data is not
supported by a user interface and normally does not directly result
in visual communication to a user. However, log data retrieved
in this way may become part of the interface presented by the
calling application.
5. Event Dependent Processes ("EDP"s)
in GEM:
Control of "special functions" is
one of the most difficult and potentially expensive aspects of content
management. No single system, GEMt included, comes with all of the
unique functions required by every user. Many systems provide complex
APIs (application programming interface) requiring the creation
of "C" or Java programming to design and build these site-specific
functions. Indeed, the customization of functionality is often the
largest cost, in time, money and staff, associated with the adoption
of a content management system.
GEMt was designed to support this requirement
without the cost or complexity normally associated with functional
customization. The GEMt architecture provides a powerful resource
by which custom processes may be designed in any language desired
and linked to the system via a device called the Event Dependent
Process or EDP. EDPs are user designed software functions that are
triggered and controlled automatically by the completion of events
in the system. EDPs may be programs created by in-house staff or
may use vendor software. When an EDP is installed along with its
appropriate activation control data, the system constantly monitors
events to determine when and how to trigger its operation. Once
activated, an EDP is further controlled by parameters generated
by the triggering event and passed to it by the activation software.
In-house EDPs may be created in virtually any
language that supports a command-line interface. To maximize their
effectiveness and integration into the overall GEMt operating environment,
EDPs are typically designed to be fully independent "background"
processes requiring no user interface or additional system information
once activated. In this way, users and processes involved in triggering
an EDP need not concern themselves with its completion. This design
philosophy also allows for some flexibility in the scheduling of
EDPs. For example, certain non-critical EDPs, once triggered, can
be queued for operation later in the day when system load is lower.
Event Dependent Processes operate under
the following circumstances, controlled by the GEMd software module:
1. EDP Definition and Activation:
a. A single EDP may be "attached"
to one or more queues within a Work Group. b. EDPs may operate across Work Groups, i. e., an EDP defined
and triggered within a single Work Group (GEMd) may reference
data and events in other Work Groups providing that the proper
privileges are in place to permit the desired action. c. EDPs are "triggered"
by a two-level process composed of:
1) Triggering file event: This is the primary component
of the EDP activation process. A file event must involve the
completion of a system action in which a data file, either master
or copy, arrives in a system queue. The system detects file
events from a central location in the group's GEMd software
module, evaluating the event completion codes of all system
events against a configuration table in memory. These event
codes are assigned by the software procedure responsible for
completing the system action and are passed to the "event
management" software resident in the GEMd module. File
events include but are not specifically limited to:
First entry of a data file master or
copy into a named or any queue.
First entry of any copy of a specific
file into a named or any queue.
Any "release" of a file back
to a queue at the close of an editing session.
Completion of a file rename within
a queue.
Creation of a file copy within
a queue.
Participation of a specific user
in an event.
When any of these primary file events occurs
within a group to which one or more EDPs are attached, the system
matches its event code against each stored EDP definition. For
any matches, the system activates the second phase of the EDP
process, the application of event constraints.
2) Event Activation Constraints:
This component of the EDP triggering process
provides for the definition of specific conditions under which
a file event actually triggers an EDP. When a file event completes,
the system checks it against the Activation Constraint Table.
The EDP software will be activated only if the characteristics
of the event satisfy the constraint values.
3) EDP Processing Control:
Once an EDP procedure has been activated
by the GEMd Event Manager, it operates independently, under
its own control, using the data passed to it by the GEMd Event
Management process. This data, described above, provides an
additional means of controlling the operation of the EDP.
EDPs may use the contents of arguments set
by the GEMd event manager: When an EDP procedure is invoked,
any or all of a series of system variable arguments may be
named in the Activation Control Record (see Figure IV-2.)
These arguments, once named in the execution statement, are
made available to the procedure to be used in processing.
The arguments available in this process are set by the GEMd
procedure (GEMd_event.tcl) responsible for evaluating EDP
Activation Control Records against each completing event.
In this way, programmers may establish and exercise a degree
of logical control over EDP processing from within the procedures
themselves.
Within an EDP procedure, processing
may be conditioned on or modified by "data events."
Data events consist of the presence, absence or specific values
in SGML elements within files passed to an EDP procedure.
By using data events, an EDP programmer may "trigger"
the EDP procedure for a broad category of files and events
then, once the EDP procedure is started, further refine the
operation of the software within the procedure itself. While
data events can be defined for virtually any element in a
data file, the most useful and controllable include:
Presence of named SGML data elements.
Presence of specific content in named
SGML elements.
Presence of SGML attributes and/or attribute
values in named elements.
Use of data events allows the EDP programmer
to focus the conditions under which the procedure runs or
to actually cause a single EDP to perform different functions
depending on the characteristics of the file presented to
it and the system status at the time of presentation.
4) Programming with EDPs:
This section describes the major steps and
considerations involved in using the EDP facility to accomplish
utility and application functions not included in the basic
system architecture. It is provided with the goal of encouraging
programmers to use the EDP facility whenever possible, minimizing
the necessity of writing external standalone procedures to operate
on system contents and variables.
When to Use the EDP Facility: EDPs provide two major facilities:
They enable the logical association of desired
file-related processes and the system variables employed to
accomplish them. These variables include file names, queues,
user Ids, events and processes.
They provide a consistent and easily managed
means of manipulating system resident data files within the
controlled software and management domain of the system environment.
This is an important integrity factor given the critical nature
of file and system data and the complexity of the system environment.
Creating an EDP:
Every EDP has two major components, each
the responsibility of the programmer to design, implement and
maintain:
The Activation Control Record (ACR): Defining
when and under what conditions the EDP will be activated by
the event monitoring section of the GEMd. Figure IV-2 describes
the construction and role of each element of an ACR.
The EDP procedure code: Providing the actual
software coding that will accomplish the desired results.
This section describes the character and use of these two
components.
1) The Activation Control Record:
ACRs, detailed in figure IV-2, provide a
machine-readable definition of all necessary information for
the GEMd to evaluate every event completion logged in its domain
and, where appropriate, to activate appropriate EDPs for a file
involved in the event. Event monitoring in the GEMd occurs on
a file-by-file basis so EDPs are always activated for a single
file even though it may be one of a series or type of files
involved in the same process. Likewise, each ACR can activate
only a single EDP. If more than one process must operate in
sequence on a file, one of two approaches must be used to satisfy
it:
a) multiple ACRs may be entered,
each one calling a single procedure to accomplish part of
the total task b) all required process steps
must be made part of a single, "macro" EDP.
2) EDP Procedure Code:
EDPs are small, self-contained programs
used to accomplish one or more tasks associated with files and
their system circumstances. EDP may be written in any programming
language approved for use in the GEMt software environment, including
(but not limited to):
Tcl/TK
Perl
"C"
OMNIMARK
EDPs may be operated either as compiled
code modules or as interpretive source files. However, simplicity
and maintenance are enhanced by the use of interpretive scripts,
obviating the need for maintenance of both source and executable
files. Accordingly, wherever processing speed requirements allow,
interpretive EDPs should be considered the preferred approach.
Although the specific construction of the EDP procedure code
is at the discretion of the programmer, adherence to several
general guidelines will provide for optimum functionality and
maintenance of EDPs.
a) Choice of programming language:
When choosing a language in which to create
an EDP, the programmer should review the goals of the procedure
and, where possible, select a language which is both adequate
to the task and in harmony with the way similar tasks are
addressed in the systems environment. Additionally, EDPs should
be developed in a manner that makes them as easy as possible
for others to understand and maintain should that become necessary.
5) Use of GEMd API Software Procedures
in GEM:
In developing the code for an EDP, the programmer
will often encounter the need to monitor system variables and/or
accomplish data and file related tasks. In addressing these
needs, the programmer should be aware of the API procedures
provided with the GEMd software environment and should use them
wherever appropriate. There are two reasons for this:
Use of the pre-written APIs will materially
simplify both the programmers' development task and, because
APIs are updated as needs and system architectures evolve,
minimize the need for subsequent maintenance of the EDP software
source code.
APIs have been tested and debugged to properly
and fully address their intended actions, minimizing the chance
of erroneous processing due to incomplete or incorrect design
of complex system actions or measurements.
d. Communicating with Users and Other Software
Processes: When it is necessary for an EDP process to communicate
with other system tasks or users, the following approach should
be used where possible:
Communications with users may be accomplished
via the user's corporate email system or the GEMt messaging facility.
This is true because, although EDPs may be triggered by actions
in which a user is directly involved, they run as background
processes and cannot be assumed to start or complete immediately
upon the user's action.
Communication with other software tasks
in the system environment should be minimized because no guarantee
can be made that the intended recipient task will be active
or capable of receiving communication when required.
e. Location of EDP Software Procedures:
The software code of an EDP may be physically
located anywhere in the system. This is true because the EDP Activation
Control Record (ACR) contains the full path of the software it
seeks to launch. It is, however, the programmer's responsibility
to ensure that EDPs are located in a manner that will optimize
their activation and completion, as well as making their support
as easy and straightforward as possible. For example, to ensure
that all EDPs can be easily located and managed, a central directory
location, at either the environment or group level, might be established
and all current EDPs stored there for
activation.
6. User Access Management and Workflow Control:
It is critical to ensure that users working
with the system are able to gain access to all parts of the system
appropriate to their tasks, while effectively preventing unauthorized
access where it is not appropriate or justified. This section describes
the philosophy, architecture and technology employed in controlling
user access to data and processes within the GEMt System. In addition
to a well-controlled environment in which users interact, GEMt's
access management facilities, working with Event Dependent Processes,
also provide the basis for an effective approach to workflow management. Currently, this approach to workflow control is in use by authors and management personnel in legal, news, training content and technical information applications.
GEMt enables the definition of processing and action paths based
jointly on user decision and allowed action. This contrasts with
the traditional workflow approach in which processing paths are
defined and user actions are forced to follow. While this more rigid
approach has merit in some applications (insurance claim processing
for example,) experience has shown that for most editorial tasks,
a less tightly defined approach works best.
In GEM, users are free to make appropriate decisions
at the end of each task, identifying appropriate next actions within
the limits established by the software's matrix of access privileges.
GEM's ability to assign privileges to users, data and functions
based on multiple variables allows this matrix to be quite specific
for each type of data and function in process.
The system recognizes nine discrete modes of
access, applied as an individual "access matrix" for each
user, defining the queues to which the user has access and the granted
modes of access for each of these queues:
edit files in a queue
copy files out of a queue
move files out of a queue
copy files into a queue from elsewhere
move files into a queue
view the contents of files in a queue
view the names of files in a queue
view the name of the queue in a queue list
rename files within a queue
switch to a queue, i.e., make it the user's "current
queue"
Access control within the GEMt System is managed
via patterns of these discrete privilege types granted to individual
users and user classes by the GEMd content server. By breaking overall
access down into specific access types, the system can be tailored
to satisfy a wide variety of user needs within the confines of a
single control mechanism. The potential complexity of managing nine
discrete access modes is addressed through procedural and software
tools to simplify the task of assigning and monitoring each user
and user group's access. All actual control of access is managed
by the GEMd software module attached to each operating group. Each
GEMd is responsible for control of processes against all data files
in its associated queues as well as certain general access functions
related to the ability of users to view queue-related data.
At system startup, each GEMd reads a series
of configuration files, building a matrix of processing and access
control parameters in memory. Once this is complete, any software
application in the systems environment can determine the validity
of a pending action by querying the appropriate GEMd via the "permissions"
API procedure. Upon receiving a query for permission, the queried
GEMd reports a valid or invalid status for the proposed action.
This "pre-validation" of permissions enables software
procedures to maintain control of their operation by determining
whether a particular action is authorized before attempting it.
When an actual transaction is attempted, the GEMd applies the appropriate
access control and rejects the transaction if it is not authorized.
This document describes the ways in which the
overall GEMt System access control facility can be used to support
effective system operation and outlines the procedures and tools
available to establish and manage effective access control for all
system operating modes.
1. GEMt System Layered Access Control:
The GEMt system approach to access management
is based on the definition and management of multiple layers of
user access to data and processes. These layers include, in order
of precedence:
Individual user assigned access
control- established and maintained in files related to each user's
home data directory. This level of control permits the assignment
of specific access privileges to any individual user, overriding
all other access controls including both assigned defaults applicable
to the class into which a user falls and system-resident access
control applied to all users. This level of access control is
assigned and modified through the "Add User" and "Modify
User Access" transactions within the GMAT system administration
tool. If no individual access control is established for a particular
user, the queue and system level defaults are applied as described
below.
Queue-related default access
control functions - maintained in system-resident configuration
files at the individual queue level, and applied by GEMt software
that reads and acts on these files. This level of access control
is established and modified via changes to queue-level configuration
files supported by the "New Queue" transaction within
the GMAT system administration tool. Queue-related defaults are
subordinate to individual user assignments as described above,
but supersede system resident controls (see below.) There are
two basic modes of queue—related default access control settings:
Default access for the owner of a queue.
Default access for all other "in-group"
users.
Default access for all other users.
"Kill" access privileges for one
designated queue per group. (The "kill" queue in
GEMt is used for file deletion)
System-resident "baseline" access control
functions—built into the core software of the system and
changeable only by modifications to system programs themselves.
This level of access control is subordinate to all other modes
of access control, providing a conceptual "baseline"
of access control, applied when no other parameters are present.
System-resident access controls are imposed directly by the system
software and are not modifiable without change to the system's
basic software coding within the system.
The following paragraphs describe the operation
and role of these three modes of access control in the overall
GEMt System access management approach.
2. Individual User Level Access Controls:
This is the highest level of access control
established within the system environment. Through its use, any
individual user may granted a pattern of access to any file, queue
and process in the system, overriding any defaults applied at
the system level or for general classes of users. User level access
controls are established within the group to which the user is
to be granted privileges, acting as a balance against the broad
range of capabilities inherent in this access control level. By
making user level access a privilege "granted" by each
affected GEMd, the possibility of problems or misuse is reduced.
Each user given broad access privilege must, in effect, "register"
with every group in the system to which he or she is to be granted
this access. In this way, the affected groups can identify and
participate in the granting of privileges to users outside their
membership. User level access controls are recorded in the This
level of access control is established through the creation of
"user access fields" in each group's "Group Configuration"
file USER records. This data, an integral part of the system configuration
and control facility, is read and stored in memory by the GEMd
at system startup or restart. Each USER record access field expresses
user level access controls as a series of fields as described
below:
The system ID for a user, either within or external
to the group, to which user level access privileges are to be
granted.
A queue ID within the group to which user level
access is to be granted to the user identified above.
One or more of the nine access modes (described
above in the Introduction) to be granted to the user for the
named queue.
Once these user access records are established
and placed in a group's configuration file, they are applied by
the GEMd , superseding all other access controls.
3. Queue-related Default Access Controls:
The default level of access control provides
a means of establishing default access patterns for each queue
in a group. These default access privileges are applied to entire
classes of users, obviating the requirement of recording them
in each user's individual configuration data files. This level
of access control is established through the creation of "queue
access default fields" in each group's "Group Configuration"
file QUEUE record. Each default access field contains a list of
the access modes to be granted all users in the class to which
it is directed (described below.) Once established, these records
become an integral part of the system configuration and control
facility read and stored in memory by the GEMd at system startup
or restart. Default access supports the establishment of general
access patterns in each queue, for four classes of users and queue
status:
The user who "owns" the queue: applicable
to "home" queues only.
In-Group Users: members of the group in
which the queue resides.
External Users: user who are not members of the
group in which the queue resides (essentially all other users.)
Designated delete ("kill") queue
for the group: this queue accepts files sent to it without
applying permission constraints to the sending user. This designation
means that any user in the system can send files to the kill
queue without having specific privilege to do so. This status
applies only to files sent (not copied) to the queue and does
not permit any other queue related actions without specific
privileges.
In system operation, the GEMd for each group
loads these default access control parameters and is responsible
for their application to all request activities and for reporting
them to other procedures submitting "permission" queries
in advance of attempting inter-group actions.
4. System-resident Access Control Functions:
This level of access control may be viewed
as the most secure of all system controls. It forms the baseline
level of control, modifiable in operation through supersedure
by assigned queue defaults or individual user assignment, but
virtually impossible to bypass in the absence of these factors.
Accordingly, it is intended for only those access control modes
which apply to the entire user population and which require absolute
security in their application. Any move to expand the number of
access control features supported at this level should be subjected
to close scrutiny before being adopted. Unless no other acceptable
means is available to accomplish the desired control, this method
should not be the choice. The following paragraphs describe the
access control functions delivered as part of the system at installation:
5. User Home Queue Access parameters:
Each user is designated a "home queue"
identified to the system through data in the user's configuration
file. Within this queue, the owning user has virtually unlimited
access for both data and processes. This comprehensive access
is mandated and maintained as part of the basic software code
rather than through assignment by one of the other two available
methods described below. It is applied as a baseline level of
access control, superseded by either assigned defaults for individual
queues or individual assignment of user access, but is always
applied in the absence of one of these other access control modes.
7. Content History ("Versioning") Management in GEMt:
GEMt provides a three-layer approach to the maintenance and management of superseded versions of content, illustrated below. This way of looking as "versioning" or content history management was developed after a searching analysis and extensive interactions with clients who face various shades of content supersedure.
Current Content Cycle Management: In virtually every organization responsible for creating new or revised content, the current cycle involves that period when revisions are entered, reviewed and finalized, often by multiple individuals and in a highly fluid manner. During this period, the traditional approach to versioning, the capture of snapshot versions of content as it is changed, can be cumbersome and difficult to control.
In GEMt, this period is treated as a unique phase in the content life cycle, supported by a mechanism more suited to its fluid nature.
For organizations wishing full control of the history of their content, the current cycle is supported by GEMt's Revision Management tool, allowing users to mark and manage revisions to the content on which they are working, including not only the old and revised versions of affected content but also a flexible amount of descriptive data such as who made the revision, when it was made, for what reason and, as it is reviewed for acceptance, the comments and decisions of its reviewers. Because this revision history is kept in the content itself, it becomes a stable component of the content available for analysis and recreation at any time. In addition, GEMt stores selected portions of this collected revision history in the repository so that it may used as the basis for reporting and research in support of editorial and production control.
"Recently Published" Content: Once a revision and publication cycle has been completed and the results are in circulation, a traditional "versioning" approach to content history becomes more appropriate. Of course, the definition of "recently published" can be set by the individual site and the system configured to perform accordingly. GEMt supports the maintenance of published versions of content on a document or collection basis, keeping the metadata describing the content in live, managed form so that users may interact with these versions at a level close to that for current content. These versions may be searched, viewed and opened so that users have the benefit of both content and revision history as they work on subsequent cycles. The system may be configured to allow or disallow a variety of transactions against published content, including restoring it as "current", editing it, etc.
Archived Content: This stage in the life of published content is up to the individual site; some may view all published material as "recently published" and have no archive phase, while others may archive content after only a short time. The primary characteristic of this phase in the content life cycle is the use of off-line storage to maintain the data. Typically, this involves the use of optical storage, allowing content to be located and restored upon request, but not interacted with in real time.
