Stimmen - , Durchschnittliche Bewertung:
(
)
)
Hersteller: HP
Dateigröße: 392.01 kb
Dateiname:
Unterrichtssprache:
Das Dokument wird geladen, bitte warten
 |
Das Dokument wird geladen, bitte warten
Dieses Gerät hat auch andere Anweisungen:
PC Desktops - HP Integrity NonStop H-Series (16.73 mb)
PC Desktops - HP Integrity NonStop H-Series (957.56 kb)
PC Desktops - HP Integrity NonStop H-Series (881.66 kb)
PC Desktops - HP Integrity NonStop H-Series (965.62 kb)
PC Desktops - HP Integrity NonStop H-Series (676.93 kb)
PC Desktops - HP Integrity NonStop H-Series (393.72 kb)
PC Desktops - HP Integrity NonStop H-Series (776.57 kb)
Anleitung Zusammenfassung
The design of an object interface includes the creation of the object references that clients use to refer to objects in the interface. These object
references are created by an object interface associated with the server.
The resolution of issues for object interface design depends on the object references that are created and returned, the strategy for finding and
creating object instances, and other aspects of interface design and use.
Object Roles and Relationships
The following three-tier classification of object roles is not specific to NonStop CORBA but is used throughout this section:
Interface objects typically run on a client workstation or other end-user device, such as a bank-teller input device or a gas-station pump.
Control objects typically run on a server machine. These objects are sometimes called business-transaction objects because each
operation on the object corresponds to a unit of work, such as “withdraw funds from account” or “transfer funds between accounts.”
Entity objects represent persistent data that needs to survive a use case (such as a business transaction).
These are conceptual classifications. Neither CORBA nor NonStop CORBA defines specific interfaces to correspond to these types of objects.
Interface Objects
In general, an interface object can interact with control objects or entity objects. In an OLTP environment, the user usually interacts with an
interface object, which in turn interacts with a control object to initiate a transaction. The control object interacts with one or more entity objects to
perform the transaction. Transactions are almost always performed against more than one database, or at least more than one database record,
so interface objects seldom interact directly with entity objects.
There are no special considerations for interface objects in NonStop CORBA.
Control Objects
Control objects do not interact directly with a database. Instead, they interact with (or coordinate) entity objects, which represent and manipulate
the data.
In some cases, a control object implements an entire transaction and is, therefore, responsible for beginning and committing that transaction.
In other cases, several control objects implement different parts of a transaction. In such cases, a higher-level control object should be defined to
coordinate the work and begin and commit the transaction.
Because a control object does not exist outside a business transaction, a control object does not pose the same types of object-sharing problems
as objects representing shared-data resources.
However, you must consider other issues if the object will be implemented in a server pool—specifically, whether the object needs to maintain
dynamic context between calls. For example, an operation that debits an account can use an account-number parameter to get all the context it
needs from a database, and does not have to retain dynamic state. In contrast, an operation that iterates through a result set must maintain
dynamic state in the form of a cursor for the result set. Whether an object maintains dynamic context between calls has implications for load
balancing, and therefore for application throughput, as described in Parallel Processing and Its Implications.
Entity Objects
An entity object typically represents stored data, although it could also represent a device. Entity objects can be used by either interface objects
or control objects: an interface object need not always use a control object for access to an entity object.
Entity objects are typically shared by multiple clients, usually control objects, so the application designer must expect and prepare for concurrent
invocations of the same object by multiple clients.
An entity object does not typically control other entity objects. The exception occurs when an entity object is a composite of other entity objects;
for example, a customer object could consist of basic customer information from one entity object and transaction history from another.
An entity object need not be persistent to represent persistent data.
Object Distribution
The client programmer does not need to know whether an object is local or remote, so long as the application and the framework or library have
been designed with local/remote transparency in mind. However, object distribution has implications for application performance.
If possible, design and distribute your objects according to the following guidelines:
Avoid the use of global state information. Global state information limits an application's ability to take advantage of the scalability features
of NonStop CORBA and the NonStop systems.
Put the objects with the most interactions closest together.
If a control object has many interactions with an entity object—for example, doing a linear search of many entity objects—and the control
object has a few well-defined interfaces to an interface object, place the control object on the same machine as the entity object.
Likewise, if a control object uses a database directly, you should locate the object on the same machine as the database.
Minimize the number of interactions with a remote object.
Design both data and operations so that interactions with remote objects require as few remote operations as possible. (This approach
also benefits performance when the target object is local, although not so dramatically.)
For example, if a control or entity object returns to a client an object consisting of many read-only attributes, consider returning a struct
instead. The get_ operations for accessing attributes are translated into individual network messages, whereas structs are passed by
value as part of the operation that returns them.
The following example shows an IDL object definition with multiple attributes:
...Dieses Handbuch ist für folgende Modelle:
PC Desktops - HP Integrity NonStop J-Series (392.01 kb)
PC Desktops - HP NonStop L-Series (392.01 kb)