Glossary

Note: In the following definitions, words shown in italics are terms for which separate glossary entries are also defined.

abstract class

A class that is not designed to be instantiated, but serves as a base class for the definition of subclasses. Regardless of whether an abstract class inherits instance data and methods from parent classes, it will always introduce methods that must be overridden in a subclass, in order to produce a class whose objects are semantically valid.
affinity group
An array of class objects that were all registered with the SOMClassMgr object during the dynamic loading of a class. Any class is a member of at most one affinity group.
ancestor class
A class from which another class inherits instance methods, attributes, and instance variables, either directly or indirectly. A direct descendant of an ancestor class is called a child class, derived class, or subclass. A direct ancestor of a class is called a parent class, base class, or superclass.
aggregate type
A user-defined data type that combines basic types (such as, char, short, float, and so on) into a more complex type (such as structs, arrays, strings, sequences, unions, or enums).
apply stub
A procedure corresponding to a particular method that accepts as arguments: the object on which the method is to be invoked, a pointer to a location in memory where the method's result should be stored, a pointer to the method's procedure, and the method's arguments in the form of a va_list. The apply stub extracts the arguments from the va_list, invokes the method with its arguments, and stores its result in the specified location. Apply stubs are registered with class objects when instance methods are defined, and are invoked using the somApply function. Typically, implementations that override somDispatch call somApply to invoke a method on a va_list of arguments.
attribute
A specialized syntax for declaring "set" and "get" methods. Method names corresponding to attributes always begin with "_set_" or "_get_". An attribute name is declared in the body of the interface statement for a class. Method procedures for get/set methods are automatically defined by the SOM Compiler unless an attribute is declared as "noget/noset". Likewise, a corresponding instance variable is automatically defined unless an attribute is declared as "nodata". IDL also supports "readonly" attributes, which specify only a "get" method. (Contrast an attribute with an instance variable.)
auxiliary class data structure:
A structure provided by the SOM API to support efficient static access to class-specific information used in dealing with SOM objects. The structure's name is <className>CClassData. Its first component (parentMtab) is a list of parent-class method tables (used to support efficient parent method calls). Its second component (instanceDataToken) is the instance token for the class (generally used to locate the instance data introduced by method procedures that implement methods defined by the class).
base class
See parent class.
behavior (of an object)
The methods that an object responds to. These methods are those either introduced or inherited by the class of the object. See also state.
bindings:
Language-specific macros and procedures that make implementing and using SOM classes more convenient. These bindings offer a convenient interface to SOM that is tailored to a particular programming language. The SOM Compiler generates binding files for C and C ++. These binding files include an implementation template for the class and two header files, one to be included in the class's implementation file and the other in client programs.
BOA (basic object adapter) class:
A CORBA interface (represented as an abstract class in DSOM), which defines generic object-adapter (OA) methods that a server can use to register itself and its objects with an ORB (object request broker). See also SOMOA (SOM object adapter) class.
callback
A user-provided procedure or method to the Event Management Framework that gets invoked when a registered event occurs. (See also event ).
casted dispatching
A form of method dispatching that uses casted method resolution; that is, it uses a designated ancestor class of the actual target object's class to determine what procedure to call to execute a specified method.
casted method resolution
A method resolution technique that uses a method procedure from the method table of an ancestor of the class of an object (rather than using a procedure from the method table of the object's own class).
child class
A class that inherits instance methods, attributes, and instance variables directly from another class, called the parent class, base class, or superclass, or indirectly from an ancestor class. A child class may also be called a derived class or subclass.
class
A way of categorizing objects based on their behavior (the methods they support) and shape (memory layout). A class is a definition of a generic object. In SOM, a class is also a special kind of object that can manufacture other objects that all have a common shape and exhibit similar behavior. The specification of what comprises the shape and behavior of a set of objects is referred to as the "definition" of a class. New classes are defined in terms of existing classes through a technique known as inheritance. See also class object.
class variable
Instance data of a class object. All instance data of an object is defined (through either introduction or inheritance) by the object's class. Thus, class variables are defined by metaclasses.
class data structure
A structure provided by the SOM API to support efficient static access to class-specific information used in dealing with SOM objects. The structure's name is <className>ClassData. Its first component (classObject) is a pointer to the corresponding class object. The remaining components (named after the instance methods and instance variables) are method tokens or data tokens, in order as specified by the class's implementation. Data tokens are only used to support data (public and private) introduced by classes declared using OIDL; IDL attributes are supported with method tokens.
class manager
An object that acts as a run-time registry for all SOM class objects that exist within the current process and which assists in the dynamic loading and unloading of class libraries. A class implementor can define a customized class manager by subclassing SOMClassMgr class to replace the SOM-supplied SOMClassMgrObject. This is done to augment the functionality of the default class-management registry (for example, to coordinate the automatic quiescing and unloading of classes).
class method
(Also known as factory method or constructor.) A class method is a method that a class object responds to (as opposed to an instance method). A class method that class <X> responds to is provided by the metaclass of class <X>. Class methods are executed without requiring any instances of class <X> to exist, and are frequently used to create instances of the class.
class object
The run-time object representing a SOM class. In SOM, a class object can perform the same behavior common to all objects, inherited from SOMObject.
client code
(Or client program or client.) An application program, written in the programmer's preferred language, which invokes methods on o bjects that are instances of SOM classes. In DSOM, this could be a program that invokes a method on a remote object.
constructor
See class method.
context expression
An optional expression in a method's IDL declaration, specifying identifiers whose value (if any) can be used during SOM's method resolution process and/or by the target object as it executes the method procedure. If a context expression is specified, then a related Context parameter is required when the method is invoked. (This Context parameter is an implicit parameter in the IDL specification of the method, but it is an explicit parameter of the method's procedure.) No SOM-supplied methods require context parameters.
CORBA
The Common Object Request Broker Architecture established by the Object Management Group. IBM's Interface Definition Language used to describe the interface for SOM classes is fully compliant with CORBA standards.
daemon
See DSOM daemon.
data token
A value that identifies a specific instance variable within an object whose class inherits the instance variable (as a result of being derived, directly or indirectly, from the class that introduces the instance variable). An object and a data token are passed to the SOM run-time procedure, somDataResolve, which returns is a pointer to the specific instance variable corresponding to the data token. (See also instance token.)
derived class
See subclass and subclassing.
derived metaclass
(Or SOM-derived metaclass.) A metaclass that SOM creates automatically (often even when the class implementor specifies an explicit metaclass) as needed to ensure that, for any code that executes without method-resolution error on an instance of a given class, the code will similarly execute without method-resolution error on instances of any subclass of the given class. SOM's ability to derive such metaclasses is a fundamental necessity in order to ensure binary compatibility for client programs despite any subsequent changes in class implementations.
descriptor
(Or method descriptor.) An ID representing the identifier of a method definition or an attribute definition in the Interface Repository. The IR definition contains information about the method's return type and the type of its arguments.
directive
A message (a pre-defined character constant) received by a replica from the Replication Framework. Indicates a potential failure situation.
dirty object
A persistent object that has been modified since it was last written to persistent storage.
dispatch-function resolution
Dispatch-function resolution is the slowest, but most flexible, of the three method-resolution techniques SOM offers. Dispatch functions permit method resolution to be based on arbitrary rules associated with an object's class. Thus, a class implementor has complete freedom in determining how methods invoked on its instances are resolved. See also dispatch method and dynamic dispatching.
dispatch method
A method (such as somDispatch or somClassDispatch) that is invoked (and passed an argument list and the ID of another method) in order to determine the appropriate method procedure to execute. The use of dispatch methods facilitates dispatch-function resolution in SOM applications and enables method invocation on remote objects in DSOM applications. See also dynamic dispatching.
DLL
Abbreviation for dynamic link library.
DSOM daemon (somdd)
The DSOM process (somdd) that locates and activates servers. The daemon (actually known as the location services daemon) is primarily meant to provide a client with the necessary communications information to allow the client to connect with an implementation server.
dynamic dispatching
Method dispatching using dispatch-function resolution; the use of dynamic method resolution at run time. See also dispatch- function resolution and dynamic method.
Dynamic Invocation Interface (DII)
The CORBA-specified interface, implemented in DSOM, that is used to dynamically build requests on remote objects. Note that DSOM applications can also use the somDispatch method for dynamic method calls when the object is remote. See also dispatch method.
dynamic link library
A piece of code that can be loaded (activated) dynamically. This code is physically separate from its callers. DLLs can be loaded at load time or at run time. Widely used term on OS/2, Windows, and, to some extent, AIX.
dynamic method
A method that is not declared in the IDL interface statement for a class of objects, but is added to the interface at run time, after which instances of the class (or of its subclasses) will respond to the registered dynamic method. Because dynamic methods are not declared, usage bindings for SOM classes cannot support their use; thus, offset method resolution is not available. Instead, name-lookup or dispatch-function method resolution must be used to invoke dynamic methods. (There are currently no known uses of dynamic methods by any SOM applications.) See also method and static method.
encapsulation
An object-oriented programming feature whereby the implementation details of a class are hidden from client programs, which are only required to know the interface of a class (the signatures of its methods and the names of its attributes) in order to use the class's methods and attributes.
encoder/decoder
In the Persistence Framework, a class that knows how to read/write the persistent object format of a persistent object. Every persistent object is associated with an Encoder/Decoder, and an encoder/decoder object is created for each attribute and instance variable. An Encoder/Decoder is supplied by the Persistence Framework by default, or an application can define its own.
entry class
In the Emitter Framework, a class that represents some syntactic unit of an interface definition in the IDL source file.
Environment parameter
A CORBA-required parameter in all method procedures, it represents a memory location where exception information can be returned by the object of a method invocation. [Certain methods are exempt (when the class contains a modifier of callstyle=oidl), to maintain upward compatibility for client programs written using an earlier release.]
emitter
Generically, a program that takes the output from one system and converts the information into a different form. Using the Emitter Framework, selected output from the SOM Compiler (describing each syntactic unit in an IDL source file) is transformed and formatted according to a user-defined template. Example emitter output, besides the implementation template and language bindings, might include reference documentation, class browser descriptions, or "pretty" printouts.
event
The occurrence of a condition, or the beginning or ending of an activity that is of interest to an application. Examples are elapse of a time interval, sending or receiving of a message, and opening or closing a file. (See also event manager and callback.)
event manager (EMan)
The chief component of the Event Management Framework that registers interest in various events from calling modules and informs them through callbacks when those events occur.
factory method
See class method.
ID:
See somId.
IDL source file
A user-written .idl file, expressed using the syntax of the Interface Definition Language (IDL), which describes the interface for a particular class (or classes, for a module). The IDL source file is processed by the SOM Compiler to generate the binding files specific to the programming languages of the class implementor and the client application. (This file may also be called the "IDL file," the "source file," or the "interface definition file.")
implementation
(Or object implementation.) The specification of what instance variables implement an object's state and what procedures implement its methods (or behaviors). In DSOM, a remote object's implementation is also characterized by its server implementation (a program).
Implementation Repository
A database used by DSOM to store the implementation definitions of DSOM servers.
implementation statement
An optional declaration within the body of the interface definition of a class in a SOM IDL source file, specifying information about how the class will be implemented (such as, version numbers for the class, overriding of inherited methods, or type of method resolution to be supported by particular methods). This statement is a SOM-unique statement; thus, it must be preceded by the term "#ifdef __SOMIDL__" and followed by "#endif". See also interface declaration.
implementation template
A template file containing stub procedures for methods that a class introduces or overrides. The implementation template is one of the binding files generated by the SOM Compiler when it processes the IDL source file containing class interface declarations. The class implementor then customizes the implementation, by adding language-specific code to the method procedures.
implicit method parameter
A method parameter that is not included in the IDL interface specification of a method, but which is a parameter of the method's procedure and which is required when the method is invoked from a client program. Implicit parameters include the required Environment parameter indicating where exception information can be returned, as well as a Context parameter, if needed.
incremental update
A revision to an implementation template file that results from reprocessing of the IDL source file by the SOM Compiler. The updated implementation file will contain new stub procedures, added comments, and revised method prototypes reflecting changes made to the method definitions in the IDL specification. Importantly, these updates do not disturb existing code that the class implementor has defined for the prior method procedures.
inheritance
The technique of defining one class (called a subclass, derived class, or child class) as incremental differences from another class (called the parent class, base class, superclass, or ancestor class). From its parents, the subclass inherits variables and methods for its instances. The subclass can also provide additional instance variables and methods. Furthermore, the subclass can provide new procedures for implementing inherited methods. The subclass is then said to override the parent class's methods. An overriding method procedure can elect to call the parent class's method procedure. (Such a call is known as a parent method call.)
inheritance hierarchy
The sequential relationship from a root class to a subclass, through which the subclass inherits instance methods, attributes, and instance variables from all of its ancestors, either directly or indirectly. The root class of all SOM classes is SOMObject.
instance
(Or object instance or just object.) A specific object, as distinguished from a class of objects. See also object.
instance method
A method valid for an object instance (as opposed to a class method, which is valid for a class object). An instance method that an object responds to is defined by its class or inherited from an ancestor class.
instance token
A data token that identifies the first instance variable among those introduced by a given class. The somGetInstanceToken method invoked on a class object returns that class's instance token.
instance variables
(Or, instance data.) Variables declared for use within the method procedures of a class. An instance variable is declared within the body of the implementation statement in a SOM IDL source file. An instance variable is "private" to the class and should not be accessed by a client program. (Contrast an instance variable with an attribute.)
interface
The information that a client must know to use a class namely, the names of its attributes and the signatures of its methods . The interface is described in a formal language (the Interface Definition Language, IDL) that is independent of the programming language used to implement the class's methods.
interface declaration
(Or interface statement.) The statement in the IDL source file that specifies the name of a new class and the names of its parent class(es). The "body" of the interface declaration defines the signature of each new method and any attribute(s) associated with the class. In SOM IDL, the body may also include an implementation statement (where instance variables are declared or a modifier is specified, for example to overridea method).
Interface Definition Language (IDL)
The formal language (independent of any programming language) by which the interface for a class of objects is defined in a .idl file, which the SOM Compiler then interprets to create an implementation template file and binding files. SOM's Interface Definition Language is fully compliant with standards established by the Object Management Group's Common Object Request Broker Architecture (CORBA).
Interface Repository (IR)
The database that SOM optionally creates to provide persistent storage of objects representing the major elements of interface definitions. Creation and maintenance of the IR is based on information supplied in the IDL source file. The SOM IR Framework supports all interfaces described in the CORBA standard.
Interface Repository Framework
A set of classes that provide methods whereby executing programs can access the persistent objects of the Interface Repository to discover everything known about the programming interfaces of SOM classes.
IR
Abbreviation for Interface Repository.
location services daemon (somdd)
A process whose primary purpose is to give DSOM clients the communications information that they need to connect with an implementation server.
macro
An alias for executing a sequence of hidden instructions; in SOM, typically the means of executing a command known within a binding file created by the SOM Compiler.
metaclass
A class whose instances are classes. In SOM, any class descended from SOMClass is a metaclass. The methods a class inherits from its metaclass are sometimes called class methods (in Smalltalk) or factory methods (in Objective-C) or constructors. See also class method.
metaclass incompatibility
A situation where a subclass does not include all of the class variables or respond to all of the class methods of its ancestor classes. This situation can easily arise in OOP systems that allow programmers to explicitly specify metaclasses, but is not allowed to occur in SOM. Instead, SOM automatically prevents this by creating and using derived metaclasses whenever necessary.
method
A combination of a procedure and a name, such that many different procedures can be associated with the same name. In object-oriented programming, invoking a method on an object causes the object to execute a specific method procedure. The process of determining which method procedure to execute when a method is invoked on an object is called method resolution. (The CORBA standard uses the term "operation" for method invocation). SOM supports two different kinds of methods: static methods and dynamic methods. See also static method and dynamic method.
method descriptor
See descriptor.
method ID
A number representing a zero-terminated string by which SOM uniquely represents a method name. See also somId.
method pointer
A pointer type that identifies one method procedure on a single class. Method pointers are not ensured to be persistent among multiple processes.
method procedure
A function or procedure, written in an arbitrary programming language, that implements a method of a class. A method procedure is defined by the class implementor within the implementation template file generated by the SOM Compiler.
method prototype
A method declaration that includes the types of the arguments. Based on method definitions in an IDL source file, the SOM Compiler generates method prototypes in the implementation template. A class implementor uses the method prototype as a basis for writing the corresponding method procedurecode. The method prototype also shows all arguments and their types that are required to invoke the method from a client program.
method resolution
The process of selecting a particular method procedure, given a method name and an object instance. The process results in selecting the particular function/procedure that implements the abstract method in a way appropriate for the designated object. SOM supports a variety of method-resolution mechanisms, including offset method resolution, name-lookup resolution, and dispatch-function resolution.
method table
A table of pointers to the method procedures that implement the methods that an object supports. See also method token.
method token
A value that identifies a specific method introduced by a class. A method token is used during method resolution to locate the method procedure that implements the identified method. The two basic method-resolution procedures are somResolve (which takes as arguments an object and a method token, and returns a pointer to a procedure that implements the identified method on the given object) and somClassResolve (which takes as arguments a class and a method token, and returns a pointer to a procedure that implements the identified method on an instance of the given class).
modifier
Any of a set of statements that control how a class, an attribute, or a method will be implemented. Modifiers can be defined in the implementation statement of a SOM IDL source file. The implementation statement is a SOM-unique extension of the CORBA specification. [User-defined modifiers can also be specified for use by user-written emitters or to store information in the Interface Repository, which can then be accessed via methods provided by the Interface Repository Framework.]
module
The organizational structure required within an IDL source file that contains interface declarations for two (or more) classes that are not a class-metaclass pair. Such interfaces must be grouped within a module declaration.
multiple inheritance
The situation in which a class is derived from (and inherits interface and implementation from) multiple parent classes.
name-lookup method resolution
Similar to the method resolution techniques employed by Objective-C and Smalltalk. It is significantly slower than offset resolution. Name-lookup resolution, unlike offset resolution, can be used when the name of the method to be invoked is not known until run time, or the method is added to the class interface at run time, or the name of the class introducing the method is not known until run time.
naming scope:
See scope.
object
(Or object instance or just instance.) An entity that has state (its data values) and behavior (its methods). An object is one of the elements of data and function that programs create, manipulate, pass as arguments, and so forth. An object is a way to encapsulate state and behavior. Encapsulation permits many aspects of the implementation of an object to change without affecting client programs that depend on the object's behavior. In SOM, objects are created by other objects called classes.
object adapter (OA)
A CORBA term denoting the primary interface a server implementation uses to access ORB functions; in particular, it defines the mechanisms that a server uses to interact with DSOM, and vice versa. This includes server activation/deactivation, dispatching of methods, and authentication of the principal making a call. The basic object adapter described by CORBA is defined by the BOA (basic object adapter) abstract class; DSOM's primary object adapter implementation is provided by the SOMOA (SOM Object Adapter) class.
object definition
See class.
object implementation
See implementation.
object instance
See instance and object.
object reference
A CORBA term denoting the information needed to reliably identify a particular object. This concept is implemented in DSOM with a proxy object in a client process, or a SOMDObject in a server process. See also proxy object and SOMDObject.
object request broker (ORB)
See ORB.
offset method resolution:
The default mechanism for performing method resolution in SOM, because it is the fastest (nearly as fast as an ordinary procedure call). It is roughly equivalent to the C ++ "virtual function" concept. Using offset method resolution requires that the name of the method to be invoked must be known at compile time, the name of the class that introduces the method must be known at compile time (although not necessarily by the programmer), and the method to be invoked must be a static method.
OIDL
The original language used for declaring SOM classes. The acronym stands for Object Interface Definition Language. OIDL is still supported by SOM release 2, but it does not include the ability to specify multiple inheritance classes.
one-copy serializable
The consistency property of the Replication Framework which states that the concurrent execution of methods on a replicated object is equivalent to the serial execution of those same methods on a nonreplicated object.
OOP
An acronym for "object-oriented programming."
operation
See method.
operation logging
In the Replication Framework, a technique for maintaining consistency among replicas of a replicated object, whereby the execution of a method that updates the object is repeated at the site of each replica.
ORB (object request broker)
A CORBA term designating the means by which objects transparently make requests (that is, invoke methods) and receive responses from objects, whether they are local or remote. With SOMobjects Developer Toolkit and Runtimes, this functionality is implemented in the DSOM Framework. Thus, the DSOM (Distributed SOM) system is an ORB. See also BOA (basic object adapter) class and SOMOA (SOM object adapter) class.
overridden method
A method defined by a parent class and reimplemented (redefined or overridden) in the current class.
override
(Or overriding method.) The technique by which a class replaces (redefines) the implementation of a method that it inherits from one of its parent classes. An overriding method can elect to call the parent class's method procedure as part of its own implementation. (Such a call is known as a parent method call.)
parent class
A class from which another class inherits instance methods, attributes, and instance variables. A parent class is sometimes called a base class or superclass.
parent method call
A technique where an overriding method calls the method procedure of its parent class as part of its own implementation.
persistent object
An object whose state can be preserved beyond the termination of the process that created it. Typically, such objects are stored in files.
polymorphism
An object-oriented programming feature that may take on different meanings in different systems. Under various definitions of polymorphism, (a) a method or procedure call can be executed using arguments of a variety of types, or (b) the same variable can assume values of different types at different times, or (c) a method name can denote more than one method procedure. The SOM system reflects the third definition (for example, when a SOM class overrides a parent class definition of a method to change its behavior). The term literally means "having many forms."
principal
The user on whose behalf a particular (remote) method call is being performed.
procedure
A small section of code that executes a limited, well-understood task when called from another program. In SOM, a method procedure is often referred to as a procedure. See also method procedure.
process
A series of instructions (a program or part of a program) that a computer executes in a multitasking environment.
proxy object
In DSOM, a SOM object in the client's address space that represents a remote object. The proxy object has the same interface as the remote object, but each method invoked on the proxy is overridden by a dispatch method that forwards the invocation request to the remote object. Under DSOM, a proxy object is created dynamically and automatically in the client whenever a remote method returns a pointer to an object that happens to be remote.
readers and writers
In the Replication Framework, different processes can access the same replicated object in different modes. A "reader" is a process that does not intend to update the object, but wants to continually watch the object as other processes update it. A "writer" is a process that wants to update the object, as well as continually watch the updates performed by others.
receiver
See target object.
redispatch stub
A procedure, corresponding to a particular method, which has the same signature as the method's procedure but which invokes somDispatch to dispatch the method. The somOverrideMtab method can be used to replace the procedure pointers in a class's method table with the corresponding redispatch stubs. This is done when overriding somDispatch to customize method resolution so that all static method invocations will be routed through somDispatch for selection of an appropriate method procedure. (Dynamic methods have no entries in the method table, so they cannot be supported with redispatch functionality.)
reference data
Application-specific data that a server uses to identify or describe an object in DSOM. The data, represented by a sequence of up to 1024 bytes, is registered with DSOM when a server creates an object reference. A server can later ask DSOM to return the reference data associated with an object reference. See also object reference.
replica
When an object is replicated among a set of processes (using the Replication Framework), each process is said to have a replica of the object. From the view point of any application model, the replicas together represent a single object.
replicated object
An object for which replicas (copies) exist. See replica.
run-time environment
The data structures, objects, and global variables that are created, maintained, and used by the functions, procedures, and methods in the SOM run-time library.
scope
(Or naming scope.) That portion of a program within which an identifier name has "visibility" and denotes a unique variable. In SOM, an IDL source file forms a scope. An identifier can only be defined once within a scope; identifiers can be redefined within a nested scope. In a .idl file, modules, interface statements, structures, unions, methods, and exceptions form nested scopes.
serializable
See one-copy serializable.
server
(Or server implementation.) In DSOM, a process, running in a distributed environment, that executes the implementation of an object. DSOM provides a default server implementation that can dynamically load SOM class libraries, create SOM objects, and make those objects accessible to clients. Developers can also write application-specific servers for use with DSOM.
server object
In DSOM, every server has an object that defines methods for managing objects in that server. These methods include object creation, object destruction, and maintaining mappings between object references and the objects they reference. A server object must be an instance of the class SOMDServer (or one of its subclasses). See also object reference and SOMDObject.
shadowing
In the Emitter Framework, a technique that is required when any of the entry classes are subclassed. Shadowing causes instances of the new subclass(es) (rather than instances of the original entry classes) to be used as input for building the object graph, without requiring a recompile of emitter framework code. Shadowing is accomplished by using the macro SOM_SubstituteClass.
signature
The collection of types associated with a method (the type of its return value, if any, as well as the number, order, and type of each of its arguments).
sister class object
A duplicate of a class object that is created in order to save a copy of the class's original method table before replacing the method table to customize method resolution. The sister class object is created so that some original method procedures can be called by the replacement method procedures.
Sockets class
A class that provides a common communications interface to Distributed SOM, the Replication Framework, and the Event Management Framework. The Sockets class provides the base interfaces (patterned after TCP/IP sockets); the subclasses TCPIPSockets, NBSockets, and IPXSockets provide actual implementations for TCP/IP, Netbios, and Netware IPX/SPX, respectively.
SOM Compiler
A tool provided by the SOM Toolkit that takes as input the interface definition file for a class (the .idl file) and produces a set of binding files that make it more convenient to implement and use SOM classes.
SOMClass
One of the three primitive class objects of the SOM run-time environment. SOMClass is the root (meta)class from which all subsequent metaclasses are derived. SOMClass defines the essential behavior common to all SOM class objects.
SOMClassMgr
One of the three primitive class objects of the SOM run-time environment. During SOM initialization, a single instance (object) of SOMClassMgr is created, called SOMClassMgrObject. This object maintains a directory of all SOM classes that exist within the current process, and it assists with dynamic loading and unloading of class libraries.
SOM-derived metaclass:
See derived metaclass.
SOMDObject
The class that implements the notion of a CORBA "object reference" in DSOM. An instance of SOMDObject contains information about an object's server implementation and interface, as well as a user-supplied identifier.
somId
A pointer to a number that uniquely represents a zero-terminated string. Such pointers are declared as type somId. In SOM, somId's are used to represent method names, class names, and so forth.
SOMObject
One of the three primitive class objects of the SOM run-time environment. SOMObject is the root class for all SOM (sub)classes. SOMObject defines the essential behavior common to all SOM objects.
SOMOA (SOM object adapter) class
In DSOM, a class that dispatches methods on a server's objects, using the SOM Compiler and run-time support. The SOMOA class implements methods defined in the abstract BOA class (its base class). See also BOA class.
somSelf
Within method procedures in the implementation file for a class, a parameter pointing to the target object that is an instance of the class being implemented. it is local to the method procedure.
somThis
Within method procedures, a local variable that points to a data structure containing the instance variables introduced by the class. If no instance variables are specified in the SOM IDL source file, then the somThis assignment statement is commented out by the SOM Compiler.
state (of an object)
The data (attributes, instance variables and their values) associated with an object. See also behavior.
static method
Any method that can be accessed through offset method resolution. Any method declared in the IDL specification of a class is a static method. See also method and dynamic method.
stub procedures
Method procedures in the implementation template generated by the SOM Compiler. They are procedures whose bodies are largely vacuous, to be filled in by the implementor.
subclass
A class that inherits instance methods, attributes, and instance variables directly from another class, called the parent class, base class, superclass, or indirectly from an ancestor class. A subclass may also be called a child class or derived class.
subclassing
The process whereby a new class, as it is created (or derived), inherits instance methods, attributes, and instance variables from one or more previously defined ancestor classes. The immediate parent class(es) of a new class must be specified in the class's interface declaration. see also inheritance.
superclass
See parent class.
symbol
In the Emitter Framework, any of a (standard or user-defined) set of names (such as, className) that are used as placeholders when building a text template to pattern the desired emitter output. When a template is emitted, the symbols are replaced with their corresponding values from the emitter's symbol table. Other symbols (such as, classSN) have values that are used by section-emitting methods to identify major sections of the template (which are correspondingly labeled as "classS" or by a user-defined name).
target object
(Or receiver.) The object responding to a method call. The target object is always the first formal parameter of a method procedure. For SOM's C-language bindings, the target object is the first argument provided to the method invocation macro, _methodName.
usage bindings
The language-specific binding files for a class that are generated by the SOM Compiler for inclusion in client programs using the class.
value logging
In the Replication Framework, a technique for maintaining consistency among replicas of a replicated object, whereby the new value of the object is distributed after the execution of a method that updates the object.
view-data paradigm
A Replication Framework construct similar to the Model-View-Controller paradigm in SmallTalk. The "view" object contains only presentation-specific information, while the "data" object contains the state of the application. The "view" and "data" are connected by means of an "observation" protocol that lets the "view" be notified whenever the "data" changes.
writers
See readers and writers.

---

[Back: Trademarks]
[Next: ]