Abstract: In an object oriented computer system, a framework mechanism defines an infrastructure for allowing a user to flexibly define keys and their corresponding attributes. A special type of key called a specification key allows combinations of attributes to be specified, as well as set and range capabilities. An attribute retrieval policy is defined by a programmer to specify an algorithm or criteria that is used to calculating the desired attribute value. An attribute key controller contains key/value pairings for the attribute, contains the attribute retrieval policy, provides a maintenance interface for changing the attribute values; and provides a client interface for retrieving the attribute according to the attribute retrieval policy. The framework thus allows a user great flexibility in defining a suitable key/attribute retrieval mechanism by defining a suitable policy, defining one or more specification keys, and defining an associated controller.

Abstract: An object oriented framework defines a generic order processing interface that creates an order, and that processes the order and generates requests to one or more fulfillment systems to fill the order. The generic order suitably includes one or more line items. One or more extensible interface classes are provided in the framework, which allows a user to define the order entry protocol for the relevant order fulfillment systems. Once properly extended, the framework is used to generate an executable framework application, which allows a client to enter a generic order, and which then generates the appropriate requests to fill the order with the appropriate order fulfillment system or systems. The framework of the preferred embodiments thus allows the specific knowledge of the back-end order fulfillment systems to be isolated to the extended portions of the framework, while the front-end order entry system has no knowledge of the order fulfillment systems that may be called upon to fill an order.

Abstract: In an object oriented computer system, a framework mechanism defines a mechanism that separates the ability to complete a process from the results of that process. A task is defined in the framework in terms of a sequence of processes. The framework includes a coupling mechanism for flexibly coupling any of these processes together in any suitable order to define the run-time behavior of the framework without changing the core functions of the framework. The coupling mechanism includes the definition of a processable interface and a processing interface. A particular process generally takes detail information as input and produces detail information that is used in a subsequent process. The detail information input into a process is said to be “processable”, and therefore implements the “processable” interface. The detail information output from a process is said to be “processing” detail that is output to the next process, and therefore implements the processing interface.

Abstract: In an object oriented computer system, a domain-neutral object is modified with domain-specific run-time extensions to customize the object to a particular domain. A special factory uses the extension identifier to create the domain-neutral object with appropriate extensions in a collection that corresponds to the domain extension. If the special factory is not available, or if a specialized collection associated with the particular extension type has not been previously created, the domain-neutral object with appropriate extensions is created in a default collection. In this manner, an object that is domain-neutral can be customized to a particular domain and created in an appropriate collection for objects of that type.

Abstract: In an object oriented computer system, a framework mechanism defines an infrastructure for allowing a user to couple processes in the framework together in any suitable way to define a desired process flow. A user first defines a static object structure that corresponds to the specific process flow from one process to the next. The processes in the framework may be flexibly coupled in any suitable order, so a process does not have knowledge of its predecessor or successor processes. Thus, at run-time, a process determines the next step in the process flow from the static object structure. Once a process determines its subsequent process, a client may then create the next process and invoke methods on one or more objects corresponding to the newly-created process. Each process thus determines at run-time the next step in the process flow from the static object structure that the user statically defined to configure the process flow, which defines the desired processing environment.

Abstract: In an object oriented computer system, an object oriented framework defines an interface mechanism that provides a common interface to a non-object oriented persistent datastore. This common interface can be customized by various types within the framework by effectively hiding attributes on the common interface that are not needed by a particular type. Attributes defined on the common interface may be accessed at any level in the framework through a process of delegation from one level to the next. In addition, one or more of these attributes on the common interface may be defined at various levels, which causes those attributes to be accessed at their respective levels instead of delegating to different levels.

Abstract: Problem ownership and status propagation in a clustered system environment must be coordinated in a way that avoids redundant and/or conflicting recovery efforts. IOP managers which overcome these problems are disclosed. A primary IOP manager is one which has problem ownership for a particular IOP. There is only one primary IOP manager for each IOP. A secondary IOP manager is one which resides upon a computer system that shares the resources of a particular IOP or IOPs, but nevertheless does not have problem ownership for that particular IOP(s). There are one or more secondary IOP managers for a given IOP. When a primary IOP manager is informed of a problem in a device attached to a shared IOP, it updates resident system management information to indicate the new status of the subject device, informs its local system management of the problem so that corrective actions may be taken, and sends the status information to the secondary IOP managers via the IOP itself.