Advanced Object Management Using Inprise AppCenter

By: David Intersimone

Abstract: To be successful in business today requires highly reliable applications. AppCenter enables you to manage these complex applications delivering reliability your e-business customers demand.

Advanced Object Management Using Inprise AppCenter

by Stephen Tindall
Inprise Corporation

Assumptions

This paper assumes the reader has a basic under standing of CORBA and the problems associated with managing distributed applications. It also assumes a basic understanding of the capabilities that a product like Inprise AppCenter provides.

Introduction

This document was originally written to explain how Visibroker objects could be managed on IBMs OS/390 platform even though Inprise AppCenter does not run there. I have made the paper more generic to include any platform that supports CORBA. Just because Inprise AppCenter does not run on a particular platform, most make the assumption that objects running there cannot be managed. This is not true, objects can still be fully managed  the only limitations over other supported platforms are that AppCenter cannot start and stop the processes that contain the CORBA object(s). However, by using the Visibroker Object Activation Daemon or OAD (an implementation of the CORBA Implementation Repository), objects can be automatically started when a client request is received and terminated when they are no longer required  essentially providing a sub-set of the same functionality as a fully supported AppCenter platform.

Non-Inprise platform support

The functionality outlined above is not limited to platforms that support the Visibroker OAD. AppCenter can be used to manage any CORBA object. As you will see below, AppCenter communicates with the objects via an IDL interface over standard IIOP. This means that any ORB object could be managed as long as it conforms to the OMGs IIOP protocol specification.

Lets take the ORBIX product from IONA as an example. ORBIX has an Implementation Repository running in orbixd. AppCenter will automatically register objects with orbixd so that they can be started upon demand. Once a object has been started AppCenter will continue to ping the object (see the management interface below) until it is shutdown. AppCenter will then automatically de-register it from orbixd so that it can no longer be started in the ORBIX environment. This is extremely powerful functionality not provided by IONA.

The AppCenter Management architecture

AppCenter is a runtime application management tool that monitors the distributed components of your application. In a typical scenario there is a daemon process running on each host in your CORBA domain called the AppCenter Agent. The Agent is responsible for doing two major types of work:

    1. it receives commands from a user at a console (via the AppCenter middle tier) like start, stop, ping, fail-over etc. and then performs those commands on the appropriate object or process, and

    2. it continually monitors the processes and objects in the application and reports changes in the application status to the AppCenter middle tier which in-turn triggers events which can be trapped and acted on or simply displayed in the console.

When dealing with processes the AppCenter Agent continually looks in the Operating System process table to see if the process that it started is still alive. Using this method, AppCenter is able to report almost immediately when a process dies or goes away for some reason. As you can imagine this is useful but not sufficient. What happens if the process doesnt die but becomes internally corrupted? Using the above method only, AppCenter would report no failures when in fact the process may not even be responding to requests and may be completely useless.

To eliminate this situation and to have much tighter control over whats actually happening inside a CORBA server, the AppCenter Agent actually communicates with a server process at the object level. It does this by loading a CORBA aware driver that sends IIOP requests to the objects inside the server. All that you as a developer need do to obtain this functionally is implement an AppCenter Management Object in your server. The details of this interface are set out below.

AppCenters Managed Object Interface

The managed object interface is made available developers to define their own ping and shutdown of processes for particular CORBA objects. In some cases, the objects that you are monitoring will be performing a very specific or unusual process. In others, the operations of the object mean that default pinging procedures are unsuitable for your particular requirements. The actual process of determining the state of an object may be particularly complicated and lengthy and require some custom programming on your part.

In such instances, it may be necessary to define your own ping process. AppCenter enables you to do this and to incorporate this unique ping into AppCenter's polling cycle. It does this by enabling you to override the managed object operation implementations with your own chosen implementations. Your implementation will then be invoked to ping the manageable object or to shut it down.

The managed object interface contains four operations:

  • Prepare shutdown
  • Can shutdown
  • Shutdown
  • Ping

The ping operation is used to administer the user-defined ping to selected manageable objects. The shutdown functions can operate in concert to produce a graceful shutdown with its associated cleanups.

The AppCenter Managed Object Interface:

    module Management
    {
        interface Maintained {
            oneway void prepareShutdown();
            long canShutdown();
            oneway void shutdown();
            boolean ping() ;
        };
    };
    

Ping( )

A user-defined ping on a specific managed object is executed in AppCenter in the same way as any other ping. However you have defined the ping, the success of a ping operation is determined by the single value that is returned from the managed object. A return value of 0 means that the ping was successful and that the object is in an up state. A return value of anything else means that the managed object is down or unavailable.

Shutting down a server

The process of stopping a managed object with the management object interface follows a well-defined pattern. The only decision point for the user is whether a graceful shutdown is to be attempted or not. If this is the case, the procedure will run until the managed object is returned to a stopped (or unmanaged) state.

prepareShutdown( )

The beginning of a graceful shutdown occurs if you have set a property to do so. The driver then calls the propose shutdown operation to prepare the object to shutdown.

The driver will invoke canshutdown() until it either gets a confirmation to do so or after a time-out period calls the shutdown operation.

canShutdown( )

This operation is called by the driver after the propose shutdown has been called. Whether the shutdown proceed is determined by the single value that the managed object returns. If this value is 0, then the Shutdown operation will be called and the shutdown will proceed gracefully. This means that the clean up has been completed and a graceful shut down can be done.

If any other value is returned, it means that the cleaning up of the object has not been completed. The managed object will be flagged as Stopping. If after a default time-out of two minutes, the object is still in a Stopping state, a forceful shutdown is initiated. That is, the shutdown operation is called on the object.

shutdown( )

This action completes the shutdown process, regardless of whether it was a graceful or forceful one.

Flexible AppCenter Driver Architecture

Combine the above management interface with a set of drivers that allow you to define the fundamental management properties like start and stop commands as well as pre-start and post-stop initialization and clean-up commands and you can really customize that way AppCenter manages your application. AppCenter actually lets you define what start means. For example, in the ORBIX example given earlier  starting the object would in fact mean registering it with orbixd. Stopping the object would actually mean un-registering it. Likewise you can have AppCenter execute a command after stopping the object to do any required clean up. This makes management extremely flexable.

Conclusion

To be successful in business today requires highly reliable applications. These applications need to be built on robust distributed frameworks such as CORBA. While distributed applications provide scalability, they also increase complexity. AppCenter enables you to manage these complex applications and deliver the reliability your e-business customers demand. You have seen here that it is quite trivial to have AppCenter manage right down to the object or component level. It enables you to manage from the application, rather than from the hardware perspective, because it's the application that enables your business to function. Even if you havent based your CORBA infrastructure on Visibroker, management is not out of reach. Inprise AppCenter could make the difference in the success of your application.


Server Response from: ETNASC01