System and method for the creation and use of surrogate information system objects5758351Abstract The present invention defines a consistent method and system for enabling components in an information system to invoke operations that may be distributed across multiple computing platforms, through the provision and use of executable operations whose behaviors are determined from information stored and extracted from a Catalog (164) using an Operation Definition Manager (82). The stored information is used by a Surrogate Object Definition Module (96) to define a Surrogate Object Type structure which enables execution of any of the operations described within it. A Surrogate Object Manager (94), along with an Operation Connection Manager (104, 118, 130 or 132), is provided which assists the user in developing applications by providing access to the definition of the input and output arguments of the operations included in the Surrogate Object Type structure (244). The present invention further includes an Operation Connection Manager (104, 118, 130 or 132) which, together with the Surrogate Object Manager (94), provides a consistent means for an Operation Requestor (92) to invoke an operation and exchange input and output arguments, independent of the intervening network communication protocol or the hardware platform type, operating system and database management system upon which the operation has been implemented. Claims What is claimed is: Description TECHNICAL FIELD OF THE INVENTION
TABLE 1
______________________________________
Surrogate Object Type Functions
Name Description
______________________________________
Create SOT Structure
Replicates a set of Catalog database 164 records
to create a Surrogate Object Type structure 244.
Save SOT Structure
Saves a complete Surrogate Object Type structure
244 to the Surrogate Object Type Storage
file 102.
List SOT Structures
Returns a list of saved Surrogate Object Type
structures 244.
Load SOT Structure
Restores a saved Surrogate Object Type
structure 244 ready for use
by the Surrogate Object Manager 94.
Get SOT Details
Returns properties of the root surrogate object
type record 314 within the current Surrogate
Object Type structure 244.
Get List of Operations
For the current Surrogate Object Type structure
244, returns the list of operations it includes.
Get Operation Details
For a specific operation, returns the operation
properties.
Get Operation Type
For a specific operation, returns the operation
type and its properties.
Get Input Arguments
For a specific operation, returns the set of
its input argument definitions.
Get Output Arguments
For a specific operation, returns the set of
its output argument definitions.
Create Operation
For a specific operation, initiates the operation
invocation process;
Activation loads the Surrogate Object Type structure 244,
if not already loaded, creates an Operation
Activation structure with the Operation Activation
record property activation.sub.-- status = "in
preparation" and returns its activation.sub.-- ID.
If a SOI.identifier is provided, will map
the core entity identifier and any other
instance-mapped predicate values to argument
values in the Operation Activation structure.
Get List of OpActs
For a specific operation, returns a list of
current Operation Activation structures from
the Operation Activation Storage file 100.
______________________________________
Surrogate Object Type Structure A Surrogate Object Type structure 244 is a named collection of records that describes one or more operations and describes and defines their input and output arguments. A Surrogate Object Type structure 244 is created by the Surrogate Object Definition Module 96 from information extracted from the Catalog database 164. It is preferred that each Surrogate Object Type structure 244 is stored in a suitable persistent form in the Surrogate Object Type Storage file 102. The preferred storage implementation uses OLE structured storage, enabling a Surrogate Object Type structure 244 to be stored as an embedded object within an OLE compound document file. This enables the Surrogate Object Type structure 244 to be stored together with the Operation Requester 92 and other parts of the application. It is preferred that each Surrogate Object Type structure 244 is stored independently. As a result, information in one Surrogate Object Type structure 244 may be duplicated in another. This duplication enables storage and retrieval times to be optimized and ensures that each structure is always complete and usable, with no dependency between structures. A Surrogate Object Type structure 244 may be created to represent some type of element of significance to the business in which case it provides a surrogate "business object" or "business object type" (BOMSIG reference). Examples of this kind of use include Surrogate Object Type structures 244 created to represent a customer, an order form or an insurance proposal. The operations included in a customer Surrogate Object Type structure 244 may include Add.sub.-- Customer, Get.sub.-- Customer.sub.-- Credit.sub.-- Rating, and Change.sub.-- Customer.sub.-- Details. Alternatively, a Surrogate Object Type structure 244 may be created as a task-related object, combining the operations required to service the needs of some computer or user task. Furthermore, a Surrogate Object Type structure 244 may be created to provide a set of domain-related services and may further include a set of operations which manipulate values for date and time, or provide currency conversion, or provide standard algorithms such as tax or interest calculation, or provide utility functions, such as string searches, spell checking, or printing. Surrogate Object Type Data Model Each of the record types within the Surrogate Object Type structure depicted at 244 in FIG. 4 is described hereinbelow together with a list of the relationships they participate in and details of their required properties. Surrogate Object Type Record The surrogate object type record 314 holds the definition of the Surrogate Object itself and provides the root record for the other record types in the Surrogate Object Type structure 244. When written thus, "Surrogate Object Type" the term refers to the structure; when written thus, "surrogate object type", the term refers to the root record type within such a structure. The surrogate object type record 314 always includes one or more operations represented by an operation record 304. These are the operations which can be invoked from the Surrogate Object Type structure 244. A surrogate object type record 314 may also include one or more instances of the predicate instance mapping record 266. The surrogate object type record 314 is required if instance mapping is enabled for the Surrogate Object Type structure 244. An instance of the predicate instance mapping record 266 exists for each instance of the argument record 288 and is used as a source of instances of the predicate value record 260 in the Surrogate Object Instance structure 242. The same instance of the predicate record 282 can be sourced from more than one instance of the argument record 288 of more than one instance of the operation record 304. Instances of the surrogate object type record 314 may have only one core instance of the entity type record 276 which is optional. A core instance of the entity type record 276 is required if instance mapping is enabled for the Surrogate Object Type structure 244. The instance of the entity type record 276 indicates the type of thing upon which the Surrogate Object Type structure 244 is based. The identifier of the instance of the entity type record 276 is used as the identifier of Surrogate Object Instance structures 242 based on the current Surrogate Object type structure 244.
______________________________________
Property Description
______________________________________
name Meaningful name for the Surrogate Object Type
structure 244.
description
Describes the purpose of the Surrogate Object
Type structure 244.
instance.sub.-- mapping.sub.--
Indicates if instance mapping has been
flag requested for the Surrogate Object Type
structure 244. Value "yes"
indicates instance mapping is enabled.
______________________________________
Operation Record Instances of the operation record 304 store the definition of an executable operation intended to be accessible using the present invention. An instance of the operation record 304 is always included in an instance of the surrogate object type object 314. An instance of the operation record 304 is always of only one operation type record 312. Different instances of the operation record 304 within the Surrogate Object Type structure 244 may be associated with different operation type records 312. An operation sometimes outputs one or more sequenced argument groups 296, shown by the "output from" relationship at 300. The "output from" relationship at 300 and the "contains" relationship at 290 between argument record 288 and argument group record 296 are sequenced so that the sequence that the individual output arguments occur in can be retained. An operation sometimes inputs one or more sequenced argument groups, shown by the "input to" relationship at 302. The "input to" relationship at 302 and the "contains" relationship at 290 between argument record 288 and argument group record 296 are sequenced so that the sequence that individual input arguments occur in can be retained.
______________________________________
Property Description
______________________________________
name Meaningful name that the operation is known by,
should be understandable to a business person.
Identifier - unique within the Catalog database 164.
source.sub.-- name
Optional. A name used in the original source.
May be used by Operation Enrollment Modules 160
to assist matching in cases of re-enrollment.
description
Describes the intended usage of the operation.
execution.sub.-- name
The name or other identifier required by the
Operation Connection Manager 104, 118, 130 or
132 at runtime to enable the operation to
be located and executed.
execution.sub.--
Information accessible to the Operation Connection
parameter Manager 104, 118, 130 or 132 at runtime to enable
correct location and execution of the operation.
input.sub.-- validation.sub.--
Optional. Indicates any constraints that apply to the
rule operation as a whole.
instance.sub.-- mapping.sub.--
Optional. Value "yes" indicates that this
flag operation's output arguments are to be mapped to
Surrogate Object Instance structures 242.
______________________________________
The execution.sub.-- parameter may be in any format understandable and meaningful to the Operation Connection Manager 104, 118, 130 or 132 and/or other communications-related components which are executed by the Operation Connection Manager 104, 118, 130 or 132 as part of the process of invoking the operation. The Operation Connection Manager 104, 118, 130 or 132 may translate or transform this information using some directory service or use some other means of determining or acquiring necessary location information so that the operation can be executed. Operation Type Record The operation type record 312 defines the type of an executable operation. The operation type record 312 is also used to hold information applicable to a number of operations of the same type. An operation type record 312 always groups one or more executable operations.
______________________________________
Property
Description
______________________________________
name Meaningful name of the operation type. Identifier - unique
within the Catalog database 164.
OCM.sub.-- name
The name of the Operation Connection Manager 104, 118,
130 or 132 to be used by the Surrogate Object Manager 94
for operations of this type.
______________________________________
Entity Type Record The entity type record 276 is a meaningful collection of predicates stored in the predicate record 282. The entity type represented by the entity type record 276 normally represents an important thing in the business. An entity type record 276 always includes one or more sequenced predicate records 282. An entity type record 276 is sometimes identified by one or more sequenced predicate records 282. This relationship must exist if Surrogate Object Instance structures 242 are to be supported for the Surrogate Object Type structure 244, in which case this relationship is required only for the core entity type record 276 of the surrogate object type record 314, described in more detail hereinbelow. The identifying predicate records 282 are used to identify Surrogate Object Instance structures 242. An entity type 276 is sometimes the core of only one surrogate object type record 314. If Surrogate Object Instance structure 242 support is enabled, only one entity type 276 is defined as the core entity type 278. Predicates 282 of non-core entity types 276 can also be represented by arguments 288 of included operations 304. An entity type 276 is sometimes represented in one or more argument groups 296. Surrogate Object Instance structure 242 support requires the ability to identify a group of an operation's output arguments as being a view of an instance of an entity type 276. Values from these arguments 288 are then used to populate predicate values 260 in a Surrogate Object Instance structure 242.
______________________________________
Property Description
______________________________________
name Meaningful name. Identifier - unique within the Catalog
database 164
source.sub.-- name
Optional. A name used in the original source. May be
used by Operation Enrollment Modules 104, 118, 130 or
132 to assist matching in cases of re-enrollment.
description
A business-level description of the entity type.
______________________________________
Predicate A predicate 282 is an important business fact which describes an entity type 276. A predicate 282 may be an attribute of the entity type 276 or it may be part of a relationship with another entity type 276. For example, "name" might be an attribute of the "customer" entity type 276. A predicate 282 always describes only one entity type 276. A predicate 282 sometimes identifies an entity type 282. The identifier of an entity type 276 may include more than one predicate 282. A predicate 282 is always represented by one or more arguments 288. A predicate 282 also defines the underlying business meaning implied by an argument 288. Association with the arguments 288 of multiple operations 304 enables the indication of common meaning among the arguments 288. A predicate 282 sometimes defines one or more predicate values 260. Not all Surrogate Object Type structures 244 need be used as the basis of Surrogate Object Instance structures 242. And for those that are, not all predicates 282 of the included entity types 276 need be stored as predicate values 260.
______________________________________
Property Description
______________________________________
name A meaningful name for the predicate 282. Unique within
its entity type 276.
source.sub.-- name
Optional. A name used in the original source. May be
used by Operation Enrollment Modules 104, 118, 130 or
132 to assist matching in cases of re-enrollment.
description
A business-level description of the predicate 282.
format For attributes only. Indicates the format used,
will include size and data type.
optionality
Indicates if every instance of the entity type 276 will
have a value for this predicate 282 - includes any
required optionality rules.
cardinality
Indicates any cardinality constraints on occurrences
of the predicate 282, e.g. min., max., average, and
indicates any cardinality rules.
validation.sub.-- rule
Optional. Indicates any constraints on values that
may be held by the predicate 282. This rule
applies to the predicate 282 in general. Additional
rules may occur on arguments 288 which are
representations of the predicate 282, which will
apply prior to execution of an operation 304.
______________________________________
Argument An argument 288 is a data item which is either input to or output from an operation 304. An argument 288 is sometimes a representation of one predicate 282. Where an argument 288 is not associated with a predicate 282, then it is assumed to be an operation-specific variable with no meaning beyond its use by the operation 312. An argument is always part of one argument group 296. The arguments 288 of a specific operation 312 may be arranged into a hierarchical structure of argument groups 296. At a minimum, each argument 288 will be associated with a highest-level argument group 296 which directly or indirectly includes all the input or all the output arguments 288 of an operation 304.
______________________________________
Property Description
______________________________________
name Meaningful name for the argument 288. Unique within
argument group 296.
source.sub.-- name
Optional. A name used in the original source. May be
used by Operation Enrollment Modules 104, 118, 130 or
132 to assist matching in cases of re-enrollment.
description
Provides a high-level description of the argument's
purpose.
format Indicates the argument's format, will include size and
data type.
optionality
Indicates if the argument is required by every execution
of the operation, may include any required
optionality rules to indicate under what conditions
this argument is required.
cardinality
Indicates any cardinality constraints on occurrences
of the argument, e.g. min., max., average, indicates any
cardinality rules.
mapping.sub.-- rule
Optional. Only used if the argument is a representation of
a predicate, and indicates any format and value
translation to occur when mapping a value between
the predicate and argument format.
validation.sub.-- rule
Optional. Indicates any constraints on values that may be
held by the argument. If the argument is associated with
a predicate, then this rule will override any
validation.sub.-- rule defined for the predicate.
______________________________________
Argument Group An argument group 296 is a meaningful collection of either input or output arguments 288 of a single operation 304 and is used to indicate structure within the arguments 288 of an operation 304. An argument group 296 is also used to distinguish arguments 288 which are representations of predicates 282 of different instances of the same entity type 276. An argument group 296 is further used to indicate where a group of arguments occurs multiple times in the input or output of an operation 304. An argument group 296 is sometimes output from only one operation 304. An argument group 296 is sometimes input to only one operation 304. An argument group 296 is sometimes part of only one other argument group 296. These three relationships are mutually exclusive. Argument groups 296 are further used to define hierarchical structure among the data items input to or output from an operation 304. At the top of the hierarchical structure, the topmost argument group 296 is associated with the operation 304 either as input 302 or output 300. Individual arguments 288 form the leaf-nodes of the hierarchical structure. An argument group 296 sometimes includes one or more sequenced argument groups 296 which is an inverse of the relationship indicated hereinabove. An argument group 296 may also include one or more sequenced arguments 288 and must include either another argument group 296 or arguments 288.
______________________________________
Property Description
______________________________________
name Meaningful name for the argument group 296. Unique
within argument group 296 or operation 304.
source.sub.-- name
Optional. A name used in the original source. May be
used by the Operation Enrollment Modules 104, 118, 130
or 132 to assist matching in cases of re-enrollment.
description
Provides a high-level description of the argument group's
296 purpose.
______________________________________
Predicate Instance Mapping A predicate instance mapping 266 is only required if Surrogate Object Instances 248 are to be enabled for the Surrogate Object Type structure 244. A predicate instance mapping 266 defines an intersection between an argument 288, a predicate 282 and the surrogate object type record 314. A predicate instance mapping 266 always defines the source of a predicate 282 in an instance of one Surrogate Object Type structure 244. A predicate instance mapping 266 always maps to one argument 288. A predicate instance mapping 266 always maps to one predicate 282. For an output argument 288, the existence of an associated predicate instance mapping 266 indicates that argument values defined by this argument 288 are mapped to the corresponding predicate value 260 in the Surrogate Object Instance structure 242. If there are no predicate instance mapping objects 266 for a predicate 282, no corresponding predicate values 260 will exist in any Surrogate Object Instance structure 242. For an input argument 288, the existence of an associated predicate instance mapping 266 indicates that the corresponding argument value is mapped from the corresponding predicate value 260 in a Surrogate Object Instance structure 244 prior to operation execution. For predicates 282 other than identifying predicates 282 this can be overridden by a value provided by the Operation Requester 92. For both input and output arguments 288, transformation between the format of the predicate 282 and the format of the argument 288 is defined by the mapping.sub.-- rule defined on the argument 288. Predicate values 262 stored in the Surrogate Object Instance structure 242 are held in the format defined by the predicate 282. To support instance mapping, an operation's arguments 288 must include arguments 288 which are representations of all of the set of predicates 282 which form the identifier of the core entity type 276 of the Surrogate Object Type structure 244. No properties are required. The predicate instance mapping 266 is identified by the combination of its relationships with argument 288, predicate 282 and surrogate object type record 314. Operation Activation Structure An Operation Activation structure 246 is a collection of records that together represents an occurrence of the activation (invocation) of an operation 304 defined within a Surrogate Object Type structure 244. The Operation Activation structure 246 provides a "staging area", which enables the input and output arguments 288 to be assembled into an operation-neutral format prior to the operation 304 being invoked and after execution. The Operation Activation structure 246 is implemented so that the relationships between the operation and operation activation records can be traversed in either direction.; i.e., it must be possible to determine all the operation activations for a given operation, and from a given operation activation, determine what operation it is for. Each individual Operation Activation structure 246 based on a single root operation activation record can be saved to the Operation Activation Storage file 100 as an option. This permits a form of operation activation logging. However, the preferred implementation does not require this persistence as an Operation Activation structure 246 is normally only required by an Operation Requester 92 for the duration of an operation activation "cycle", during which time the Operation Activation structure 246 is maintained in computer memory. After operation execution, output arguments are either retrieved immediately by the Operation Requester 92 and/or they are mapped to predicate values 260 in a Surrogate Object Instance structure 242 which can then be saved to the Surrogate Object Instance Storage file 98. Once the Surrogate Object Manager 94 processing is terminated, all unsaved Operation Activation structures 246 are lost. Operation Activation Data Model Operation Activation Record An operation activation record 316 is the root of an Operation Activation structure 246 and holds details of a single invocation--or activation--of an operation 304, including time of activation, user-id of person requesting activation, execution status, error message etc. When written thus, "Operation Activation" the term refers to the structure; when written thus, "operation activation", the term refers to the root record type within such a structure. An operation activation record 316 always records the invocation of only one operation 304. An operation activation record 316 sometimes has as input one or more argument value groups 324. An operation activation record 316 sometimes has as output one or more argument value groups 324.
______________________________________
Property Description
______________________________________
activation.sub.-- ID
Date and time of the activation. Unique within
operation.
activation.sub.-- status
Gives execution details and provides a
means to check the current execution status.
Values include:
"in preparation"; the activation object
has been created but the operation should
not be invoked yet
"in progress"- the execution has been
requested but no response or error has
yet been encountered
"completed OK"- operation execution
was successful and a valid response has
been received
"application error"- operation execution
was successful but an application-level
error has occurred
"system error"- some error has occurred
which has prevented a response from
the operation being received.
activation.sub.--
Optional. Provides additional information
message regarding the
activation.sub.-- status. The message may be
returned from the operation or generated by the
system if an error has occurred
instance.sub.-- mapping.sub.--
Optional: Indicates if Operation Activation
status results were successfully mapped to Surrogate
Object Instance records. Only required if instance
mapping is being used.
user.sub.-- information
Optional. Could be used to record the
system identifier (user-id) or other user-related
properties of the person requesting
the Operation Activation.
callback.sub.-- pointer
Optional. Points to a user-provided
module to be executed by the Operation
Connection Module 104, 118, 130 or 132
on completion or error.
______________________________________
An Operation Activation structure 246 is identified by a combination of its associated operation and the activation.sub.-- ID. Argument Value An argument value 328 holds the value for an argument for a specific operation activation 316. In the preferred embodiment of the present invention, each argument value 328 is implemented as a slot in a record which includes either all the input or output argument values, arranged according to the sequence and structure defined by the argument value groups 324. The relative position of each argument value 326 within the record corresponds to the relative position of the defining argument within the operation input or output argument structure. An argument value 326 is always part of one argument value group 324.
______________________________________
Property Description
______________________________________
<value> The stored value.
______________________________________
Surrogate Object Instance Structure The Surrogate Object Instance structure 242 provides a form of local "database" comprising a collection of records which hold data representing one or more instances of a common surrogate object type record 314. The Surrogate Object Manager 94 functions which offer access to these records in the Surrogate Object Instance structure 242 act as the database engine. A Surrogate Object Instance structure 242 comprises possibly multiple "root" surrogate object instance records, together with one or more entity records each with one or more predicate value slots. Each entity and predicate value is created from the output of one or more operations after their execution. Individual arguments are mapped to predicate value slots based on the predicate instance mappings defined in the Surrogate Object Type structure 244. The exact structure of the records included within a Surrogate Object Instance structure 242 will depend upon a combination of the definition of the Surrogate Object Type structure 244, which operations have been invoked and with what input arguments, the state of the data currently held on the application databases accessed by the operations and the rules included within the operation logic. Where repeated executions of the same operation, or executions of different operations results in output arguments being returned that represent the same predicates of the same entities (i.e. the values of the output arguments which represent the identifying predicates of the entity type are the same) this will cause the same predicate value slots of the entity record to be used and the values and properties stored therein will be updated. Surrogate Object Instance Data Model Surrogate Object Instance (SOI) record The Surrogate Object Instance record type 248 represents the root object of the Surrogate Object Instance structure 242 and collects together the set of predicate values which together hold the instance data. When written thus, "Surrogate Object Instance" the term refers to the structure; when written thus, "surrogate object instance", the term refers to the root record type within such a structure.
______________________________________
Property Description
______________________________________
identifier
Unique identifier for the SOI record type 248 within
Surrogate Object Type structure 244.
______________________________________
Entity The entity 254 represents an occurrence of an entity type 276. The entity 254 collects together the predicate values 260 that hold the data stored about the entity 254. An entity 254 is identified by the values in the predicate slots that correspond to the predicates that form the identifier of the entity type 276. Each of these slots must hold a valid value. An entity 254 sometimes is the core of a Surrogate Object Instance structure 242. An entity 254 always includes one or more predicate values 260. An entity 254 is always is defined by one entity type 276.
______________________________________
Property Description
______________________________________
last.sub.-- updated.sub.--
name of operation which caused creation or last
operation update of a predicate value slot.
last.sub.-- updated.sub.-- time
activation.sub.-- ID (timestamp) of operation activation
resulting in creation or last update of a predicate
value slot. Provides traceability - finer detail
carried on each predicate slot.
______________________________________
Predicate Value A predicate value 260 holds the value of an individual predicate 282 within an entity 254. In the preferred embodiment of the present invention, each predicate value 260 is a slot in an entity record. Each predicate 282 in the set defines the corresponding predicate value 260. A predicate value 260 always is included in one sequenced entity 254. A predicate value 260 is sometimes paired with one predicate value 260. If the corresponding predicate 282 in the entity type 276 represents a relationship, the predicate value 260 is paired with a predicate value 260 belonging to an entity 254 of the related entity type 276. This provides a navigable pointer pairing mechanism allowing relationship pairings between entities 254 to be traced. A predicate value 260 is always defined by one predicate 282.
______________________________________
Property Description
______________________________________
<value> The stored value.
last.sub.-- updated.sub.--
name of operation which caused last update of the
operation value in this slot. Provides traceability.
last.sub.-- updated.sub.-- time
activation.sub.-- ID (timestamp) of operation
activation resulting in creation or last
update of this slot. Provides traceability.
______________________________________
Operation Connection Manager The Operation Connection Manager 104, 118, 130 or 132 provides a generalized runtime connection capability enabling the Surrogate Object Manager 96 to trigger execution of an implemented operation. An Operation Connection Manager 104, 118, 130 or 132 will be required for each set of operations which support a consistent interface protocol. Operations built by a common tool in a common style may all be able to use the same Operation Connection Manager 104, 118, 130 or 132. For example, any distributed process server (DPS) module built with Composer by IEF, for example, regardless of the platform on which the DPS module executes, can be accessed by the same Composer Operation Connection Manager 104. Similar use of a common Operation Connection Manager 130 or 132 is likely to be possible for operations built by other application development tools. The Surrogate Object Manager 94 and the appropriate Operation Connection Manager 104, 118, 130 or 132 will collaborate to ensure the input arguments in the Operation Activation object 316 are formatted and defined in the manner expected by the operation, and communicated to the operation using the appropriate communication protocol. The Operation Connection Manager 104, 118, 130 or 132 is responsible for applying input and output transformation rules to transform data between the format stored in the Operation Activation structure 246 and the operation message format and back again. Depending on the requirements of the type of operation involved, the Operation Connection Managers 104, 118, 130 or 132 can be written to accommodate operations which expect fixed or variable length message structures, in a pre-defined sequence or with embedded tags describing the arguments. Data compression or encryption algorithms can also be incorporated as required on both input and output. The input and output transformation rules and data marshaling rules can be coded as part of the Operation Connection Manager 104, 118, 130 or 132, or can be retrieved from some external source to be evaluated at execution time. The Operation Connection Manager 104, 118, 130 or 132 is responsible for monitoring operation progress including operation completion and the detection of various possible error conditions. In the case of successful completion, the Operation Connection Manager 104, 118, 130 or 132 decodes the returned data into the set of output argument values in the Operation Activation structure 246. Through the definition of a set of common functions that must be supported by all of the Operation Connection Managers 104, 118, 130 or 132, the present invention provides for any number of different Operation Connection Managers 104, 118, 130 or 132 to be used simultaneously by the Surrogate Object Manager 94. Differences between operation types are thus made transparent to the Operation Requester 92. It is anticipated that the Operation Connection Managers 104, 118, 130 or 132 are built in advance by a user of the present invention in accordance with the specific operation types, or developed and sold by application development tool vendors as part of their commercial offerings. Flow Overview A general description of the use and behavior of one embodiment of the primary components of the present invention is described hereinbelow. This description follows a logical sequence, describing three phases of use. In the first phase, operations are created and their definitions are enrolled into the Catalog database 64. In the second phase, these operations definitions are combined to create a Surrogate Object Type and Operation Requester 92 and any user interface or other programs are also constructed. In the final phase, the completed application is used and operations are executed with input data being passed from the Operation Requester 92 to the operation via the Surrogate Object Manager 94 and the appropriate Operation Connection Manager 104, 118, 130 or 132. The results of the execution are then returned to the Operation Requester 92. Scenarios Two slightly different scenarios are described to illustrate the purpose and flow of information through the various elements of the present invention. Both scenarios involve the use of a common set of operations (described hereinbelow). In this example, the operations implement behavior of a "customer" business object, and their definitions are used to create a "Customer" Surrogate Object Type. To the developer of a user interface program, the Customer Surrogate Object Type behaves as if it includes the implementation of the operations--it has become a surrogate for the set of customer operations. Scenario 1, illustrated in FIGS. 5 and 6, show the simplest use of the present invention with a user interface program 368 which provides any required transient or persistent management of the data returned by the operations. Scenario 2, illustrated in FIG. 7, is an extension of scenario 1 and illustrates in more detail the use of the Surrogate Object Instance feature of the present invention. In the second scenario, the user interface program 572 makes use of the facilities provided by the system to manage instance data returned by the operations. Furthermore, in scenario 2, the Surrogate Object Manager 614 functions are used to create and manage discrete surrogate object instances, one per customer record that has been accessed by an operation. Each surrogate object instance is accessible individually and can be made the subject of operation requests. Building The Operations Both scenarios described hereinbelow involve the same set of exemplary executable operations: Add.sub.-- Customer, List.sub.-- Customers, Get.sub.-- Customer.sub.-- Details, Change Customer Details and Get.sub.-- Customer.sub.-- Credit.sub.-- Rating. Each of the operations are stored on one of a plurality of heterogeneous, distributed computers interconnected by an exemplary computer network system 20 as shown in FIG. 1. The input and output arguments for each exemplary operation are described in FIG. 8. With the exception of Get.sub.-- Customer.sub.-- Credit.sub.-- Rating, each of the exemplary operations involves either creating, reading or updating of customer records stored in a shared customer database 424, 524 or 640. These four operations behave as follows: Add.sub.-- Customer creates a customer record in an application database with values for name, address and phone number as supplied in the operation input arguments and returns in addition the unique customer number created to identify the new customer record. List.sub.-- Customers returns a list of the customer number and name stored on each customer record in the database. Get.sub.-- Customer.sub.-- Details requires a customer number. If a matching customer record is found in the database, the operation returns the name, address and telephone number stored therein. Change.sub.-- Customer.sub.-- Details requires the customer number and optionally, the name, address and telephone number. If the customer is found, then the supplied values for name, address and telephone number will be used to replace those in the database. These four exemplary operations have been packaged together into a single executable--the Customer operation package, "CUSTOMER.EXE" 412, 514 or 630. Execution of the correct exemplary operation within this package requires the use of an execution.sub.-- parameter passed to the operation package 412, 514 or 630--in these scenarios, this takes the form of a command field. The command values required for each operation are described in FIG. 8 as the execution.sub.-- parameter. Regarding the first scenario as illustrated in FIG. 7, the four operations, Add.sub.-- Customer, List.sub.-- Customers, Get.sub.-- Customer.sub.-- Details, and Change.sub.-- Customer.sub.-- Details have been developed using a common tool, i.e., Composer by IEF, so they share a common protocol for execution and argument passing. As a consequence, all these operations can be connected to the Surrogate Object Manager 390 via a single, common Operation Connection Manager, shown in FIG. 7 as the Composer Operation Connection Manager 394. The Composer Operation Connection Manager 394 in turn uses the Composer Communications Module 406 to communicate with the computer system on which the operation package 412 is implemented via the computer front-end module 410 associated with that computer system. The computer front-end module 410 assists in routing the operation request to the operation and the response back. The operation Get.sub.-- Customer.sub.-- Credit.sub.-- Rating is implemented on a different computer system, is developed in a different language with a different tool, uses a different database and runs under a different operating system. (In this scenario, this operation is, for example, part of an older information system which would otherwise be difficult to integrate with the newer operations in the Customer operation package 412 at runtime.) By making Get.sub.-- Customer.sub.-- Credit.sub.-- Rating available as an operation of the Customer Surrogate Object Type, the present invention makes it appear indistinguishable from the other newly-built operations to the person developing the Operation Requester 378. In both scenario 1 and scenario 2, the operation Get.sub.-- Customer.sub.-- Credit.sub.-- Rating is accessed using the 3270 message protocol through the 3270 Terminal Emulation Module 434 and the Computer Front-End Module 438. This communication protocol is a de facto standard for screen-based communication between IBM-compatible computers and "dumb terminals". The 3270 protocol defines how information to be displayed on a screen is packaged into a data stream. The data stream includes the data to be displayed together with various control codes which are interpreted by the display terminal. Interception of this data stream at the terminal end by the terminal emulation software running on some other kind of computing device (i.e. a personal or server computer as opposed to a "dumb terminal") enables this data stream standard to be used to communicate with compatible operations implemented on IBM-compatible mainframes. This is particularly suitable if it is desired to make use of application components already in existence which were written initially to use this communication protocol. Thus, the present invention provides the ability to incorporate older, pre-existing communication technology and thus integrate access to a wide range of existing applications as well as applications specifically designed to exploit the present invention. Other standard messaging protocols could similarly be used whether screen oriented or not. In the scenarios described herein in FIGS. 7-9, a specialized 3270 Operation Connection Manager 426, 528 or 642 is shown. The specialized 3270 Operation Connection Manager 426, 528 or 642 is responsible for mapping operation input arguments into a 3270 data stream and sending it to the host for processing, and then for receiving the 3270 data stream sent back in response and for identifying the output arguments within the 3270 data stream and mapping these output arguments back into the form understood by the present invention. Although the 3270 data stream is pre-determined, the layout of information on each screen frequently varies from screen to screen--i.e. the row/column starting position and length of fields and text strings. As this layout information affects the relative position of data and other elements within the 3270 data stream, this information is required to enable the 3270 Operation Connection Manager 426, 528 or 642 to map the operation arguments into and out of the data stream. In addition, other control codes may need to be entered into the data stream, or multiple interactions between the 3270 Operation Connection Manager 426, 528 or 642 and the host may be required to cause the host system to be put in a state ready to execute the operation. This information is likely to include user log-on and access, via menus and other control mechanisms, to the correct "screen" on which the operation data is represented. This navigation and formatting information will normally be different for each operation, although re-usable for every execution of the same operation. This "script" information could be written into the logic of the 3270 Operation Connection Manager 426, 528 or 642 or stored externally in Script File Storage 432, 536 or 648 as a set of parameters which are accessed and interpreted whenever the operation is to be executed. In both scenario 1 and scenario 2, script information is required to enable the 3270 Connection Module 426, 528 or 642 to correctly locate and execute the Get.sub.-- Customer.sub.-- Credit.sub.-- Rating operation 442. External storage of this is assumed and illustrated in FIGS. 5, 6 and 7 in the Script File Storage 432, 536 or 648, respectively. Select Or Build The Required Operation Connection Managers The Operation Connection Manager 426, 528 or 642 is expected to be a common module used to connect many operations with similar connectivity characteristics into the system. If a new type of operation is being used for the first time a new Operation Connection Manager may have to be constructed, otherwise one should already exist. The operation of the Operation Connection Manager 426, 528 or 642 is illustrated in the flowchart shown in FIG. 13. The present invention allows the simultaneous use of multiple, different Operation Connection Managers. It must be possible for any Surrogate Object Manager that has to access an operation to be able to locate the Operation Connection Manager for that type of operation. It may be that the Operation Connection Managers will be co-located with the Surrogate Object Managers, perhaps on a user's desktop machine, or they may be located on a shared computing resource and re-used by multiple Surrogate Object Managers. Both scenarios 1 and 2 require a Composer Communications Module 406, 508, or 624 and a 3270 Terminal Emulation Module 434, 538 or 650 to be present. Enroll the Operations and their Arguments into the Catalog Information representing an operation and its input and output arguments must be stored in the Catalog database 64 before it is accessible through the present invention. If the Catalog database 64 being used for the present invention is shared with the development tools used to develop the operation code, then this information may be present as a result of the normal development process. If the operation has been developed from a separate development repository then this information may be enrolled using an Operation Enrollment Module 160. Operations which have been manually written or built using a tool for which a specific Operation Definition Module 82 is not available can be input manually using an Operation Enrollment Module 160 that supports manual entry. Once entered in the Catalog database 64, regardless of the source, information can be maintained by the Catalog Editor 148. In the two scenarios discussed here, the operations are either built with Composer or they are existing 3270-based operations. In both cases, information about the operations has been stored in Composer's development repository and is extracted and enrolled into the system's Catalog database 64 using an Operation Enrollment Module 160 designed for the purpose. The Operation Enrollment Module 160 captures properties of each operation and associates each operation with an operation type object, and then maps the definition of each operation's input and output arguments from a Composer-proprietary representation to the representation defined in the data model of the Catalog database 64 as illustrated in FIG. 3. As described hereinabove, a key function of the Operation Enrollment Module 160 is the construction of a normalized model of the underlying set of business facts that are represented by the arguments of operations being enrolled. The model is built up with each successive operation as it is enrolled. The arguments of each operation being added are matched to predicates in the model as it already exists. The arguments are either associated with existing predicates and entity types in the model or if necessary, new ones are added. For example, if the operation Get.sub.-- Customer.sub.-- Details is added after Add.sub.-- Customer has been added, the arguments of Get.sub.-- Customer.sub.-- Details will be found to entirely overlap with those of Add.sub.-- Customer as illustrated in FIG. 8. In the Catalog database 64, records will be created to represent the new operation and its arguments and these will be associated with the arguments of Add.sub.-- Customer through their mutual reference to common predicates. Additionally, mapping and validation rules may be specified. Mapping rules allow a transformation to be described between the format of an argument and the predicate. In this way minor variations in the representation of common concepts can be supported. If transformation is required between the format defined by the predicate and the format defined by the argument, the mapping.sub.-- rule property on both input and output argument objects is used to store the rule. This mapping.sub.-- rule would define format and domain transformations between the predicate and the arguments affecting things such as left or right alignment, character padding, null characters representation, addition or removal of currency symbols, numeric to character conversion and etc. The mapping.sub.-- rule on the input argument would be applied before operation execution; the mapping.sub.-- rule on the output argument would be applied after execution. Validation rules stored in the Catalog database 64 enable arguments to be verified prior to operation execution. Validation rules can be stored in the validation.sub.-- rule property on a predicate, on an input argument, or on the operation. Validation rule processing is invoked on request by the Operation Requester 92 to validate an operation's input arguments, perhaps as they are entered through the user interface, or immediately before invoking the operation as shown in the operation of the Operation Requester 92 illustrated in the flowchart shown in FIG. 11. The present invention does not specify a particular rule language for either the validation or mapping rules. Any procedural or declarative rule language can be used and implemented in the design of the Validate Input Argument and Validate Operation Input functions of the Surrogate Object Manager 94. The point at which these functions are invoked is indicated in the flowcharts shown in FIGS. 11-13. It is contemplated that a corresponding rule parser and checker could be usefully included as part of the Operation Enrollment Module 160 to assist in the correct definition of rules upon entry to the Catalog database 64. The other Catalog record types and their properties described earlier are captured either during enrollment or during maintenance using the Catalog Editor 148. Emphasis is placed on having descriptions in the Catalog database 64 that will assist the developer of an Operation Requester 92 to locate and identify operations which match their needs. Browse Catalog To Find Suitable Operations And Create A Surrogate Object Type Both scenarios are based on the creation and use of a Surrogate Object Type created to represent a customer business object. A customer business object requires a collection of operations which act upon customer information. The Surrogate Object Definition Module 96 is used to browse among the operations that have been enrolled into the Catalog database 64 to locate those to be included in the Surrogate Object Type. It is contemplated that the process of searching the Catalog database 64 for operations which match some set of requirements could be included in the present invention. If it is ever intended that the Surrogate Object Type might support instance mapping (i.e., the creation of Surrogate Object Instances), then a core entity type must be defined. If this is done, it is likely, but not essential, that the operations to be included will all have arguments which represent predicates of the core entity type. Only those operations whose output arguments include representations of all of the identifying predicates will be able to participate in instance creation. Once the required operations and the core entity type (if required) have been identified from the Catalog database 64, the Surrogate Object Definition Module 96 calls the function Create.sub.-- SOT.sub.-- Structure of the Surrogate Object Manager 94 passing it information about the selected objects. In this case, the Create.sub.-- SOT.sub.-- Structure function creates an instance of the Surrogate Object Type structure 244 with a root surrogate object type record with name of "Customer." The Create.sub.-- SOT.sub.-- Structure function also populates the structure with records replicated from the Catalog database 64 including the selected operations, their associated operation type(s), their input and output arguments, each argument's associated predicates and the entity types these predicates belong to. When complete, the Surrogate Object Type structure 244 includes a replicated subset of the information held in the Catalog database 64. The Surrogate Object Type structure 244 includes all the information required to support the execution of the operations defined within it. Further minor modification to the properties of objects included within the Surrogate Object Type structure 244 can be carried out with the Surrogate Object Definition Module 96 without further contact with the Catalog database 64. Once completed, the Surrogate Object Type structure 244 is saved in a persistent form in the Surrogate Object Type Storage file 100 by invoking the Save.sub.-- SOT.sub.-- Structure function of the Surrogate Object Manager 94. Surrogate Object Types can be created in advance of their planned use by the Operation Requester 92 or can be created as and when needed. Once saved in the persistent form, the Surrogate Object Type structures 244 can be distributed to wherever they may be required. Build the Operation Requester and User Interface Program The Operation Requester 92 and user interface program 90 are now built. In both scenarios, the Operation Requester 92 is called by the user interface program 90 which enables data to be entered by the end-user, each operation to be executed and any returned data to be viewed. The screen generated by and the behavior of the user interface program 90 provide the means by which the user can activate the operations executable using the present invention and to observe their effect. In scenario 1, as illustrated in FIG. 5, the user interface program 368 provides any required desktop persistence of data between operation executions. In a simple solution, this is likely to be done using in-memory data structures. In this way data values returned as output arguments of one operation can be re-used as input argument values for a subsequent operation execution without re-entry by the user. Values can be retained in in-memory structures for as long as the user interface program is running but will be lost when it is stopped. A more complex solution might provide persistence across multiple sessions, storing important data values in some non-volatile storage medium. However, provision of any such capability would be the responsibility of the programmer of the user interface program 368 and is not provided for by the system. In both scenarios, as illustrated in FIGS. 5-7, revision #3 of the Visual Basic language and product from Microsoft is used to construct the Operation Requester 378, 482 or 582 and the user interface program 368, 476 or 572. Appropriate code is written to trigger operation execution and to map input and output arguments into the Operation Activation structure 246 via the functions offered by the Surrogate Object Manager 390, 498 or 614. This will be accomplished if the developer constructs the logic of the Operation Requester 378, 482 or 582 in accordance with the preferred logic shown in the flowchart illustrated in FIG. 11. To assist the programmer writing the Operation Requester 378, 482 or 582, the Surrogate Object Type structure 244 is examined using the Surrogate Object Definition Module 96. This enables the programmer to determine the correct operation names and argument names to use in construction the program logic statements required to invoke the required Surrogate Object Manager 390, 498 or 614 functions. Alternatively, because the Surrogate Object Manager 390, 498 or 614 supports pre-defined functions, it is contemplated that standard application development tools could be built to automatically generate some or all of the code of the Operation Requester 378, 482 or 582 based on the contents of the Surrogate Object Type structure 244. Once developed, the Operation Requester 378, 482 or 582 and the user interface programs 368, 476 or 572 are deployed onto the intended computing platform ready for use. In these scenarios, this could be a desktop personal computer running the Microsoft Windows operating system. All of the other elements of the present invention required at runtime must also be installed and readied for use. This includes the Surrogate Object Manager 390, 498 or 614, the saved Customer Surrogate Object Type structure 244 in the Surrogate Object Type Storage file 392, 500 or 616, the Composer Operation Connection Manager 394, 502 or 618, the 3270 Operation Connection Manager 426, 526 or 642, the 3270 script file 432, 536 or 648 for the Get.sub.-- Customer.sub.-- Credit.sub.-- Rating operation, and the operations and the databases they access. Executing Operations at Runtime; Scenario 1 The diagrams shown in FIGS. 5 and 6 show data flows through specific elements of the present invention and depict the appearance of the user interface and data content of the databases before and after use of the present invention. The operation of the Operation Requester 378 or 482, illustrated in the flowchart shown in FIG. 11; the operation of the Start.sub.-- Operation.sub.-- Execution function of the Surrogate Object Manager 390 or 498, illustrated in the flowchart shown in FIG. 12; and the operation of the Execute.sub.-- Operation function of the Operation Connection Manager 394, 426, 502 or 526, illustrated in the flowchart shown in FIG. 13, further illustrate certain aspects of the data flow of one embodiment of the present invention. In Scenario 1, as illustrated in FIG. 5, the user interacts with the present invention entirely through an application window 352 presented by the user interface program 368. The application window 352 permits the user to enter new customer details and request that a new customer record is created. This causes the Operation Requester 378 to be called which in turn calls the Surrogate Object Manager 390 which invokes the Add.sub.-- Customer operation. This request is passed on via the appropriate Operation Connection Manager 394 or 426 and the operation is executed. This operation creates a new customer record in the customer database, using the details entered by the user and assigns the record a new identifying customer number. When the user interface program 368 receives confirmation through the present invention that the operation executed successfully, it calls the Operation Requester 378 again, this time to invoke the Get.sub.-- Customer.sub.-- Credit.sub.-- Rating operation, which searches the credit database 444 for the customer by name and returns the customer's credit rating if found. FIG. 6 shows one embodiment of the present invention in accordance with the scenario illustrated in FIG. 5 immediately after the user has entered the customer details but before requesting that the record is added. FIG. 7 shows another embodiment of the execution of the present invention in accordance with a second scenario after successful completion of the addition and the credit rating search. Details of the flow through each of the elements of the present invention are described hereinbelow. The logic of the user interface program 368, 476 or 572 is not described as this can vary widely depending upon design choices of the developer. Adding A New Customer The user first starts the user interface program 368 from the Windows program manager. The user interface program 368 displays the Create New Customer application window 352 and then waits for user input. Using a keyboard, the user enters values for customer name, address and telephone number, and then with the keyboard or a pointing device selects the push-button marked "Add" 360 to indicate that data entry is complete and that a new customer is to be created. The user interface program 368 detects the push-button selection event and from this determines that the Add.sub.-- Customer operation of the customer Surrogate Object Type is to be invoked. The user interface program 368 then maps data values from the fields in the application window 352 to corresponding fields in the requester send buffer 376 and the Operation Requester module 378 is invoked with values for SOT.name="Customer" and operation.name="Add.sub.-- Customer" as shown at 950 in the flowchart in FIG. 11. The Operation Requester module 378 then calls a series of functions of the Surrogate Object Manager 390. First, the Operation Requester module 378 calls the Create Operation Activation function using the SOT.name and operation.name as shown at block 952 in FIG. 11. This function loads the Customer Surrogate Object Type structure 244 from storage if not already loaded and creates an Operation Activation structure with its operation activation record associated with the operation Add.sub.-- Customer. The Operation Activation structure is created with the appropriate input and output argument value group structures and argument value slots initialized to spaces ready for use. Upon completion, the Create Operation Activation function returns the activation.sub.-- ID of the newly created operation activation record to the Operation Requester 378. Scenario 1 does not include the use of surrogate object instances so a surrogate object instance.identifier is not passed to the Create Operation Activation function. Had this been done, the Create Operation Activation function would have initialized all instance-mapped input arguments based on mapped predicate values from the core entity of the surrogate object instance. The Operation Requester 378 now processes each input argument in turn, moving the value held for it in the Requester Send Buffer 954 to the corresponding input argument value slot in the Operation Activation structure as shown in the flowchart in FIG. 11 at blocks 953 and 956. This is done by calling the Put Input Argument function of the Surrogate Object Manager 390 for each argument with the current SOT.name, operation.name, activation.sub.-- ID and the argument.name and the argument value retrieved from the Requester Send Buffer 954. At this point the customer name, "Digital Widgets Inc." and address, "2560, Highland Blvd., Plano, Tex." and phone number, "214 575 5000" are stored in input argument value slots in the Operation Activation structure. Each of these argument values is validated according to the validation.sub.-- rule properties of the associated input argument object and its associated predicate object in the Surrogate Object Type structure 244 using the Validate Input Argument function in the Surrogate Object Manager 390 as shown at block 958. This module returns a validation.sub.-- status and validation.sub.-- message to the Operation Requester 378 which can now take appropriate action if the input argument value is invalid as determined at decision block 966. Once all input arguments have been transferred to the Operation Activation structure at decision block 768, the operation's validation.sub.-- rule can be invoked using the Validate Operation Input function at block 974. The operation's validation.sub.-- rule might include expressions which involve more than one argument. Precisely how validation errors are handled may vary depending on the design requirements of the user interface program 368 and the Operation Requester 378, although the normal case might be to abandon processing the operation request and to advise the user interface program that a validation error has occurred. The logic shown in the flowchart in FIG. 11 illustrates the creation of an invalid argument list which is returned to the user interface program 368 for processing as required. Once the input arguments have been validated successfully and if no errors have been found at decision block 976, the Surrogate Object Manager 390 Start Operation Execution function is called at block 980 with the SOT.name, operation.name and activation.sub.-- ID, with no callback.sub.-- pointer and the async/sync.sub.-- flag="async". The Start Operation Execution function allows an operation to be invoked either synchronously--with no response until the operation completes or an error occurs, asynchronously with call-back of a user-supplied module by the Operation Connection Manager 394 or 426 on operation completion or error, or asynchronously with polling where detection of completion is handled by the Operation Requester 378 polling for change in activation.sub.-- status. In both scenarios described hereinabove, the Start Operation Execution function is called with no callback.sub.-- pointer and in the asynchronous mode. With either of the asynchronous approaches, the user interface program 368 and/or the Operation Requester 378 can be designed to allow multiple, potentially long running operations to be started without waiting for the first to have completed. The operation of the Operation Requester 378 as illustrated in the flowchart shown in FIG. 11 shows a polling approach to detect operation completion. The narrative continues with the description of the Start Operation Execution function of the Surrogate Object Manager 390 as illustrated in the flowchart in FIG. 12. Had a callback.sub.-- pointer been provided, at decision block 1102 the Start Operation Execution function in the Surrogate Object Manager 390 would update the equivalent property on the current operation activation record as shown at block 1104. In all cases, the Start Operation Execution function invokes the Get Operation Type function at block 1106 using the SOT.name and operation.name to get the name of the correct Operation Connection Manager 394 or 426. The returned OCM.sub.-- name is then used to locate and start the appropriate Operation Connection Manager 394 or 426 at block 1108. Once the correct Operation Connection Manager 394 or 426 is started, the Execute Operation function is called at block 1112 with the SOT.name, operation.name and activation.sub.-- ID. If the input async/sync.sub.-- flag value is "async" at decision block 1110, the call to the Execute Operation function at block 1112 is asynchronous so the logic in Start Operation Execution does not wait for a response back from the Operation Connection Manager 394 or 426 before calling the Update Activation Status function at 1118 to set the activation.sub.-- status on the Operation Activation record to "in progress" and to then return control to the Operation Requester 378. This narrative continues with the Execute Operation function in the Operation Connection Manager 394 or 426, as described in the flowchart shown in FIG. 13. In overview, the Execute Operation function is responsible for mapping the input arguments stored in the Operation Activation Structure into a message suitable for transmission to the operation, for the execution of the operation and for generating a mapping of the returned arguments in the message into the output arguments in the Operation Activation. The Execute Operation function then updates the activation.sub.-- status on the Operation Activation record to indicate that the operation has completed successfully. This process involves calling several functions within the Surrogate Object Manager 390. The Execute Operation function first gets a list of the operation's input arguments by calling the Get Input Arguments function at block 1204 with SOT.name and, operation.name. This returns a list of arguments in the same sequence as stored in the Catalog database 64. The sequenced list allows the Operation Connection Manager 394 or 426 to retrieve the arguments from the Operation Activation Structure in the sequence required by the operation. Each input argument value is retrieved from the Operation Activation structure by calling the Get Input Argument Value function of the Surrogate Object Manager 390 using the SOT.name, operation.name, activation.sub.-- ID and the argument.name from the list above. Each retrieved value is processed at block 1208 using whatever input transformation rules 1210 are defined within the Operation Connection Manager 394 or 426 and the resulting transformed argument is added to the message in the Message Send Buffer 1212. Once all the input arguments have been transformed and the message is ready at decision block 1214, the operation's execution.sub.-- name and execution.sub.-- parameters are retrieved from the Surrogate Object Type structure 244 by calling the Get Operation Details function of the Surrogate Object Manager 390 using the SOT.name and operation.name at block 1216. In this scenario, the operation's execution.sub.-- name is CUSTOMER.EXE and the execution.sub.-- parameter is "Add". Using this information the operation is executed and the message sent to it at block 1218. If no system error is detected at decision block 1220, the Operation Connection Manager 394 or 426 waits for a response from the operation. Various approaches can be used to handle this situation. Operation requests and responses can be handled synchronously or asynchronously. The choice may depend on many factors, including the type of communications protocol available between the Operation Connection Manager 394 or 426 and the operation execution environment. However, this choice does not affect the operation of the present invention beyond possibly limiting the throughput if communications are synchronous and operation response times are slow. If well implemented, the operation of the present invention should not add any significant overhead to operation response time. In the meantime the operation executes using the message passed to it as input. In this scenario, the Composer Operation Connection Manager 394 uses a Composer Communications Module 406 and message protocol on top of various standard communications protocols such as LU6.2 or TCP/IP in order to execute the Customer Operation Package, CUSTOMER.EXE 412. CUSTOMER.EXE 412 starts and receives the message and uses the value in the command field to direct the logic flow to the Add.sub.-- Customer operation. The Add.sub.-- Customer operation executes using the arguments customer name, customer address and customer phone number transferred in the body of the message, and a new customer record is added to the Customer database 422. The logic of the Add.sub.-- Customer operation in this scenario is responsible for determining the new customer number. The customer number 10022 is assigned. This number, together with the other input arguments, are formatted into the output message, together with an application response code which indicates successful execution and the message, "Customer added successfully", are included in the returned message. The Operation Connection Manager 394 or 426 meanwhile has been waiting for the operation to respond and to receive the returned message into the Message Receive Buffer 1232. The Operation Connection Manager 394 or 426 must be able to detect whether an error condition has arisen either with the operation execution (it may | ||||||