Creating CORBA Server Applications

Designing and Implementing a Basic CORBA Server Application

This chapter describes how to design and implement a CORBA server application, using the Basic University sample application as an example. The content of this chapter assumes that the design of the application to be implemented is complete and is expressed in OMG IDL. This chapter focuses on design and implementation choices that are oriented to the server application.

This topic includes the following sections:

How the Basic University Sample Application Works

The Basic University sample application provides the student with the ability to browse course information from a central University database. Using the Basic sample application, the student can do the following:

The Basic University Sample Application OMG IDL

In its OMG IDL file, the Basic University sample application defines the following interfaces:

The Basic University sample application is shown in Figure 3-1.

For the purposes of explaining what happens when the Basic University sample application runs, the following separate groups of events are described:

Application Startup

The following sequence shows a typical set of events that take place when the Basic client and server applications are started and the client application obtains an object reference to the Registrar object:

Browsing Course Synopses

The following sequence traces the events that may occur when the student browses a list of course synopses:

Browsing Course Details

The following sequence shows a typical set of events that take place when the client application browses course details:

Design Considerations for the University Server Application

The Basic University sample application contains the University server application, which deals with several fundamental CORBA server application design issues. This section addresses the following topics:

This section also addresses the following two topics:

Design Considerations for Generating Object References

The Basic client application needs references to the following objects, which are managed by the University server application:

The following table shows how these references are generated and returned.

Note the following about how the University server application generates object references:

Design Considerations for Managing Object State

Each of the three objects in the Basic sample application has its own state management requirements. This section discusses the object state management requirements for each.

The RegistrarFactory Object

The RegistrarFactory object does not need to be unique for any particular client request. It makes sense to keep this object in memory and avoid the expense of activating and deactivating this object for each client invocation on it. Therefore, the RegistrarFactory object has the process activation policy.

The Registrar Object

The Basic sample application is meant to be deployed in a small-scale environment. The Registrar object has many qualities similar to the RegistrarFactory object; namely, this object does not need to be unique for any particular client request. Also, it makes sense to avoid the expense of continually activating and deactivating this object for each invocation on it. Therefore, in the Basic sample application, the Registrar object has the process activation policy.

The CourseSynopsisEnumerator Object

The fundamental design problem for the University server application is how to handle a list of course synopses that is potentially too big to be returned to the client application in a single response. Therefore, the solution centers on the following:

The University server application has the CourseSynopsisEnumerator object, which implements this solution. Although this object returns an initial batch of synopses when it is first invoked, this object retains an in-memory context so that the client application can get the remainder of the synopses in subsequent requests. To retain an in-memory context, the CourseSynopsisEnumerator object must be stateful; that is, this object stays in memory between client invocations on it.

When the client is finished with the CourseSynopsisEnumerator object, this object needs a way to be flushed from memory. Therefore, the appropriate state management decision for the CourseSynopsisEnumerator object is to assign it the process activation policy and to implement the CORBA application-controlled deactivation feature.

Application-controlled deactivation is implemented in the destroy() operation on that object.

The following code example shows the destroy() operation on the CourseSynopsisEnumerator object:

void CourseSynopsisEnumerator_i::destroy()
{
        // When the client calls "destroy" on the enumerator,
        // then this object needs to be "destructed".
        // Do this by telling the TP framework that we're
        // done with this object.
 
        TP::deactivateEnable();
}

Basic University Sample Application ICF File

The following code example shows the ICF file for the Basic sample application:

module POA_UniversityB
{
    implementation CourseSynopsisEnumerator_i
    {
        activation_policy  ( process                               );
        transaction_policy ( optional                              );
        implements         ( UniversityB::CourseSynopsisEnumerator );
    };
    implementation Registrar_i
    {
        activation_policy  ( process                               );
        transaction_policy ( optional                              );
        implements         ( UniversityB::Registrar                );
    };
    implementation RegistrarFactory_i
    {
        activation_policy  ( process                               );
        transaction_policy ( optional                              );
        implements         ( UniversityB::RegistrarFactory         );
    };
};

Design Considerations for Handling Durable State Information

Handling durable state information refers specifically to reading durable state information from disk at some point during or after the object activation, and writing it, if necessary, at some point before or during deactivation. The following two objects in the Basic sample application handle durable state information:

The following two sections describe the design considerations for how these two objects handle durable state information.

The Registrar Object

