Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Verification and Access Control in an Object Oriented System

IP.com Disclosure Number: IPCOM000121544D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 146K

Publishing Venue

IBM

Related People

Barrett, K: AUTHOR [+2]

Abstract

The Enabling Architecture is a general, modular, and flexible software architecture. The initial goal was to eliminate some of the fundamental limitations of OS/2* EE Communications Manager (CM) configuration; however, the software architecture described here is applicable to other products as well. Characteristics of the new Enabling Architecture include: - Unification of redundant architectures. - Support for a vertical team organization. - Facilitation of code reuse. - Support for multiple configuration files and configuration file formats. - Separation of the user interface from the configuration data. - Support for new function. - Implementation of an open architecture. - Preparation for later convergence with AIX*.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Verification and Access Control in an Object Oriented System

      The Enabling Architecture is a general, modular, and
flexible software architecture. The initial goal was to eliminate
some of the fundamental limitations of OS/2* EE Communications
Manager (CM) configuration; however, the software architecture
described here is applicable to other products as well.
Characteristics of the new Enabling Architecture include:
- Unification of redundant architectures.
- Support for a vertical team organization.
- Facilitation of code reuse.
- Support for multiple configuration files and configuration file
formats.
- Separation of the user interface from the configuration data.
- Support for new function.
- Implementation of an open architecture.
- Preparation for later convergence with AIX*.

      The Enabling Architecture is an architecture designed to meet
most or all of these goals.  It is an object-oriented architecture
consisting of two main pieces: a topology graph showing the
relationships between objects such as hardware information, user
data, configuration files, and the communications features installed
by the user, and a C API implementing the methods used to access the
objects in the topology.

      The architecture is not tailored for use only by configuration;
it can be used by runtime or by any code that needs to access the
objects without regard for how or where they are stored.  In fact,
the architecture does not even assume that the context is
Communications Manager;  it was designed to be generic, for
application in other areas as well.
VERIFY

      Verification is the process of determining whether or not the
configuration data entered by the user represents a legal
configuration of Communications Manager;  that is, the data obeys all
of the "rules" that must be satisfied in order for Communications
Manager to run.  Typical verify rules for CM include:
- "An LU name cannot be used by both a 3270 session and an SNA
gateway session."
- "Deep token-ring ports use a fixed 64K byte workarea that cannot be
exceeded."
- "If a PVC logical channel number has been defined, then the
corresponding PVC must be configured."

      In previous releases of CM, Verify was a single block of code
that contained the rules for all installed features of CM.  In
addition, the basic unit of verification was the configuration file;
that is, Verify was run against a configuration file, and tested
whether or not its contents satisfied all the rules.  If so, the file
was said to have "verified" and (theoretically) CM should run.  CM
would not run with a configuration file that failed to verify.

      In the context of the Enabling Architecture, Verify is a method
whose code is distributed among all the verifiable objects in the
topology.  The verify code associated with each Verify method is
different for each object type, defined by the creator of that object
type.  The algorithm for verification is recursive, and...