One of the operations on the Registrar object returns detailed course information to the client application. In a typical scenario, a student who has browsed dozens of course synopses may be interested in viewing detailed information on perhaps as few as two or three courses at one time.

To implement this usage scenario efficiently, the Registrar object is defined to have the get_course_details() operation. This operation accepts an input parameter that specifies a list of course numbers. This operation then retrieves full course details from the database and returns the details to the client application. Because the object in which this operation is implemented is process-bound, this operation should avoid keeping any state data in memory after an invocation on that operation is complete.

The Registrar object does not keep any durable state in memory. When the client application invokes the get_course_details() operation, this object simply fetches the relevant course information from the University database and sends it to the client. This object does not keep any course data in memory. No durable state handling is done via the activate_object() or deactivate_object() operations on this object.

The CourseSynopsisEnumerator Object

The CourseSynopsisEnumerator object handles course synopses, which this object retrieves from the University database. The design considerations, with regard to handling state, involve how to read state from disk. This object does not write any state to disk.

There are three important aspects of how the CourseSynopsisEnumerator object works that influence the design choices for how this object reads its durable state:

Given these three aspects, it makes sense for this object to:

Therefore, when the CourseSynopsisEnumerator object is activated, the activate_object() operation on this object does the following:

Using the University Database

Note the following about the way in which the University sample applications use the University database:

For more information on the files you build into the Basic server application, see the Guide to the CORBA University Sample Applications.

How the Basic Sample Application Applies Design Patterns

The Basic sample application uses the following design patterns:

This section describes why these two patterns are appropriate for the Basic sample application and how this application implements them.

Process-Entity Design Pattern

As mentioned in the section Process-Entity Design Pattern on page 1-22, this design pattern is appropriate in situations where you can have one process object that handles data entities needed by the client application. The data entities are encapsulated as CORBA structs that are manipulated by the process object and not by the client application.

Adapting the Process-Entity design pattern to the Basic sample application allows the application to avoid implementing fine-grained objects. For example, the Registrar object is an efficient alternative to a similarly numerous set of course objects. The processing burden of managing a single, coarse-grained Registrar object is small relative to the potential overhead of managing hundreds or thousands of fine-grained course objects.

For complete details about the Process-Entity design pattern, see the Design Patterns technical article.

List-Enumerator Design Pattern

This design pattern is appropriate in situations where an object has generated an internal list of data that is potentially too large to return to the client application in a single response. Therefore, the object must return an initial batch of data to the client application in one response, and have the ability to return the remainder of the data in subsequent responses.

A list-enumerator object must also simultaneously keep track of how much of the data has already been returned so that the object can return the correct subsequent batch. List-enumerator objects are always stateful (that is, they remain active and in memory between client invocations on them) and the server application has the ability to deactivate them when they are no longer needed.

The list-enumerator design pattern is an excellent choice for the CourseSynopsisEnumerator object, and implementing this design pattern provides the following benefits:

Although the Registrar object has the get_courses_synopsis() operation on it, the knowledge of the database query and the synopsis list is embedded entirely in the CourseSynopsisEnumerator object. In this situation, the Registrar object serves only as a means for the client to get the following:

Additional Performance Efficiencies Built into the BEA Tuxedo System

The BEA Tuxedo system implements a performance efficiency in which data marshaling between two objects in the same server process is automatically disabled. This efficiency exists if the following circumstances exist:

An example of this is when the Registrar object creates an object reference to the CourseSynopsisEnumerator object and causes that object to be instantiated. No data marshaling takes place in the requests and responses between those two objects.

Preactivating an Object with State

The preactivate object with state feature allows you to preactivate an object before a client application invokes that object. This feature can be particularly useful for creating iterator objects, such as the CourseSynopsisEnumerator object in the University samples.

Preactivating an object with state centers around using the TP::create_active_object_reference() operation. Typically, objects are not created in a CORBA server application until a client issues an invocation on that object. However, by preactivating an object and using the TP::create_active_object_reference() operation to pass a reference to that object back to the client, your client application can invoke an object that is already active and populated with state.

How You Preactivate an Object with State

The process for using the preactivation feature is to write code in the server application that:

Thus, the preactivated object is created in such a way that the TP Framework invokes neither the Server::create_servant() nor the Tobj_ServantBase::activate_object() operations for that object.

Usage Notes for Preactivated Objects

Note the following when using the preactivation feature: