VisiBroker Configuration Reference

VisiBroker Configuration Reference VERSION 1.6 InpriseAppCenter Inprise Corporation, 100 Enterprise Way Scotts Valley, CA 95066-3249

Copyright 1998, 1999 Inprise Corporation. All rights reserved. All Inprise and Borland brands and product names are trademarks or registered trademarks of Inprise Corporation. Other brands and product names are trademarks or registered trademarks of their respective owners. Printed in the U.S.A. ACE0016WW21003 1E1R599 9900010203-9 8 7 654321 PDF

Contents Chapter 1 Introduction 1-1 This manual s target................ 1-1 AppCenter documentation............ 1-1 VisiBroker-compliant versions.......... 1-2 CORBA type.................... 1-2 VisiBroker browsers.............. 1-2 CORBA basics................... 1-2 CORBA objects................. 1-3 Architecture of the ORB............ 1-3 Object Adapter................. 1-4 OA options................... 1-4 VisiBroker basics.................. 1-5 About the Performance Monitor....... 1-6 What s in this book................ 1-7 Manual conventions................ 1-8 Contacting Inprise developer support...... 1-8 Chapter 2 Managing CORBA objects and processes 2-1 CORBA and application modeling........ 2-1 Building an application model........ 2-2 Starting and stopping components...... 2-3 Getting the status................ 2-4 Dependencies.................. 2-5 Load balancing................. 2-5 Fault tolerance................. 2-5 Locating an object............... 2-5 Cleaning up..................... 2-6 Chapter 3 Using VisiBroker browsers 3-1 Using VisiBroker browsers............ 3-1 Browsers available............... 3-2 Starting browsers................ 3-2 Drag and drop usage.............. 3-2 Using browsers with the viewer....... 3-2 Using browsers with the cockpit....... 3-3 Naming Service.................. 3-3 Interface features................ 3-3 Adding objects to a configuration in AppCenter................... 3-3 Location Service................... 3-4 Interface features................ 3-4 Adding objects to a configuration in AppCenter................... 3-5 Interface Repository................ 3-6 Interface features................ 3-6 Accessing the Interface Repository...... 3-6 Object Activation Daemon............. 3-6 Interface features................ 3-6 Adding servers to a configuration in AppCenter................... 3-7 Performance Monitor browser.......... 3-8 Interface features................ 3-8 Using the Performance Monitor browser with AppCenter................ 3-8 Adding CORBA objects to a cockpit....... 3-9 Getting statistics from a CORBA configuration example............. 3-10 Adding an object to a configuration..... 3-11 Adding the object to a cockpit........ 3-11 Monitoring the object............. 3-12 Chapter 4 Building CORBA configurations 4-1 Basic CORBA modeling.............. 4-1 Servers...................... 4-1 Defining VisiBroker server readiness..... 4-2 Objects...................... 4-3 Locating objects................. 4-3 Performance concepts.............. 4-4 Manageable object concepts.......... 4-4 Management object concepts.......... 4-5 VisiBroker management interface concepts..................... 4-5 Starting........................ 4-5 VisiBroker servers................ 4-5 OAD servers................... 4-5 VisiBroker objects................ 4-5 OAD objects................... 4-6 Delays in starting VisiBroker objects..... 4-6 Stopping....................... 4-6 VisiBroker servers................ 4-6 VisiBroker objects................ 4-6 OAD objects................... 4-7 i

Pinging....................... 4-7 VisiBroker servers............... 4-7 OAD servers.................. 4-7 Objects...................... 4-7 Configuration-specific information....... 4-7 VisiBroker 3.2 C++ servers............ 4-8 Creating object and servers............ 4-8 VisiBroker object property inheritance..... 4-9 Updating VisiBroker objects..........4-10 Chapter 5 Using the Performance Monitor 5-1 Statistics collection overview........... 5-1 Interceptor.................... 5-1 Monitor Agent................. 5-1 AppCenter Performance Monitor engine.. 5-2 Cockpit display................. 5-2 Performance Monitor browser........ 5-3 Enabling statistics collection........... 5-3 Manual statistics collection.......... 5-3 Automatic statistics collection........ 5-3 Cockpit hosted statistics.............. 5-4 Creating user-defined statistics.......... 5-5 Data structures for objects........... 5-5 Data structures for attributes......... 5-8 Java code examples................ 5-8 Adding a user defined statistic........ 5-8 Monitor Agent interface.............. 5-11 Chapter 6 Monitor Agent interface reference 6-1 Overview...................... 6-1 CORBA attributes............... 6-1 Methods..................... 6-1 Exceptions.................... 6-2 Data types.................... 6-2 Reference...................... 6-3 add_attribute.................. 6-3 all_attributes.................. 6-4 AllObjectsStatusSeq.............. 6-4 Attribute..................... 6-4 AttributeConfigElement............ 6-5 AttributeConfigSeq............... 6-5 AttributeNotFound.............. 6-5 AttributeType.................. 6-6 BufferSizeFull................. 6-6 delete_attribute()................ 6-7 DistributionList................. 6-7 monitor..................... 6-7 object_status().................. 6-8 object_status_all()................ 6-8 object_status_update.............. 6-9 ObjectNotFound................ 6-9 ObjectStatusElement.............. 6-9 ObjectStatusSeq................. 6-9 ObjectTimeElement.............. 6-10 ObjectTimeSeq................. 6-10 server_id()................... 6-10 StatusElement................. 6-11 Chapter 7 VisiBroker CORBA driver properties 7-1 About the CORBA Driver............. 7-1 Process cycle................... 7-2 Driver function................. 7-2 Starting........................ 7-3 VisiBroker object................. 7-3 OAD activated VisiBroker object....... 7-3 VisiBroker server................ 7-4 OAD activated VisiBroker server....... 7-4 Pinging........................ 7-4 VisiBroker object................. 7-4 OAD activated VisiBroker object....... 7-6 VisiBroker server................ 7-6 OAD activated VisiBroker server....... 7-7 Stopping....................... 7-7 VisiBroker object................. 7-7 Comment..................... 7-8 OAD activated VisiBroker object....... 7-8 VisiBroker server................ 7-9 OAD activated VisiBroker server....... 7-9 CORBA Properties................. 7-9 Standard.................... 7-10 VisiBroker................... 7-11 Command options............... 7-14 Infrastructure................. 7-16 Chapter 8 CORBA API for AppCenter 8-1 List of CORBA API operations.......... 8-1 CORBA API usage considerations........ 8-2 How to find the AppCenter object...... 8-2 Error returns................... 8-2 Exporting the environment settings...... 8-2 ii

iii C development kit............... 8-3 CORBA development kit........... 8-3 accreateevent................... 8-3 accycle....................... 8-4 acdecrement.................... 8-4 acfailover..................... 8-5 acfindobject.................... 8-5 acgetchildren................... 8-6 acgetobjecthost.................. 8-7 acgetobjectlabel................. 8-7 acgetobjectstatus................. 8-8 acgetobjecttype.................. 8-8 acgetpropertyvalue................ 8-9 acidle........................8-10 acincrement.....................8-10 aclogin.......................8-10 aclogout...................... 8-11 acsetpropertyvalue................8-12 acstart........................8-12 acstop........................8-13 Example of API usage.............. 8-13 How to compile the test_client.cpp program.................... 8-14 How to run this test_client.exe program.................... 8-16 Example of a Java test client........... 8-16 Chapter 9 CORBA-managed object interface 9-1 Introduction to the managed object interface.. 9-1 IDL definition.................... 9-1 Ping operation description............. 9-3 Ping operation.................. 9-3 Shutdown operation description......... 9-3 Prepare shutdown................ 9-5 Can shutdown.................. 9-5 Shutdown.................... 9-5 IDL implementation................ 9-6 Index I-1

Tables 4.1 Supplied VisiBroker runtime libraries.. 4-8 7.1 CorbaObject.................7-10 7.2 CorbaContainer...............7-10 7.3 OnDemandObject..............7-10 7.4 CorbaServer................. 7-11 7.5 VB_BaseObject............... 7-11 7.6 VB_Object.................. 7-11 7.7 OAD_Object.................7-12 7.8 VB_Server.................. 7-12 7.9 OAD_Server................ 7-13 7.10 ORB options................ 7-14 7.11 BOA options................ 7-15 7.12 Name service................ 7-16 7.13 Location Service.............. 7-16 7.14 VB_Configuration............. 7-17 7.15 VB_BaseServer............... 7-17 Figures 1.1 CORBA architecture............. 1-3 3.1 Accessing the VisiBroker browsers.... 3-3 3.2 Selecting root name............. 3-4 3.3 Copying a location object.......... 3-5 3.4 Opening the Interface Repository..... 3-6 3.5 Copying an OAD.............. 3-7 3.6 Opening the Performance Monitor.... 3-8 3.7 Copying to a cockpit............ 3-9 4.1 Creation wizard options.......... 4-2 4.2 Templates for objects actioned by AppCenter.................. 4-9 4.3 Templates for objects actioned by the OAD................... 4-10 4.4 Templates for servers actioned by AppCenter.................. 4-10 4.5 Templates for servers actioned by the OAD................... 4-10 5.1 Performance monitor architecture...... 5-3 5.2 Statistics gathering with a wizard..... 5-4 5.3 Object data structure............. 5-5 5.4 Attribute data structure........... 5-8 9.1 Shutting down a managed object...... 9-4 iv

Chapter 1 Chapter1Introduction This manual s target Inprise AppCenter is capable of managing a number of types of middleware. One of the most important of these is VisiBroker. This manual addresses the specific procedures and considerations that are entailed in managing distributed applications that use a variety of CORBA as their middleware. It also addresses specifically the use of Inprise s VisiBroker browsers and how they integrate with AppCenter. This book is not intended as a replacement for the AppCenter User s Guide. Rather, it is an adjunct to it. The basic requirements for managing distributed applications are all addressed in the AppCenter User s Guide. This book deals exclusively with the considerations of managing VisiBroker applications. In this book, you will be shown the specific considerations of managing VisiBroker CORBA distributed applications. All information that can be applied to AppCenter generally or to more than one type of middleware are discusses in the AppCenter User s Guide. AppCenter documentation The AppCenter documentation set includes the following: The AppCenter Getting Started. It describes the basic features of AppCenter and includes tutorial chapters that explain how to use them. It also provides information on installing AppCenter. The AppCenter User s Guide. It includes complete information about AppCenter s components and explains in detail how to use AppCenter s features. Introduction 1-1

VisiBroker-compliant versions Note This manual, which provides information about dealing with distributed applications that employ VisiBroker as their middleware. All books are available online in HTML and PDF format. VisiBroker-compliant versions CORBA type CORBA basics AppCenter 1.6 manages VisiBroker CORBA 3.2 and 3.3. Earlier versions may be used with AppCenter, but these have not been certified. CORBA is not a brand or type of object middleware in itself. Rather, it is a specification, published by the Open Management Group. Various manufacturers produce a range of CORBA implementations, (such as Iona with ORBIX and Inprise with its VisiBroker). Technically, objects from different vendors can communicate with each other, communication between different implementations being made possible by the IIOP (Internet Inter- ORB Protocol). This version of AppCenter can only be used to manage VisiBroker CORBA middleware. VisiBroker browsers As part of managing CORBA objects implemented with VisiBroker, AppCenter1.6 has surfaced a number of VisiBroker browsers in its interface which can be used to create application configurations and to monitor objects and implementations identified in the browsers. The browsers used are Naming Service Location Service Interface Repository Object Activation Daemon Performance Monitor Common Object Request Broker Architecture (CORBA) is a middleware specification, not an actual product. It is an agreed product definition for middleware. CORBA is based around the creation of interface specifications, not actual code. These specifications are written in an open Interface Definition Language (IDL) that defines a component s parameters (its interfaces) with 1-2 VisiBroker Configuration Reference

CORBA objects other components. These components are portable across languages, tools, operating systems, and networks. The CORBA Object Request Broker (ORB) is the middleware that establishes client/server relationships between objects. Components locate each other and inter-operate on the ORB. CORBA is structured to allow the integration of a wide variety of object systems. It also specifies an extensive range of services for creating and deleting objects and implementations, accessing them by name, storing them in persistent stores, externalizing their states and defining the relationships between them. As CORBA services become available, you will be able to create an object and make it transactional, secure, lockable and persistent by making it multiply inherit from the appropriate services by plugging-in the appropriate middleware capabilities. CORBA objects CORBA objects are binary components that can be accessed by remote invocations. Clients don t need to know where an object is located or which operating system it executes on, nor how the server object is implemented. What the client needs to know is what interface the server object implements. Architecture of the ORB The ORB, as middleware, intercepts the client/server invocation and is responsible for finding an object that can handle the request, pass it the parameters, invoke the operation and return the results. Figure 1.1 CORBA architecture Stubs are the client side invocation mechanism whereas skeletons are the server-side interfaces for requests. Introduction 1-3

Object Adapter Object Adapter This sits on the ORB s core communication services and accepts requests for service from clients. The object adapter is the principle way that an object implementation accesses services provided by the ORB. The VisiBroker OA provides several functions to clients and the servers that they use, including Registering object implementations with the VisiBroker Smart Agent. Installing and registering object implementations with the Implementation Repository and activating the object implementations on client request with the OAD. The OA s main purpose is to allow the object server to interact with the ORB. Persistent, or globally scoped, objects are used to provide long term tasks or are activated by an OAD registration. You can create a persistent object for a server when it is globally scoped; that is, its name is registered with the Smart Agent. These persistent references remain valid beyond the lifetime of the processes that create them. This is distinct from objects which are locally scoped that are not given object names when instantiated. The three activation policies available are 1 Shared object: Only one server is launched regardless of the number of clients; the clients share the server. Shared servers are the most common types of servers. 2 Un-shared object: These are processes that are used, at the most, by one object. A client program causes this type of server to be activated. Once that client exits, the un-shared server exits. 3 Per-operation object: This requires that a server process be started for each operation that is invoked. After the operation has been completed, the server will exit. Subsequent operation invocations on the same object will require a new server to be started. OA options The VisiBroker for Java (VBJ) and the VisiBroker for C++ (VBC++) ORBs share a number of OA options. There are, however, a number of specific options for each product: Common options OAConnectionMax OAconnectionMaxidle OAid OAipAddr OAport OAthreadMax OAthreadMaxIdle 1-4 VisiBroker Configuration Reference

VisiBroker basics VisiBroker basics VBJ only OAthreadmin VBC++ only OAagent OAgarbageCollectTimer OAlocalIPC OArcvbufsize OAsendbufsize OAshmisze (Windows only) OAtcpNoDelay OAthreadStackSize AppCenter operates in conjuction with VisiBroker by including a range of VisiBroker browsers in its interface. These browsers can be used in AppCenter either to view CORBA objects that they have identified or to include them in configurations contained in the AppCenter repository. The tools are based on the CORBA 2.0 specification published by the OMG (Object Management Group). The tools that can be used with AppCenter are Naming Service Location Service Interface Repository Object Activation Daemon Naming Service The Naming Service browser is a graphical tool that displays in hierarchical form the contents of the naming service running on your network and that enables you to register object names at runtime. The services (either Java or C++) are full implementations of the OMG s CORBA naming service specification. Client applications use the Naming Service to find the names of the objects that they need. A naming service implements an extended naming service factory. They also provide a default context (called a root context), which is a VisiBroker extension of the CORBA specification. This makes it easy to locate naming contexts. These root contexts are used to create the hierarchy of its contents. A name (or name space) is made up of three components: A root context which is a naming context with no parent context. It can contain child naming contexts and objects. A Naming Context which can contain child naming contexts and objects. It can be bound to other naming contexts in the name space. A Name Binding that consists of an object reference and its associated Name and Kind identifiers. Each Name Binding must be uniquely identified within its associated naming context. Introduction 1-5

About the Performance Monitor The CORBA specification defines rules for names within a name space. On startup, the browser automatically searches for all of the root contexts on your network. When you start the naming service, it is this list that is displayed. Location Service The Location Service provides a visual interface that lets you locate and browse object instances registered with Smart Agents on your network. It provides a view of the VisiBroker ORB s location service, a VisiBroker extension to the CORBA specification that works with objects that have been implemented with VisiBroker ORBs. On startup, the list of active object is blank. To view a list of objects, you need to refresh the display. The Location Service then searches for all active objects registered with Smart Agents on your network. This view can be filtered to show or hide objects, based on criteria such as Repository ID, Instance, Host and Port. Interface Repository The Interface Repository displays, in a hierarchical form, the contents of the interface repositories available on your network. On startup, the browser automatically searches for all of the interface repositories on your network. Object Activation Daemon The Object Activation Daemon (OAD) is the VisiBroker incarnation of the CORBA implementation repository. It provides a run time repository of information about the classes that a server supports, the objects that are instantiated and their IDs. It is also used to automatically activate an implementation when a client requests a bind to an object. On startup, the browser automatically searches for the OAD running on hosts on your network. All objects registered with an OAD are stored in an implementation repository so that the OAD knows how to activate it when requested. You can add an object implementation to the repository. You can also update object implementations. About the Performance Monitor The Performance Monitor is a monitoring and reporting tool that collects performance statistics for distributed objects on VisiBroker CORBA networks. The Performance Monitor can display these statistics as real time graphs. In AppCenter, the Performance monitor can be used to add CORBA servers, interfaces, object interfaces and operation names to an AppCenter cockpit where they can be graphed with AppCenter instruments. 1-6 VisiBroker Configuration Reference

What s in this book What s in this book Performance monitoring uses four AppCenter components: Interceptor Monitor Agent Performance Monitor Engine Performance Monitor Browser For more information on these components and how they operate, see Statistics collection overview on page 5-1. This manual is organized into the following chapters: Chapter 1, Introduction, explains the purposes of this book and system requirements. Chapter 2, Managing CORBA objects and processes, deals with the special considerations that you need to be aware of when managing VisiBroker distributed applications. Chapter 3, Using VisiBroker browsers, lists the VisiBroker browsers that can be used in conjuction with AppCenter and how you use them. Chapter 4, Building CORBA configurations, addresses how AppCenter wizards can be used to help you build VisiBroker configurations and explains the key decision points in the process. Chapter 5, Using the Performance Monitor, discusses the AppCenter Performance Monitor and how it monitors VisiBroker applications. Chapter 6, Monitor Agent interface reference, describes the MonitorAgent interface, which is defined in the monitor.idl file that comes with the Performance Monitor package. Chapter 7, VisiBroker CORBA driver properties, explains AppCenter s VisiBroker driver and how you can use the properties of VisiBroker objects to tailor their behavior. Chapter 8, CORBA API for AppCenter, describes the IDL for accessing AppCenter and how it is used. Chapter 9, CORBA-managed object interface, explains how to implement this interface to provide VisiBroker servers with enhanced management capabilities. Introduction 1-7

Manual conventions Manual conventions This manual uses the typefaces and symbols described in the table below to indicate special text. Typeface or symbol Meaning This icon indicates an online resource. Monospace type Monospaced text represents text as it appears on screen or in code. It also represents anything you must type. [ ] Square brackets in text or syntax listings enclose optional items. If using the optional item, do not type the brackets. Boldface Boldfaced words in text represent reserved words. Italics Italicized words in text represent identifiers, such as variables. Keycaps This typeface indicates a key on your keyboard. For example, Press Esc to exit a menu. Contacting Inprise developer support Inprise offers a variety of support options. These include free services on the Internet, where you can search our extensive information base and connect with other users of Inprise products. In addition, you can choose from several categories of telephone support, ranging from support on installation of the Inprise product to fee-based consultant-level support and detailed assistance. For more information about Inprise s developer support services, please see our Web site at http://www.inprise.com/devsupport, call Inprise Assist at (800) 523-7070, or contact our Sales Department at (800) 632-2864. When contacting support, be prepared to provide complete information about your environment, the version of the product you are using, and a detailed description of the problem. 1-8 VisiBroker Configuration Reference

Chapter 2 CORBA and application modeling Chapter2Managing CORBA objects and processes Distributed applications, such as CORBA applications, increasingly require that they be submitted to modeling to produce a coherent management design. Generally, the modeling process is used in connection with the design and architecture phases of an application s lifecycle. That model is then implemented by a team of programmers when they build the application itself. Another form of application model is also necessary however, once the application has been successfully built and tested. This application model is known as the management model. This model represents the implementation and delivery of the application on a specific set of deployed resources. Distributed applications in particular require this form of modeling because of the inherent difficulty associated in managing and maintaining them. The management model provides a means of describing the key aspects of the application deployment so as to allow management systems, operators, help desk staff, system administrators, configuration managers, and others to understand what the deployment truly involves. The management model is not the same as the object model used to design the application, but it does take that model into account. The types of information that are prime considerations in a management model include: The current state of the application and its components. This includes the rules necessary to decide if an individual component is working (up) or not (down). It may also include information concerning the performance of various components and possible corrective actions that can be taken. The scalability of the various distributed components. That is, knowing and describing the load-balancing issues associated with each component and the rules that govern it. Managing CORBA objects and processes 2-1

Building an application model The fault-tolerant aspects of each component of the distributed application. The dependency relationships between internal components and between components and various external resources. The hardware on which the application is to run. This includes both the systems and the network topology. The middleware used to distribute the application (for example CORBA, DCOM, RPC, Messaging, and so forth). The underlying operating systems, file systems, disks, and so on. By defining this information and bringing it together in a single management model, you can greatly ease the burden of the deploying and managing distributed applications. Building an application model Building a management model involves breaking down a distributed application into its constituent components and then identifying the various relationships that exist between them. Some components are more important than others for various reasons, most commonly because they represent the core services required by the application client to complete a specific function. These services should be monitored for status, and perhaps for performance. These services may be CORBA objects or server processes or some other manageable entity. A given management model will probably contain a number of each. Objects or processes? The first issue to contend with is that of what the definition of a component should be. The difficulty arises because the answer will vary from application to application, object to object, and installation to installation. Each component really just represents a particular section of the distributed application that it makes sense to manage as a single entity. In reality, what you are doing is defining the granularity of the entities that you are managing. While CORBA is an object oriented environment and you do design distributed objects; in most current operating systems these objects are implemented inside processes which run on that system. The line between object and process becomes blurred when object factories are implemented. An object factory is a process that only contains a small number of objects (perhaps only one), and clients use this object as a way to access or create other temporary objects. Do each of the temporary objects need to be managed, or is it good enough to only manage the more permanent objects, or the process they reside in? 2-2 VisiBroker Configuration Reference

Starting and stopping components There are a number of issues to be considered when trying to divide a distributed application into discrete, logical units: The coarser the granularity, the easier the application is to manage. It is pointless to have thousands of objects implementations in your management model, each of which represents a temporary object that is only around for a very short time. It is equally pointless to have only your application represented as one object. The finer the granularity, the more management information will be available, and the more control you will have over the application. It is important to get the right balance for the amount of information that you make available. If the model is too coarse grained, you may not have enough information and control. A model that is too finely grained, on the other hand, becomes unwieldy and impractical to manage. You can manage certain parts of an application purely at the process level, even though those processes may contain objects. It may not be important for post-development staff to understand or deal with those objects. If you gather statistics associated with a particular process or object, then you need to include that item as part of your model. It is sometimes easier to start with the architectural model of the objects and delete the ones that are not important to the management model. Then group the remainder together by function or by process or some other characteristic that makes sense. You will often now start to see the basic pattern for the management model emerge. It may be extremely useful for AppCenter to actually start VisiBroker runtime components, such as the Object Activation Daemon (OAD), naming services, and so on. This way, dependency relationships can be created between objects and the infrastructure that they require to survive. In AppCenter, a VisiBroker managed object can be A unique CORBA object A CORBA server A CORBA object that is contained within a CORBA server. In the last two instances, the server can be configured to be started either by AppCenter, or by the OAD. Starting and stopping components The next stage in building a management model is to take each component and to start and to stop it and to determine if the actions of starting and stopping the object have any significance within the logical structure of the model. Managing CORBA objects and processes 2-3

Getting the status If the component is a process or server, then this just means deciding when the process should start up. If you want it running all the time, then it is best to let AppCenter start and stop it. If, however, you want it to start only when one of the objects it contains is in use, then the OAD should control the process. If the component is an object, then it is necessary to decide if starting and stopping actually makes any sense. Perhaps it does if this object lives inside an executable which is controlled by the OAD. It may then be useful to model this fact. It may also be that starting or, more likely, stopping an object may require some special action to be performed (such as invoking a particular operation in that interface to tell it to close down gracefully). This type of information should also form part of the model. Getting the status One of the most fundamental things we want to know about every component is its current status, is it up or down? It is therefore important to ask what the significance of an up status for this component is. The answer can sometimes be challenging as the options are numerous. Ultimately, you must decide what are the minimum criteria that must be met to ensure that a component (be it object or process) is working correctly and is available for use by clients. For a process, this will involve options such as checking that the process ID is still in the operating system process table. It may even require calling an interface or function in the server to verify that it is working. For an object, this can involve checking that the process it is running in is available, ensuring that it is registered in the appropriate naming services and OAD. It may involve calling a particular operation in the object to get the final clearance. It is with objects that we get an interesting difference in the definition of what constitutes an up state. With a process, an up state will almost always mean that the process is currently running and ready to receive requests from clients. With an object this may not necessarily be the case. If the object is registered with the OAD, so that the server in which it is located will start whenever the object is needed, we have a case where the object may not be (or even need to be) running all of the time. It may only be needed twice a day, at the opening and closing of business, for example. The definition of up in this case may merely mean available; that is, the object would start if anybody needed it. In this case, the object s state would be displayed in AppCenter as up, perhaps only because it is registered with the OAD and naming service. You may want to go further to confirm its state and every now and then actually start the object, just to ensure it will start if needed. Whatever the case, the status of this object would have a different feel to it than the status of a simple process. 2-4 VisiBroker Configuration Reference

Dependencies Dependencies Dependency relationships are an important aspect of management modeling. With them, you can define that certain components will not work without other components being in an operational state first. One component depends upon another. This can effect both the starting and stopping of components. Objects that are contained in servers have an automatic dependency on their containing server. Load balancing Load balancing using VisiBroker tools is supported by the CORBA middleware itself. If a client tries to contact a particular object and there is more than one instance of the required object available, the middleware will share the load between them. A management model should represent this as a group relationship. Inside the group are all of the objects that are deemed as being able to provide the necessary service. In the management model, you can define how many of these servers you want to be up. You are also be able to define a set of rules to use to ensure that the optimum number of servers are always available, based on the current load conditions. Fault tolerance Fault tolerance using VisiBroker tools is also supported by the CORBA middleware itself. If a client can no longer contact a particular server, then the CORBA middleware redirects the request to another running instance of that server. AppCenter can be used to start a secondary copy of a server should the primary instance fail. In this way, by maintaining backup copies of server objects, a reliable service can be maintained. The management model should account for these fault-tolerant relationships so that fail-over operations can be performed either automatically or manually. Locating an object In order to manage a CORBA object, AppCenter needs to know how to locate it. This can be done in a number of ways that involve setting properties that allow AppCenter to locate the object. Typically, AppCenter can be configured to find the object using a CORBA IOR (Interoperable Object Reference), or by looking up the object in the Location Service. The initial location of an object usually occurs when the object is started. Managing CORBA objects and processes 2-5

Cleaning up Cleaning up Objects and servers fail for a number of reasons, such as lack of resources, programmer error, changed configuration, and so on. When they fail, they will generally not exit gracefully and may leave stale references in the naming or location services. Client programs which attempt to bind to these stale references will experience runtime exceptions when they try to invoke a operation on the object. Since AppCenter already detects failures, it can be useful to have the management system remove any stale references in case of failure. 2-6 VisiBroker Configuration Reference

Chapter 3 Chapter3Using VisiBroker browsers There are a range of tools available that provide various functions for the management of distributed VisiBroker applications. AppCenter enables you to integrate the operations of VisiBroker s browsers with AppCenter s own management capabilities. This chapter does not address all of the capacities of the various VisiBroker browsers, only those ones that can be used in AppCenter. For more complete information on the VisiBroker tools, see the VisiBroker Manager User s Guide. Using VisiBroker browsers AppCenter is supplied with a range of browsers to use with VisiBroker CORBA configurations inside its own interface. You are not limited to just viewing the VisiBroker objects and servers that are contained in the VisiBroker browsers. You can use some of the browsers to integrate objects into configurations that you create in AppCenter s repository. You can also use the cockpit to instrument objects identified by the browsers but which may not exist in an AppCenter repository. This facility will be useful for experienced VisiBroker users who may be more familiar with the use of Naming and Location services, for example, than with AppCenter s own interface. AppCenter can also make use of the functions of VisiBroker and proprietary features. For example, you can create a VisiBroker object with the AppCenter wizard in a configuration that is not started by AppCenter, but rather by the VisiBroker Object Activation Daemon. Using VisiBroker browsers 3-1

Browsers available Browsers available AppCenter uses these browsers for the management of distributed CORBA objects. The tools currently available are: Naming Service: This displays in a hierarchical form the contents of the naming servers on your network. Location Service: This provides an interactive view of object instances registered with the VisiBroker Smart Agents. Interface Repository: This displays in a hierarchical form the contents of the interface repositories available on your network. Object Activation Daemon: This manages the implementation repositories available on your network. Performance Monitor: This is used to collect and display performance statistics for CORBA objects. These browsers can be used to help configure VisiBroker CORBA environments but are primarily intended to work within the AppCenter environment. Starting browsers Ensure that the various services are activated on your network before you attempt to access them from AppCenter. For example, you will not be able to use the Naming Service browser from with AppCenter if the actual Naming Service is not running. Drag and drop usage The drag and drop ability to copy an object from the VisiBroker tools to the AppCenter interface is not implemented in this version. You should use the copy and paste method instead. Using browsers with the viewer Note The various VisiBroker tools can be used as browsers inside AppCenter. Some of them can also be used to add objects to configurations inside AppCenter. You can then use the VisiBroker object wizards to edit them. The tools that can be used to add objects to AppCenter configurations are Naming Service Location Service Object Activation Daemon Browsers can only look at one OSAgent port at a time. However, they can be directed to look at different OSAgent ports by reassigning port numbers in the VisiBroker Registry Editor. You will need to close down the AppCenter viewer before you do this. 3-2 VisiBroker Configuration Reference

Using browsers with the cockpit Using browsers with the cockpit Naming Service You are not limited to using the AppCenter Cockpit Design browser to populate your cockpit with objects. AppCenter can also monitor objects that are not in its repository by accessing them via the VisiBroker middleware.you can monitor objects that appear in the VisiBroker Naming Service VisiBroker Location Service VisiBroker Object Activation Daemon VisiBroker Performance Monitor Any object that is in one of these browsers can be used to gain performance statistics by AppCenter (as long as it has been implemented to do so). For more information on this, see Adding CORBA objects to a cockpit on page 3-9. Interface features The Naming Service is an independent window that can display the naming services on your network that are accessible to AppCenter. Adding objects to a configuration in AppCenter The Naming Service can be used to add objects to a configuration within AppCenter. Doing this will automatically create an instance of that object in the AppCenter repository. 1 In AppCenter, open the configuration to which you want to add an object. 2 Click the Tools option in the AppCenter menu bar. 3 Select the VisiBroker Browsers Naming Service option from the context menu. Figure 3.1 Accessing the VisiBroker browsers Using VisiBroker browsers 3-3

Location Service 4 Click the Root Name combo box and select the root context that you want to use. Figure 3.2 Selecting root name Location Service 5 In the Naming Service navigator, go to the object that you want to use in the configuration. 6 Right-click the object and select Copy from the context menu. 7 Move the Naming Service window so you can see AppCenter s Contents or Hierarchy tabs. 8 Right-click the Tab view background and select Paste from the context menu. The object will be added to the AppCenter repository and can be used like any other AppCenter object. Interface features It is possible to sort the contents of the Location Service browser by clicking the mouse in the header column that you want to sort by. In addition, by rightclicking on an object in the Location Service, you can open the Interface Repository browser for that object interface. You can use the filters to refine what is displayed in the Location Service browser. 3-4 VisiBroker Configuration Reference

Adding objects to a configuration in AppCenter Adding objects to a configuration in AppCenter The Location Service can be used to add objects to a configuration within AppCenter. Doing this will automatically create an instance of that object in the AppCenter repository. 1 In AppCenter, open the configuration to which you want to add an object. 2 Click the Tools option in the AppCenter menu bar. 3 Select the VisiBroker Browsers Location Service option from the context menu. 4 Apply the filters in the Location Service to limit the number of locations displayed, if the number is very large. 5 In the Location Service, select the object that you want to use in the configuration. 6 Right-click the object and select Copy from the context menu. Figure 3.3 Copying a location object 7 Move the Location Service window so that you can see AppCenter s Contents or Hierarchy tabs. 8 Right-click the Tab View background and select Paste from the context menu. The object will be added to the AppCenter repository and can be used like any other AppCenter object. Using VisiBroker browsers 3-5

Interface Repository Interface Repository The VisiBroker Interface Repository displayed in AppCenter can only be used for browsing. It can t be used to add objects to either the AppCenter viewer or cockpit. Interface features The Interface Repository is an independent window that enables you to view the interfaces that can be used by AppCenter. Accessing the Interface Repository 1 Click the Tools option in the AppCenter menu bar. 2 Select the VisiBroker Browsers Interface Repository option from the context menu. Figure 3.4 Opening the Interface Repository Object Activation Daemon Interface features The AppCenter Object Activation Daemon incorporates a number of features that make it easy to use within AppCenter. 3-6 VisiBroker Configuration Reference

Adding servers to a configuration in AppCenter The OAD repository details are shown directly on opening the daemon. The OAD Registration information is displayed in a single field at the bottom of the OAD. The OAD interface within AppCenter can be used to edit existing OADs and to create new ones. Adding servers to a configuration in AppCenter The OAD can be used to add servers and their related objects to a configuration within AppCenter. Doing this will automatically create an instance of that server in the AppCenter repository, and then automatically add the associated object contained in that server. By right-clicking on an OAD registration in the OAD, you can open the Interface Repository browser for that object. 1 In AppCenter, open the configuration to which you want to add the object from the OAD. 2 Click the Tools option in the AppCenter menu bar. 3 Select the VisiBroker Browsers Object Activation Daemon option from the context menu. 4 Click the OAD Server Combo box in the browser and select the computer that you want to access. 5 Click the object that you want to use in the configuration. 6 Right-click the object and select Copy from the context menu. Figure 3.5 Copying an OAD Using VisiBroker browsers 3-7

Performance Monitor browser 7 Move the OAD window so that you can see AppCenter s Contents or Hierarchy tabs. 8 Right-click the Tab View background and select Paste from the context menu. The object will be added to the AppCenter repository and can be used like any other AppCenter object. Performance Monitor browser To a certain extent, the Performance Monitor is redundant in AppCenter as all of the instruments which it uses to perform on line metrics are replicated in the AppCenter cockpit. It can however be used to locate objects which are currently running and that have been instrumented to provide performance statistics. Interface features Only the Monitor client is visible. All of the menu bar options have been removed. No VisiBroker performance instruments can be opened in the AppCenter interface. Using the Performance Monitor browser with AppCenter The Performance Monitor can only be used to add CORBA objects, interfaces, object instances, and operation names to an AppCenter cockpit. For information on how to do this, see Adding CORBA objects to a cockpit on page 3-9. Figure 3.6 Opening the Performance Monitor 3-8 VisiBroker Configuration Reference

Adding CORBA objects to a cockpit Adding CORBA objects to a cockpit To use one of the VisiBroker browsers to populate a cockpit, 1 Select the cockpit that you want to populate and click the Design tab. 2 In the AppCenter toolbar, click the Tools option on the menu bar. 3 Select the VisiBroker Browsers option. 4 Select the type of browser that you are going to use (this can be either a naming or location service, an Object Activation Daemon or the Performance Monitor). 5 In the VisiBroker browser, navigate to the object you want to add to the cockpit and select it. 6 Right-click and select the Copy option in the context menu to copy it to the Clipboard. Once you have selected the object, you need to place it in to the cockpit. 1 Move the browser to give you a clear view of the AppCenter Tab View. 2 In the Design tab, right-click the tab background and select Paste from the context menu. The object selected in the broker is then added to the cockpit. Figure 3.7 Copying to a cockpit Using VisiBroker browsers 3-9

Getting statistics from a CORBA configuration example Note 3 Click the Cockpit Design Browser button at the top of the design tab. 4 Click the Instruments tab, select an instrument with which to monitor the object and drag it onto the Design tab. 5 Add a cockpit operator if you require one by selecting it from the Operators tab in the Cockpit Design Browser and dragging it onto the Design tab. 6 In the Design tab, click the Add Relationship tool on the tab toolbar. 7 Click the object and, holding the mouse button down, draw a relationship line between it and the instrument icon (and between it and the operation icon, if one is present). Because you have selected a process to be monitored by the cockpit, it does not necessarily follow that you will be able to gather statistics from it. For example, if you select a VisiBroker process from the Naming Service and that process has not been instrumented to supply statistics, none will be available. Enabling a cockpit A cockpit does not begin to collect and display statistics as soon as it is populated. It needs to be told that statistics gathering can commence. To do this 1 Click the cockpit in the navigator. 2 Right-click to invoke the context menu. 3 Select Actions Enable. This will start the cockpit which will continue to collect statistics even when it is not visible. An enabled cockpit is indicated by a green checkmark next to it in the navigator. Closing a cockpit You do not want cockpits running and consuming bandwidth if they aren t gathering useful information. To close a cockpit, 1 Click the cockpit in the navigator. 2 Right-click to invoke the context menu. 3 Select Actions Disable. This will stop the cockpit. Getting statistics from a CORBA configuration example Before you can access statistics from a CORBA configuration in an AppCenter cockpit, there are a number of conditions that must be met The object that you want to monitor must be able to supply statistics. This can be verified by using the AppCenter Update wizard to ensure that the server that you are using in the configuration has been enabled to collect statistics. The Gather Performance Statistics window in the wizard should indicate that this feature has been turned on. The configuration used must be a real configuration, not a dummy one. 3-10 VisiBroker Configuration Reference

Adding an object to a configuration The configuration must contain a VisiBroker server and that server must be in the naming service that you are going to use. The VisiBroker service that corresponds to the browser that you are going to use must be running. In this instance, it must be either the Naming or Location services or OAD as we are going to add an object to a configuration. The process consists of three distinct parts; adding an object from a VisiBroker browser to the configuration, adding that object to a cockpit and monitoring the object. Adding an object to a configuration 1 Click the configuration that you are going to work with and open it. 2 Click the Tools VisiBroker Browsers option on the menu bar and select the browser that you are going to use. 3 Click an object on the browser and right click to invoke the context menu. Select Copy. 4 Select the configuration s Contents tab. Right click on its background and select Paste from the context menu. 5 Select the configuration s Containment tab. Click the Add Relationship tool and draw a relationship between the object that you have just added and the server you want to use. 6 Click on the configuration object in the navigator and start it. Adding the object to a cockpit Once the configuration is running, you can set up the cockpit to monitor it. 1 Right click on the Cockpits object and select New Cockpit from the context menu. 2 In the New Cockpit dialog, assign the cockpit a name. Then click OK. 3 Open the Cockpits folder and click on the cockpit that you have just created. Select the Design tab. 4 Click the Cockpit Design Browser button. In the Cockpit Design Browser, click the Objects tab and navigate to the object that you have added to the configuration. Click on the object and drag it onto the Design tab. 5 Click on the Cockpit Design Browser s Instruments tab. Select an instrument that shows performance statistics (the line graph for example) and drag it onto the Design tab. Then close the Cockpit Design Browser. 6 Click the Add Relationships button and draw a relationship between the object and the instrument. Using VisiBroker browsers 3-11

Monitoring the object 7 Right click on the object and select Properties from the context menu. 8 In the property editor, click on the Statistics tab. Then click the menu box and select a property to monitor. Click OK. The object is now ready to be monitored. Monitoring the object Note 1 Right click the cockpit in the Navigator and select Actions Enable from the context menu. 2 Click the Cockpit View tab. You will see the instrument that you have selected. The instrument will not display any activity if the object is not being used. You may have to produce this activity yourself if the program is not using the object. 3-12 VisiBroker Configuration Reference

Chapter 4 Chapter4Building CORBA configurations VisiBroker objects can be started, stopped, and pinged in a number of ways, depending on how you have configured the application that they are in. Designing CORBA applications so that they provide optimal performance means that you need to be aware how AppCenter is able to manage and monitor them. This chapter explains how AppCenter manages VisiBroker applications and what it is capable of doing with objects within them. Basic CORBA modeling Servers CORBA servers are the executable files or Java classes that contain the code that implements one or more objects used in an application. Each server can contain a number of objects. When building a configuration, it is not necessary to specify each object, only the ones that are important to the successful running of the application. Servers can be of two types. The first is a server that is started and maintained by AppCenter itself. These are typically long running processes that are required by the application much of the time. These servers are called AppCenter processes or VisiBroker servers. The second type of server is the one that is started on demand by the VisiBroker Object Activation Daemon (OAD). These servers are only running when some part of the application requires one of the objects contained within the server. As such, the server need not be running for much of the time. These servers are referred to as OAD servers. Building CORBA configurations 4-1

Defining VisiBroker server readiness Both of these servers can be created using the VisiBroker Server Wizard. OAD servers will also be created automatically by dragging an object from the OAD browser and dropping it into a configuration. Figure 4.1 Creation wizard options Defining VisiBroker server readiness There will be occasions where you only want objects to be marked as up when the objects that they depend on, such as a Naming service, are up. It is therefor necessary to define what an object s starting requirements are. This is especially the case where an server that others depend on takes a long time to start up. You need to define an object to be associated with each server. In each server, the object is not entered into the location service until the server has started up completely. When you manage that object in AppCenter, you can set the ping after death flag so it will ping the object even when it is down. You then make your other servers dependent upon the object you have created being up. The object will be down to start with and come up after all of its starting requirements are met. Then all the dependent servers can start. Example You have three servers, S1, S2, and S3. You define marker objects in each server, say M1, M2, and M3 for S1, S2, and S3 respectively. After each server completes its startup chores, you create the M1, M2, and M3 instances and invoke boa.obj_is_ready() on each. These are named global objects, so they are registered with the OSAgent and accessible via the Location Service. You tell AppCenter about M1, M2, and M3, making them managed objects. You then set the AM_DONT_DIE property on each of these to false so AppCenter will be looking for these objects via the Location Service. Initially, their state will be down, but eventually each object will come up. Then, write a CORBA client process, say K1, the startup of which is dependent on the objects M1, M2, and M3 being up. This queries the Location Service for objects of the M-type interface. 4-2 VisiBroker Configuration Reference

Objects Objects VisiBroker objects represent the actual objects that are used in the application. Not all VisiBroker objects can be represented (nor should they be). Only two types of VisiBroker objects have been represented and can be modeled: Those that have been externalized (that is, can be found using the location service, name service, or one of the other VisiBroker tools). Those where you know the IOR of the object. In general, it is not important or wise to try to model objects that are transient in nature, as their existence is not an indicator of the overall performance and health of the application. Objects can exist in a configuration as a single entity or they can be contained in a server that has been defined. While it is clear that all CORBA objects are contained in a server, it may be more practical under certain circumstances to only model the object and not its container. For example, if your application uses a database object, AppCenter is not responsible for starting and stopping the database server; in fact you may not even know anything about the actual process that is providing the object. In such an instance, you are better off simply modeling the database object as a stand-alone object and forgetting about the server. In this case, the server is of no real importance to the application. In most cases, however, the server will be associated with the application as well, and so it will make sense to have objects that are contained within the appropriate server. Locating objects When you define an object, you have to tell AppCenter how to find it. The location of an object is very important, as this is the means that AppCenter will use to determine the current state of the object and also to invoke any management functions associated with the object. You can specify the location of an object in one of two ways, Specifying the IOR of the object. Specifying the repository ID, the instance name, and the host on which it runs. If an object is contained in a server that is managed by AppCenter, then AppCenter will also check that the object actually is in the server by comparing the process IDs. This is configurable. An OAD must be uniquely defined by its repository ID, its name, and its host. This is demanded by the OAD itself. Building CORBA configurations 4-3

Performance concepts Performance concepts AppCenter provides a way of automatically adding performance monitoring capabilities to existing CORBA servers, be they Java or C++. It does this by providing a shared library or VisiBroker.jar file that will be executed during the start-up phase of the server (this is done through the use of command-line options). This special initialization provides two things: 1 It creates VisiBroker specific interceptors to allow the gathering of performance information, such as the number of times methods are invoked and the time taken to complete operation calls. This information is forwarded, on request, to AppCenter and is used by the cockpit to provide data for the graphs. It also creates a Performance Monitor Agent object associated with every server. 2 There is an option to give the Performance Monitor Agent object a unique name and it will be registered in the location service. This has a number of practical uses. The most important of these is that it provides an object that can be found easily that will always be inside this particular server (guaranteed by the unique name it is given). You must specify that you want to do performance monitoring on a server before you start it (as it is a command-line option). If you change your mind after the server is started, you will have to stop it and then restart it. Manageable object concepts AppCenter works with Manageable Object. A CORBA object can be managed within AppCenter by supporting the Managed::Maintained interface. The IDL definition for this object is included as part of AppCenter. If developers, when they define major interfaces associated with a server, have those interfaces inherit from the Management::Maintained interface, then AppCenter can provide an extra level of management capabilities. A Manageable Object has a number of methods (one for pinging and a few more for stopping) that need to be implemented by developers. These operations provide you with great flexibility in defining If the object is actually working correctly (that is, if it is in an up state). When an object needs to shutdown (the developer can write specific code to close particular things). The AppCenter wizard allows you to specify to AppCenter that the object supports the managed object interface. You can also instruct AppCenter to ping or shut down the object using this interface. For further information, see CORBA-managed object interface on page 9-1. 4-4 VisiBroker Configuration Reference

OAD objects OAD objects As distinct from VisiBroker objects, OAD objects implementations can have a more formal concept of being started. When AppCenter needs to start an OAD object, it can mean make it available for use. This means register it with the OAD. This is an optional way to start an object. Delays in starting VisiBroker objects Sometimes AppCenter will start a VisiBroker server, but it will take some time for the VisiBroker object to be registered in the OSAgent and become visible in the location service. The best way to deal with this situation is to set the startup latency on the server object. Startup latency is the time that it takes between actually starting the server and when AppCenter should first ping the server to see if it is up. This delay represents the time that it takes to initialize the server. During this time, the server will be marked as Starting. An object that is contained within a server will not be pinged until the server is started, that is, it changes from starting to up. By changing the latency time, you can adjust how long this interval will be. The latency is measured in agent ping intervals. The default is 1, which means that the agent will start the server, skip the first ping, and then send the second ping to verify state. Increase the value for the property to increase the number of ping cycles skipped. Stopping Before any server is stopped, all objects contained in that server are stopped. VisiBroker servers AppCenter will use the appropriate operation to stop this type of server. This may be by using the Management Object, or by using the VisiBroker Management Interface, or by killing the process. VisiBroker objects VisiBroker objects have two phases to stopping. 1 Physically stopping the object. This can be handled by the managed object interface. Often, there is no specific need to stop an object and shutting down the server will suffice. 2 Cleanup. This involves possibly taking the object out of the location service or the naming service so that it is no longer available for use. 4-6 VisiBroker Configuration Reference

OAD objects OAD objects These are the same as VisiBroker objects except that you can also optionally clean up the OAD so that the object is no longer registered and therefore no longer available for use. Pinging VisiBroker servers VisiBroker servers, as they are under the control of AppCenter, will by default be pinged by checking that the PID of the process is still in the process table. Optionally, you can also use the managed object associated with the server to get a more detailed and server-specific ping. OAD servers OAD servers will not be pinged explicitly by AppCenter. Objects VisiBroker objects can be pinged in a variety of ways. Can clients find the object? This is a ping setting that checks to make sure that the object is still in the location service or naming service or OAD (as appropriate). It does not actually contact the object itself. Invoke the _is_nonexistant operation. This will actually invoke the object in question and make sure it is answering requests. While this is fine for VisiBroker objects, it is important that you understand the consequences if you set this for an OAD object. If the OAD object is not currently running when this operation is invoked, the OAD will start it so that it can answer this request. Invoke the managed object interface ping operation. This will do a deeper level of ping and ask the object itself to respond. Again, for OAD Objects this will start the object if it is not currently running. Configuration-specific information AppCenter allows the values of properties to be inherited from the configuration object itself. This feature allows managers to define and change specific property values once at the configuration level and have the change propagate down to all objects and servers in that configuration. Building CORBA configurations 4-7

VisiBroker 3.2 C++ servers While managers can set this up manually to work for any properties, AppCenter has used this mechanism to help manage VisiBroker configurations. If you create a VisiBroker application (or manually add a VisiBroker configuration template to your configuration object), you will see the extra property OSAgentPort. In most circumstances, it is necessary to specify the OSAgentHost. The VisiBroker Server wizard asks you if you want this server to inherit its OSAgent Port from the configuration. If you click this option (it is the default), then whatever value you set at the configuration level for the port (including blank meaning use the default one) will be used by this server. The wizard also lets you assign a port for OSAgents on an object by object basis. VisiBroker 3.2 C++ servers AppCenter ships with different versions of the VisiBroker runtime libraries for different platforms. If you are using C++ servers that require different versions from those shipped with AppCenter, you will need to specify at the server level the path for the libraries to use at. Table 4.1 Platform Creating object and servers Supplied VisiBroker runtime libraries C++ runtime library Windows NT VisiBroker 3.3 Solaris VisiBroker 3.3 AIX VisiBroker 3.2 HP-UX VisiBroker 3.2 There are a number of ways to get servers and objects into a configuration. Use one of the AppCenter s wizards. This is the most convenient way to create a new server or object. There are two distinct wizards, one to create VisiBroker servers and another to create VisiBroker objects. These wizards will guide you though the various steps in order to create a server or object. It will probably be easier if you first define the servers you will need, and then define the objects that will be contained in them. Drag and drop from one of three VisiBroker browsers (a naming service, a location service or an OAD). This infers, of course, that the object (or server) that you are looking for is running at the moment (or currently registered in the OAD). When you drop an object into a configuration, it will be given a number of default property settings. These may or may not be appropriate for the way in which you want to manage the object. It is always advisable to click the object after it has been dropped, select the VisiBroker Update Wizard, and go through the properties to make sure they are set to the values you want. 4-8 VisiBroker Configuration Reference

VisiBroker object property inheritance Copy an object or server from an existing configuration. Again, when you do this, it is useful to go through the update wizard to verify that the object will act as desired. Do it all manually. This involves creating an object in AppCenter and linking the appropriate templates to it. You then need to edit the properties by hand in order to set up the appropriate conditions. This method is not recommended because of the number of properties involved and their complex interaction with each other. For simple changes (like turning on or off a ping setting) it might be easier to use the property editor rather than go though the update wizard. Also, the property editor has the advantage of being able to change the properties associated with a number of objects at the same time. For example, you could select a group of VisiBroker objects, edit them using the property editor, and turn off the ping to the management interface. VisiBroker object property inheritance When you create an object in AppCenter, that object inherits the properties that it uses from the templates that are applied at its creation. Objects that are created to use VisiBroker middleware use different templates, depending upon how they are being used. If you use one of AppCenter s wizards to create an object, AppCenter will automatically apply to the object the templates that it requires to do the job that you specify. If, on the other hand, you choose to manually create an object or want to use templates of your own devising, you will have to manually associate the required templates with the object. We recommend that you use the wizards whenever possible when you are creating objects to ensure that the correct properties are applied to the object. AppCenter activated objects When you create an object that is started by AppCenter and that uses VisiBroker middleware, the object inherits properties from VisiBroker templates that in turn inherit properties from the CORBA template. Figure 4.2 Templates for objects actioned by AppCenter Building CORBA configurations 4-9

Updating VisiBroker objects OAD activated objects When you create an object that is actioned by the VisiBroker Object Activation Daemon, the object s direct property inheritance is from the OAD template. This template itself inherits properties from the OnDemand template and the VB_BaseObject. Figure 4.3 Templates for objects actioned by the OAD AppCenter activated servers VisiBroker servers that are started directly by AppCenter inherit some of their properties from the VB_Server template and indirectly from the CORBAServer template. Figure 4.4 Templates for servers actioned by AppCenter OAD activated servers The property inheritance for VisiBroker servers started by the OAD comes from the OAD_Server template and indirectly from the CORBAServer template. Figure 4.5 Templates for servers actioned by the OAD Updating VisiBroker objects AppCenter has the capability to update VisiBroker objects and servers after they have been created. This is not the same as a refresh operation. The update wizard is identical to the wizard used to create a VisiBroker object. It enables 4-10 VisiBroker Configuration Reference

Updating VisiBroker objects you to proceed, pane by pane, through the wizard that you used to create the object. You can edit it as you go and make any changes that you need. There is a separate wizard for objects and servers. The one that is presented to you depends on the object that you select. You cannot convert the object from a CORBA object to a CORBA server, but most other settings can be changed. The wizard is accessed from the context menu of the selected object. 1 Click the object that you are going to edit. 2 Right-click to invoke the context wizard. 3 Select Update VisiBroker Server. The update wizard will appear. You do not need to re-enter all of the configuration information that was used to create the object. Just use the Next and Back keys to navigate to the part of the wizard where you want to edit information. When you are done, click Finish to save the changes. Building CORBA configurations 4-11

4-12 VisiBroker Configuration Reference

Chapter 5 Chapter5Using the Performance Monitor This chapter explains how you can use the Performance Monitor to obtain performance statistics for presentation in an AppCenter cockpit. Statistics collection overview The Performance Monitor provides AppCenter with an additional source for gathering and representing statistical data. The data passes through five components Interceptor, where it is measured. Monitor Agent, where it is collected. Performance Engine, where it is aggregated. Cockpit, where it is displayed. Performance Monitor Browser, where it can be selected. Interceptor The Interceptor collects statistical data after each operation invocation to the managed object and sends it to the Monitor Agent. Monitor Agent This is not the same as an AppCenter agent. The Monitor Agent stores all the collected statistics in memory. There must be a Monitor Agent within each CORBA server process. The Monitor Agent is itself a CORBA object. Using the Performance Monitor 5-1

AppCenter Performance Monitor engine There are three types of statistical data which the Monitor Agent can collect: Counter statistic: For example, total invokes or failed invokes. Just one number is stored for a counter statistic. Distribution statistic: For example, invoke latency or input buffer size. For these statistics, the Monitor Agent stores a count, total value, maximum value, minimum value and a distribution array. User-defined statistic: This is represented as an Any type statistic and tracks any value the user determines. User-defined statistics are not considered in this document. The statistics gathered by the Monitor Agent are monotonically increasing ones; commencing when the monitoring process begins. This means that when the Performance Monitor polls for the data it always receives a total since the start of monitoring, and performs a simple subtraction to find the value for the last poll period. AppCenter Performance Monitor engine The Performance Monitor itself polls for the statistics once every poll period. Each time it takes a snapshot of the current accumulations of each statistic. For Counter Statistics this is just the total value. For Distribution statistics, it retrieves The count Total value Maximum value Minimum value Distribution array The Performance Monitor then aggregates the data from multiple Monitor Agents and passes the results on to the cockpit. The Performance Monitor is integrated into the AppCenter viewer, so statistics are only collected while the viewer is running. Cockpit display The cockpit is used to display the data on the selected instruments in the AppCenter interface. By using the cockpit, you can choose from a range of instruments with which to present the information. You can also apply a number of mathematical operations/functions to the statistics that you gather. Performance statistics are obtained from the VisiBroker middleware and from the performance interface which allows you to add your own statistics. The Performance MonitorAgent in the server process is queried directly for statistics about the objects in the server. For complete information on how to present information in a cockpit, see the AppCenter User s Guide. 5-2 VisiBroker Configuration Reference

Performance Monitor browser Figure 5.1 Performance monitor architecture. Performance Monitor browser The Performance Monitor browser displays in an hierarchical view the contents of the Performance engine. Objects can be selected in this browser for inclusion in the cockpit. Enabling statistics collection Manual statistics collection Note To manually enable statistics collection for an object, you need to instantiate the Monitor Agent. To do this, add these arguments to the command-line of the VisiBroker server. For Java -DORBservices=com.visigenic.PerfMon.MonitorAgent -DPerfMonName=uniquename The file ${APPMDIR}/perf/VBMonitor.jar must be appended to the CLASSPATH. For C++ -ORBloadlib ${APPMDIR}/perf/VBMonitor -PerfMonName=uniquename where APPMDIR is an environment variable defined in the script files for the AppCenter agent. Automatic statistics collection By using the AppCenter wizard, you can create an object that will automatically feed statistics to the Monitor Agent. The VisiBroker server wizard enables you to specify whether you want automatic statistics collection to take place from either Java or C++ servers. Using the Performance Monitor 5-3

Cockpit hosted statistics For Java servers, AppCenter modifies the command-line and CLASSPATH as shown in Manual statistics collection. A Monitor Agent object will be automatically created, associated with the server and registered with the VisiBroker Location Service. For C++ objects, AppCenter modifies the command-line as in Manual statistics collection. As with Java servers, a Monitor Agent is automatically created and associated with the server. It is then registered with a VisiBroker Location Service. Figure 5.2 Statistics gathering with a wizard Cockpit hosted statistics The VisiBroker tools, of which the Performance Monitor browser is only one, can be used to copy VisiBroker objects into an AppCenter cockpit. The cockpit can be saved so that the performance of those objects can be monitored even if the Performance Monitor browser itself is not running. The browsers that can be used to add objects to a cockpit are the VisiBroker Location Service browser VisiBroker Naming Service browser VisiBroker Object Activation Demon browser Performance Monitor browser 5-4 VisiBroker Configuration Reference

Creating user-defined statistics For instructions on how to add CORBA objects to a cockpit from a VisiBroker browser, see Adding CORBA objects to a cockpit on page 3-9. Depending on the type of VisiBroker tool that you are using, you specify the Repository ID, the object name, the operation name, or any combination of these) to be monitored in the cockpit. Creating user-defined statistics There are four operations in the Monitor Agent interface to define your own statistics: add_attribute() defines a new custom attribute. all_attributes() returns a list of all currently defined attributes. delete_attribute() removes a custom attribute. object_status_update() refreshes the data for a custom attribute. Data structures for objects The following hierarchical diagram shows the data structures used in operations where users update statistics. The StatusElement structure is the lowest level in the hierarchy, and the ObjectTimeSeq sequence is the highest level of aggregation. Figure 5.3 Object data structure Using the Performance Monitor 5-5

Data structures for objects Example of retrieving the status of all objects This sample Java code shows how to retrieve the status of all defined objects using the object_status_all() operation, and then how to process the results. This process would typically occur in a custom client application that retrieves up to the minute performance statistics from the Monitor Agent. class MyClass implements Runnable { protected Thread mythread ; com.visigenic.perfmon.monitoragent.monitoragent myagent ; int updateinterval = 1000 ; // Update every updateinterval milliseconds. public MyClass() { mythread = new Thread(this) ; mythread.start() ; // Start sampling. } // Perform the actual sampling. public void run() { while (true) { try { objectdata(myagent.object_status_all(false)) ; } catch (Exception e) { e.printstacktrace(); return ; } try { mythread.sleep(updateinterval) ; } catch (InterruptedException theexception) { } } } public synchronized void objectdata(objecttimeelement [] thedata) { StatusElement datapoint ; String myinterfacename ; // Specify the data you are querying by setting String myinstancename ; // string values for these four data items. String mymethodname ; // Monitoring data are uniquely identified String myattributename ; // by this set of names. 5-6 VisiBroker Configuration Reference

Data structures for objects // Search through list of objects to find data about our object. try { for (int counter = 0 ; counter < thedata.length ; counter++) { if (myinterfacename.equals(thedata[counter].interface_name) && myinstancename.equals(thedata[counter].instance_name)) { // Correct object verified. Loop through all method and // attribute items to verify that we have what we want. for (int itemcounter = 0 ; itemcounter < thedata[counter].object_data.length ; itemcounter++) { // Discriminate on both method and attribute name. // Retain all old datapoints for historical graphs. if (mymethodname.equals( thedata[counter].object_data[itemcounter].method_name) && myattributename.equals( thedata[counter].object_data[itemcounter].status.attribute_name)) { // Access the data items as needed. // For maximum data, reference: thedata[counter].object_data[itemcounter].status.maximum // For minimum data, reference: thedata[counter].object_data[itemcounter].status.minimum // For total data, reference: thedata[counter].object_data[itemcounter].status.total // For distribution data, look at distribution entries for (int distncounter = 0 ; distncounter < thedata[counter].object_data[itemcounter].status.distribution.length ; distncounter++) { // Reference this data element... thedata[counter].object_data[itemcounter].status.distribution[distncounter]... } } } } } } } catch (Exception e) { } } Using the Performance Monitor 5-7

Data structures for attributes Data structures for attributes The hierarchical diagram in Figure 5.4 shows the data structures used in operations where users define statistics. The AttributeConfigSeq sequence is the highest level of aggregation in the hierarchy. Figure 5.4 Attribute data structure Java code examples Adding a user defined statistic This Java code example shows how to add a user-defined statistic using the add_attribute() operation. This process would typically occur on a one time, startup basis. This code example also shows how to update object status information using the object_status_update() operation. In order to demonstrate the addition of user defined statistics to an existing VisiBroker server, the bank server from the VisiBroker java_examples directory has been used. The changes that were made to the file Server.java are Adding the statement import com.visigenic.perfmon.monitor.* Changing the orb variable to the new _orb class variable. Changing the type of the variable manager from Bank.AccountManager to AccountManagerImpl Adding the call manager.initstatistics() so that it appears immediately after the statement boa.obj_is_ready(manager) 5-8 VisiBroker Configuration Reference

Adding a user defined statistic Adding the static operations getmonitoragent() and getorb() Adding the static variables _monitoragent and _orb // Server.java import com.visigenic.perfmon.monitor.*; public class Server { public static void main(string[] args) { // Initialize the ORB. _orb = org.omg.corba.orb.init(args,null); // Initialize the BOA. org.omg.corba.boa boa = _orb.boa_init(); // Create the account manager object. AccountManagerImpl manager = new AccountManagerImpl("BankManager"); // Export the newly created object. boa.obj_is_ready(manager); // Initialize User Defined Statistic Attributes manager.initstatistics(); System.out.println(manager + " is ready."); // Wait for incoming requests boa.impl_is_ready(); } static public MonitorAgent getmonitoragent( org.omg.corba.object localobj ) { if( _monitoragent == null ) { try { // This call to _nonexistent() is required for VisiBroker 3.2 boolean nonexistent = localobj._non_existent(); org.omg.corba.object obj = localobj._resolve_reference("performancemonitoragent"); _monitoragent = MonitorAgentHelper.narrow( obj ); } catch( Exception e ) { System.out.println("Monitor Agent not found:"+e); } } return _monitoragent; } static public org.omg.corba.orb getorb() { return _orb; } static private org.omg.corba.orb _orb = null; // The one and only ORB instance static private MonitorAgent _monitoragent = null; // The Performance Monitor Agent } Using the Performance Monitor 5-9

Adding a user defined statistic The changes that were made to the file AccountManagerImpl.java are Adding the statement import com.visigenic.perfmon.monitor.* Adding the constant NEW_ACCOUNT_ATTRIB Adding the operations initstatistics() and updatestatistic() Adding the call updatestatistic() to the open() operation // AccountManagerImpl.java import java.util.*; import com.visigenic.perfmon.monitor.*; public class AccountManagerImpl extends Bank._AccountManagerImplBase { static public final String NEW_ACCOUNT_ATTRIB = "New Accounts"; public AccountManagerImpl(String name) { super(name); } public void initstatistics() { try { // Get a reference to the Monitor Agent MonitorAgent monitoragent = Server.getMonitorAgent( this ); // Construct the New Attribute AttributeConfigElement attribute = new AttributeConfigElement( NEW_ACCOUNT_ATTRIB, AttributeType.distributionAttribute, new int[1] ); // Add the New Attribute monitoragent.add_attribute( attribute ); System.out.println( "New Statistic \""+NEW_ACCOUNT_ATTRIB+"\" added" ); } catch( Exception e ) { System.out.println( "New Statistic \""+NEW_ACCOUNT_ATTRIB+"\" NOT added: "+e ); } } protected void updatestatistic( String method, String attribute, int value ) { try { // Get a reference to the ORB org.omg.corba.orb orb = Server.getOrb(); // Get a reference to the Monitor Agent MonitorAgent monitoragent = Server.getMonitorAgent( this ); // Construct an attribute StatusElement StatusElement statuselement = new StatusElement( attribute, // The attribute name null, // The distribution list 0, 0, value, // Min, Max and Value for the attribute orb.create_any() ); // Get the ORB to create a dummy "Any" value // Construct an array of elements for the given method name ObjectStatusElement[] elements = new ObjectStatusElement[] { new ObjectStatusElement( method, statuselement ) }; // Construct an ObjectTimeElement for this object's repository Id and Object Name ObjectTimeElement objectstatus = new ObjectTimeElement( _repository_id(),_object_name(),elements); // Update the attribute monitoragent.object_status_update( objectstatus ); System.out.println( "Statistic \""+NEW_ACCOUNT_ATTRIB+"\" updated" ); } catch( Exception e ) { System.out.println( "Statistic \""+NEW_ACCOUNT_ATTRIB+"\" NOT updated: "+e ); } } 5-10 VisiBroker Configuration Reference

Monitor Agent interface Monitor Agent interface public synchronized Bank.Account open(string name) { System.out.println("Open account for "+name); // Lookup the account in the account dictionary. Bank.Account account = (Bank.Account) _accounts.get(name); // If there was no account in the dictionary, create one. if(account == null) { // Make up the account's balance, between 0 and 1000 dollars. float balance = Math.abs(_random.nextInt()) % 100000 / 100f; // Create the account implementation, given the balance. account = new AccountImpl(balance); // Make the object available to the ORB. _boa().obj_is_ready(account); // Print out the new account. System.out.println("Created " + name + "'s account: " + account); // Save the account in the account dictionary. _accounts.put(name, account); // Increment the New Account Attribute updatestatistic( "open", NEW_ACCOUNT_ATTRIB, 1 ); } // Return the account. return account; } private Dictionary _accounts = new Hashtable(); private Random _random = new Random(); } The Monitor Agent interface represents the Monitor Agent object that intercepts ORB calls and tabulates performance statistics. The Monitor Agent interface and its associated data structures are defined in the monitor.idl file that is stored in the ${APPMDIR}/idl. You can use the MonitorAgent interface in client applications to gain more direct access to the data that the Monitor Agent collects. You can accomplish common tasks such collecting performance data, adding user defined statistics, switching monitoring off and on and obtaining or editing the unique name of a server. For more information, see Chapter 6, Monitor Agent interface reference. Using the Performance Monitor 5-11

5-12 VisiBroker Configuration Reference

Chapter 6 Chapter6Monitor Agent interface reference This chapter describes the Monitor Agent interface, which is defined in the file ${APPMDIR}/perf that comes with the Performance Monitor package. Overview This section provides a summary of the MonitorAgent interface components. CORBA attributes The MonitorAgent interface defines the following attribute. CORBA attribute server_id Description String that uniquely identifies the server to the Monitor Agent Methods The MonitorAgent interface defines the following methods Method name add_attribute() all_attributes() delete_attribute() monitor() object_status() object_status_all() object_status_update() Description Adds a custom attribute to monitor. Returns a list of all default and custom attributes that are currently being monitored. Deletes a custom attribute. Switches monitoring on or off. Returns the status of a single object. Returns the status of all objects. Updates the status of an object. Monitor Agent interface reference 6-1

Exceptions Method name server_status() server_status_update() Description Internal use only. Returns the status of a server. Internal use only. Updates the status of a server. Exceptions The MonitorAgent interface contains the following exceptions Exception AttributeNotFound BufferSizeFull ObjectNotFound Description Specified attribute is invalid. Buffer is full. Specified object is invalid. Data types The monitor.idl file defines the following data types Declared data type AllObjectsStatusSeq Attribute AttributeConfigSeq DistributionList ObjectStatusSeq ObjectTimeSeq StatusSeq Enumerated data type AttributeType Description List of ObjectStatusSeq sequences containing monitor statistics for all methods within an individual object. Server attribute or property that the Monitor Agent can monitor. List of AttributeConfigElements containing attribute information and monitor statistics. List of monitor statistics for attributes of type distributionattribute. List of ObjectStatusElements containing monitoring statistics for individual methods within an object. List of ObjectTimeElements containing monitoring statistics for individual objects. Internal use only. Description Describes the type of data that the Monitor Agent collects for an attribute. Structure AttributeConfigElement ObjectStatusElement ObjectTimeElement StatusElement Description Represents the properties of an attribute: its name, type, and (for attributes of type distributionattribute) its distribution bounds. Represents a operation, and its monitor statistics, within an object. Represents an object and its monitor statistics. Represents the current monitor statistics for an attribute. 6-2 VisiBroker Configuration Reference

Reference Reference This section provides a detailed description of the MonitorAgent interface components, presented in alphabetical order. add_attribute void add_attribute( in AttributeConfigElement thenewattribute) raises (BufferSizeFull) ; Parameter thenewattribute Description Attribute to add. An AttributeConfigElement containing the name of the new attribute, its type (counter or distribution attribute), and, if it is a distribution attribute, its distribution bounds. Do not specify the names of the default attributes. Note Adds a new custom attribute to monitor. The Monitor Agent begins collecting statistics as soon as the custom attribute is added. If the buffer size is exceeded, add_attribute() raises a BufferSizeFull() exception. If the new attribute is of type distributionattribute, you can specify as many distribution bounds as needed for the histogram collection buckets. Client code must subsequently increment the data using the object_status_update() operation. Do not specify the names of the default attributes: latency marshalinsize marshaloutsize totalcalls totalreplies requestfailed replyfailed The following sample Java code creates a new attribute, called CommittedTransactions, which is of type counterattribute. // Create and define the AttributeConfigElement AttributeConfigElement theattribute = new AttributeConfigElement( "CommittedTransactions", // Attribute name // Don t specify names of default attributes AttributeType.counterAttribute, // Attribute type new int[1]) ; // You must pass dummy distribution list try { add_attribute(theattribute) ; // Add the new custom attribute } catch (Exception e) { // Could result in buffersizefull() } Monitor Agent interface reference 6-3

all_attributes The following sample Java code creates a new attribute, called TransactionTime, which is of type distributionattribute, for collecting histogram statistics: // Create and define the AttributeConfigElement theattribute = new AttributeConfigElement( "TransactionTime", // Attribute name AttributeType.distributionAttribute,// Attribute type new int[4]) ; // Distribution bounds for histogram. theattribute.distribution_bounds[0] = 150 ; // range: up to 150 theattribute.distribution_bounds[1] = 300 ; // range: 151-300 theattribute.distribution_bounds[2] = 500 ; // range: 301-500 theattribute.distribution_bounds[3] = 1000 ; // range: 501-1000 // range 1001+ implied try { add_attribute(theattribute) ; // Add the new custom attribute } catch (Exception e) { // Could result in buffersizefull() } all_attributes AttributeConfigSeq all_attributes ; Returns a list of all default and custom attributes that are currently being monitored. The returned AttributeConfigSeq sequence contains one or more ObjectStatusElements, each of which represents the properties of an attribute: its name, type, and distribution bounds. The default attributes have the following names: latency, marshalinsize, marshaloutsize, totalcalls, totalreplies, requestfailed, and replyfailed. AllObjectsStatusSeq typedef sequence <ObjectStatusSeq> AllObjectsStatusSeq ; A list of ObjectStatusElement sequences containing monitor statistics for all methods within an individual object. Attribute typedef string Attribute ; Represents a server attribute or property that the Performance Monitor can monitor. Used in the ObjectStatusElement and StatusElement structures. 6-4 VisiBroker Configuration Reference

AttributeConfigElement AttributeConfigElement struct AttributeConfigElement { Attribute attribute_name ; AttributeType attribute_type ; DistributionList distribution_bounds ; } ; Member attribute_name attribute_type distribution_bounds Description Name of the attribute. Type of attribute. One of the following attribute types: counterattribute, distributionattribute, or anyattribute. If the attribute is a distribution attribute, the elements of distribution_bounds define the upper limit of each distribution sampling bucket. See also DistributionList on page 6-2. Structure that represents the properties of an attribute: its name, type, and (for attributes of type distributionattribute) its distribution bounds. Used as an argument to add_attribute() option. AttributeConfigSeq typedef sequence<attributeconfigelement> AttributeConfigSeq ; List of ObjectStatusElements containing attribute information and monitor statistics. Returned by the all_attributes() operation. AttributeNotFound exception AttributeNotFound { } ; The attribute name specified in the delete_attribute() operation is invalid (undefined). Monitor Agent interface reference 6-5

AttributeType AttributeType enum AttributeType { counterattribute, distributionattribute, anyattribute } Identifier counterattribute distributionattribute anyattribute Description The attribute is a single, unsigned long value. All incoming data are added to the counter. The attribute is an array of unsigned long values. Each element in the array represents a different bucket to collect data. Internal use only. The attribute is a single value of type any. The MonitorBuffer performs no computations and simply passes this data through. Enumerated type that describes the type of data that the Monitor Agent collects for an attribute. For attributes of type counterattribute, the Monitor Agent increases a single value by the amount received in incoming data. A counterattribute represents an attribute that has a single bucket for accumulating data. For attributes of type distributionattribute, the Monitor Agent increases one of multiple values (or counters) in an array by the amount received in incoming data. A distributionattribute represents an attribute that has multiple buckets for accumulating data. The Monitor Agent determines which array element to increase based on the corresponding range value specified in the associated DistributionList sequence. Distribution attributes are used to generate histograms in the Monitor Client. The Monitor Agent collects and tracks the data for every object and every operation invocation internally. The AttributeConfigElement structure contains the DistributionList field, which is of type AttributeType. BufferSizeFull exception BufferSizeFull { } ; The buffer is full. Insufficient buffer space exists for the add_attribute() operation to add more attributes to monitor. 6-6 VisiBroker Configuration Reference

delete_attribute() delete_attribute() void delete_attribute( in string attributename) raises (AttributeNotFound) ; Parameter attributename Description Name of the attribute to delete. Do not specify the names of the default attributes. Note Deletes the specified attribute. After client code calls delete_attribute(), the Monitor Agent stops collecting data for the deleted attribute and dumps all data collected so far. If the specified attributename is invalid, delete_attribute raises the AttributeNotFound exception. Do not specify the names of the default attributes: latency, marshalinsize, marshaloutsize, totalcalls, totalreplies, requestfailed, or replyfailed. DistributionList Note typedef sequence<unsigned long> DistributionList ; Distribution list containing monitoring statistics for attributes of type distributionattribute. Used as a field in the AttributeConfigElement and StatusElement structures. When used in an AttributeConfigElement, a DistributionList is a set of numbers that defines the configuration of a histogram of values. Each value defines the upper bound of a range. There is one additional range that includes values greater than the last upper bound. Values must be in increasing numerical order. When used in a StatusElement structure, a DistributionList provides data values for each range in a histogram of values. When used, the DistributionList in a StatusElement will contain one more value than the DistributionList for the corresponding AttributeConfigElement. monitor boolean monitor(in boolean turnon) ; Parameter turnon Description TRUE turns monitoring on, and FALSE turns monitoring off. Switches monitoring on or off. Monitoring is automatically enabled when an implementation of this interface is instantiated. You can switch monitoring off if you want to stop monitoring temporarily, such as to eliminate the minor overhead associated with collecting statistics. Monitor Agent interface reference 6-7

object_status() When monitoring is suspended, the Monitor Agent stops collecting statistics but retains the accumulated statistics in memory. When monitoring is activated again, the Monitor Agent resumes updating those statistics. The monitor() operation returns a boolean TRUE if the operation succeeds, or FALSE if a failure occurs. object_status() ObjectTimeSeq object_status( in string interface_name, in string instance_name) raises (ObjectNotFound) ; Parameter interface_name instance_name Description Name of the object s interface, as defined in the IDl file. Name of the object instance, which must match an object that has been explicitly named in application code. only named (PERSISTENT) objects may be monitored with this operation. Returns the status of the specified object. The returned ObjectTimeSeq contains one ObjectTimeElement describing the interface name, instance name, and collected data (an ObjectStatusElement) for the specified object. If the specified object is invalid (for example, the object is not active), object_status() raises an ObjectNotFound() exception. Alternatively, use object_status_all() instead to obtain the status of all active objects. object_status_all() ObjectTimeSeq object_status_all(in boolean purge_data) ; Parameter purge_data Description If TRUE, after the object status has been obtained, clears the Monitor Agent data buffers of statistics. If FALSE, does not clear the data buffers. Returns the status of all object instances that are visible to the Monitor Agent. The returned ObjectTimeSeq contains one or more ObjectTimeElements describing the interface name, instance name, and monitor data (an ObjectStatusElement) for each object. Alternatively, use object_status() instead to obtain the status of a single object when the object s interface name and instance name is known. 6-8 VisiBroker Configuration Reference

object_status_update object_status_update boolean object_status_update(in ObjectTimeElement newstatus) ; Parameter newstatus Description Status information to update. An ObjectTimeElement describing the object s interface name, instance name, and the status information to update. In each of the contained StatusElement, only the Total field is used. Updates the status of the specified object with the specified data. For attributes of type counterattribute, the given value is used to update the cumulative total, minimum, and maximum values. For attributes of type distributionattribute, the given value is used to update the cumulative total, minimum, and maximum values, and to increment the appropriate counter in the DistributionList. ObjectNotFound exception ObjectNotFound { } ; The requested object in the object_status() operation is invalid (unknown). ObjectStatusElement struct ObjectStatusElement { string method_name ; StatusElement status ; } ; Member method_name status Description Name of the operation being called. Status data collected by the Monitor Agent. A StatusElement containing the attribute name, distribution list, minimum and maximum values, and accumulated total. ObjectStatusSeq typedef sequence <ObjectStatusElement> ObjectStatusSeq ; List of ObjectStatusElements containing monitoring statistics for individual methods within an object. Used as a member of the ObjectTimeElement structure and in the AllObjectsStatusSeq. Monitor Agent interface reference 6-9

ObjectTimeElement ObjectTimeElement struct ObjectTimeElement { string interface_name ; string instance_name ; ObjectStatusSeq object_data ; }; Member interface_name instance_name object_data Description Name of the object s interface as defined in the IDL file. Name of the object instance, which must match an object that has been explicitly named in application code. Unnamed objects identified by reference, although permitted in CORBA, are not permitted here because they are not known to the OSAgent or Object Activation Daemon (OAD) and therefore are not visible to outside clients. Monitor statistics data for the object. An ObjectStatusSeq. Structure that represents an object and its monitor statistics. Returned by the object_status_update() operation and in the ObjectTimeSeq. ObjectTimeSeq typedef sequence <ObjectTimeElement> ObjectTimeSeq ; List of ObjectTimeElements containing monitoring statistics for individual objects. Returned by the object_status() and object_status_all() methods. server_id() attribute string server_id(in String servername) ; Member servername Description An arbitrary String value that uniquely defines the server name. CORBA attribute that uniquely identifies the server to the Monitor Agent. Each server should define its own server_id. If the server doesn t define a name, you should assign it one. Consider using a descriptive name in 6-10 VisiBroker Configuration Reference

StatusElement accordance with your organization s server naming conventions. The assigned name should be unique among all servers to monitor. // Specify the server ID in a Server application // Instantiate the agent. com.visigenic.perfmon.monitoragent.monitoragent theagent = new com.visigenic.perfmon.monitoragent.monitoragent("agent") ;... java.lang.string servername ; // Set the server name value. servername = Book Server theagent.server_id(servername) ; // That does the work. StatusElement struct StatusElement { Attribute attribute_name ; DistributionList distribution ; unsigned long maximum ; unsigned long minimum ; unsigned long total ; any additional_value ; }; Member attribute_name distribution maximum minimum total additional_value Description Name of the attribute being monitored. Distribution List containing a distribution of values that the Monitor Agent has collected. Simple counters have distribution member fields with one element. Contains data when the attribute s AttributeType is a distributionattribute. Maximum value that the Monitor Agent has collected for this attribute. Minimum value that the Monitor Agent has collected for this attribute. Accumulated total of all values that the Monitor Agent has collected for this attribute. Contains data when the AttributeType is a counterattribute. Internal use only. Structure that represents the current monitor statistics for an object attribute. The ObjectStatusElement structure. Monitor Agent interface reference 6-11

6-12 VisiBroker Configuration Reference

Chapter 7 Chapter7VisiBroker CORBA driver properties The architecture of AppCenter s VisiBroker CORBA drivers is very similar to that of the generic and vanilla drivers. However, managing VisiBroker objects requires some different considerations when issuing commands (Start, Stop, Ping and Get Statistics) than you encounter with simple objects. This chapter explains some of the factors that you have to consider when managing VisiBroker objects and provides a list of key properties and a summary of how you use them. About the CORBA Driver AppCenter s VisiBroker CORBA drivers (called vobject and vserver) conform closely to the driver architecture for the generic drivers. When we refer to a driver, we are usually referring, in fact, to a driver module. A driver module is a components which is invoked by the driver and which actually executes the specified task. The driver is an executable that is started by an agent when a management operation (such as start, stop, ping) is performed. The driver dynamically loads the driver modules that carry out the management task. The modules are generally provided as either DLLs (on Windows platforms) or as shared libraries (on UNIX platforms). The driver modules are dynamically loaded by the driver when it needs to use one of them to carry out a specific management task. The modules may, as well as executing the task, pass name/value properties back to the driver and thence to the agent. The VisiBroker driver is designed to let you manage VisiBroker 3.2 and 3.3 objects. If you want to manage any other flavors of CORBA middleware, this VisiBroker CORBA driver properties 7-1

Process cycle can be done with the Generic driver. This enables you to implement scripts that provide AppCenter with the information that it needs to manage an object. What this would not provide you is the CORBA specific functionality which depends upon the operations of VisiBroker (interceptors and so on). It is theoretically possible to manage any implementation of CORBA with a VisiBroker driver. While the Location Service wouldn t work, the Naming Service should operate effectively. Note that this has not yet been tested. Process cycle Like the AppCenter generic driver, the VisiBroker CORBA driver performs each management task in three phases, the Pre phase, the Main phase, and the Post phase. Pre phase Main phase Post phase Enables a module to perform any initialization that is required before the main phase is called. Performs the actual task that the module was invoked to execute. Cleans up the server s environment and eliminates any superfluous entities. These phases are reflected in the properties that are associated with a CORBA object, PRE_PHASE, MAIN_PHASE, and POST_PHASE. These allow the module to carry out initialization, management tasks, and cleanup processes as specified in these properties. Driver function When you are implementing a VisiBroker object, the first consideration that you face is whether you want the object to be controlled by AppCenter or by the Object Activation Daemon (OAD). If it is controlled by AppCenter, then it is AppCenter that starts the object and ensures that it remains resident in the system process table. If you elect to have the object controlled by the OAD, AppCenter is not responsible for starting it, the OAD is. An executable may only start, for example, the first time that a client makes an invocation to it. Objects controlled by the OAD are sometimes referred to as on-demand objects because they are only started when they are needed. 7-2 VisiBroker Configuration Reference

Starting Starting VisiBroker object Properties used AM_OBJECT_TYPE AM_OBJECT_NAME AM_OBJECT_HOST AM_IOR AM_CONTAINED AM_PARENT_CONTAINER Operation The main objective of the start command inside AppCenter is to obtain the current IOR for that object. If the AM_IOR is specified, no lookup is done and the Start command returns a success. If the AM_IOR isn t specified, then AM_OBJECT_TYPE, AM_OBJECT_NAME and AM_OBJECT_HOST are used to obtain the current IOR. This is done by checking in the location service. OAD activated VisiBroker object Properties used AM_OAD_PATH AM_OAD_ARGS AM_OAD_ENV AM_OAD_REFERENCE_DATA AM_OAD_HOST AM_ACTIVATION_POLICY AM_OAD_REGISTER AM_OBJECT_ACTIVATE Operation If AM_OAD_REGISTER is set, then using AM_OAD_PATH, AM_OAD_ARGS, AM_OAD_ENV, AM_OAD_REFERENCE_DATA and AM_OAD_HOST the object is registered with the OAD. Duplicate entries are not allowed and they will cause the object to be marked in AppCenter as being down. If AM_OBJECT_ACTIVATE is set, an attempt to invoke the _non_existent operation on the object will be made. This may result in the executable that contains the object being started. VisiBroker CORBA driver properties 7-3

VisiBroker server Pinging VisiBroker server Properties used AM_S_EXECUTABLE AM_S_ARGS AM_S_TYPE AM_S_NAME AM_S_IOR AM_S_USE_MO AM_S_IS_JAVA AM_S_MO_FILE AM_S_USE_PERF AMSS_PERF_NAME AM_S_PERF_FILE AM_S_MI_SHUTDOWN Operation The purpose in starting a server is to build a command line that will be executed by the Vanilla driver. They type of command line that is built depends on whether the server is a C++ or a Java server and upon if the AM_S_USE_PERF property is turned on or not. For example, for a Java server where AM_S_USE_PERF is turned on and the other default values used, a command-line is constructed which would read Java -DORBServices=ORBManager -DORBSecureShutdown=false - DORBServices=com.visigenic.Perf.Mon.MonitorAgent - DPerfMonName=perf_bank_example_L:9078183292 Server This is then passed to the Vanilla driver for execution. OAD activated VisiBroker server Any OAD start for a server will return the value of True because the OAD server is actually a container for OAD registered objects. An OAD server is created for the sole purpose of enabling OAD activated objects to be created in AppCenter so that they can be modeled as being contained by the OAD server. VisiBroker object Properties used AM_OBJECT_TYPE AM_OBJECT_NAME AM_OBJECT_HOST AM_IOR 7-4 VisiBroker Configuration Reference

VisiBroker object AM_PARENT_CONTAINER AM_CHECK_LS AM_CHECK_NS AM_CHECK_TS AM_CHECK_OBJECT AM_CHECK_OBJECT_MO AM_OBJECT_OAD AM_PING_RETRIES AM_PING_SLEEP AM_PING_POLICY AM_PING_REBIND_ON_FAILURE AM_NAME_ID AM_NAME_KIND AM_ROOT AM_IS_JAVA AM_CONTAINED Operations There are four options for checking the existence of an object; namely by checking the Naming Service, Location Service, the Managed Object Interface, and by invoking the object directly. What combination of these four properties you use defines the ping for a particular object. Depending upon which of these properties are set, the services identified by the properties will be searched to see if the object is present. A single failure on any selected service will result in the object being marked as down. 1 The means of determining whether a ping is successful or not is defined. This entails what combination of calls to a naming service, location service, trading service and invocation of the managed object is used. 2 A lookup is performed on each of the nominated services. If the service object is located on the service, a return value is added to the cumulative total for the object. If the object is not located, the ping will fail. 3 If it has been nominated to ping the object itself, the _non_existent operation is called on the object. 1 If a direct bind is made to the managed object, an invocation to the current IOR using the _non_existent() operation is made. If this succeeds, a value is returned. 2 If it fails, AM_PING_REBIND_ON_FAILURE is used to connect to a replica of the object. If this cannot be done, the ping will fail. 4 If it has been nominated to ping the object via the Managed Object Interface, an invocation is made to the ping operation on the interface which should return 1 for success. 5 Once all of the ping procedures have been executed and the number of calls equals the cumulative total, the ping will be successful. If not, the ping will fail and the object will be marked as being down. VisiBroker CORBA driver properties 7-5

OAD activated VisiBroker object Comments Special note is made of cases where a direct bind to the object is initiated. Using the current IOR, an invocation is made of a well-known operation (_non_existent). If this fails and the AM_REBIND_ON_FAILURE property is set, an attempt is made via VisiBroker s built-in fault tolerance mechanism to rebind to an object with the same interface and object name. If this succeeds, the current IOR is updated and the ping returns a value of 1 (a success). OAD activated VisiBroker object Properties used AM_OAD_PATH AM_OAD_ARGS AM_OAD_ENV AM_OAD_REFERENCE_DATA AM_OAD_HOST AM_ACTIVATION_POLICY AM_OAD_REGISTER AM_OBJECT_ACTIVATE Operation You have the same options for pinging an object that is controlled by the OAD as you do for an object controlled by AppCenter (see VisiBroker object on page 7-4). In addition, the ping operation can confirm that the object is still registered with the OAD. If the object was due to be activated, it will confirm that the OAD has started the executable containing the object. 1 Check in OAD to verify that the object is registered there. If not, the ping fails and the object is marked as being down. 2 Check with the OAD that the server has started. This is only done if the object was due to be activated. 3 Once the ping procedures have been executed and the number of calls equals the cumulative total, the ping will be successful. If not, the ping will fail and the object will be marked as being down. VisiBroker server Operation You have the same options for pinging an object that is controlled by the OAD as you do for an object controlled by AppCenter (see VisiBroker object on page 7-4). In all instances, a ping returns a value of TRUE and lets the Vanilla driver check the process ID of the server. 7-6 VisiBroker Configuration Reference

OAD activated VisiBroker server OAD activated VisiBroker server Operation The OAD Ping for a server will automatically return a TRUE value as the server is a container for OAD registered objects, providing that it is still registered with the OAD. For more information, see OAD activated VisiBroker server on page 7-4. Stopping VisiBroker object Properties used AM_IOR AM_NAME_ID AM_NAME_KIND AM_NAME_ROOT AM_INITIATED_SHUTDOWN AM_FORCED_STOP AM_STOP_VIA_MO AM_CLEANUP_LS AM-CLEANUP-NS AM_CLEANUP_TS Operation You have the same options for pinging an object that is controlled by the OAD as you do for an object controlled by AppCenter (see VisiBroker object on page 7-4). If STOP_VIA_MO is not specified, all that will be attempted is to clear up entries in the respective services specified with the cleanup properties were set. An object may be stopped using the AppCenter Managed Object Interface. This mechanism will result in an invocation to the object to prepare to shut down. Subsequently, the object will be asked if it can be shut down and if so, the shutdown operation will be called. After a specific time, if the object still says that it can t shut down, a forceful shutdown will be initiated and the object is marked as down (that is, unmanaged). 1 Determine if a stop via the managed object is required. If not, the stop operation proceeds directly to the cleanup of services. 2 Determine if a forceful shutdown is required. If so, the shutdown is called immediately. If not, a graceful shutdown is requested. 3 Prepare shutdown is called on the object using managed object interface. VisiBroker CORBA driver properties 7-7

Comment 4 The object is asked if it can shutdown. 1 If the object is unable to shutdown, its state is marked as Stopping until either a forceful shutdown is employed or it confirms that it can shutdown. 2 If the object is able to shutdown, shutdown is called immediately. 5 A cleanup of the services will be initiated. 6 When the cleanup is completed, the Stopped status will be returned. Comment The IDL for the Managed Object Interface is described in Chapter 9, CORBAmanaged object interface. OAD activated VisiBroker object Properties used AM_OAD_PATH AM_OAD_ARGS AM_OAD_ENV AM_OAD_REFERENCE_DATA AM_OAD_HOST AM_ACTIVATION_POLICY AM_OAD_REGISTER AM_OBJECT_ACTIVATE Operation If AM_OAD_REGISTER is set, the object will be unregistered from the OAD. If the OAD has been started with the -k option, it is possible that the executable containing this object will be stopped. The usual clean up operations when stopping an object will be attempted after the unregister has been completed. 1 A check is made that the AM_OAD_REGISTER is set. If not, a cleanup is done and a status of Stopped will be returned. 1 If the AM_OAD_REGISTER is set, the object is unregistered from the OAD. 2 If the object was started with the -k option, the executable containing it may stop also. 2 If the object is able to shutdown, it will start the cleanup of services. 3 The cleanup is done on all services that the object uses. 4 When the cleanup is completed, the Stopped status will be returned. 7-8 VisiBroker Configuration Reference

VisiBroker server VisiBroker server CORBA Properties Properties used AM_S_EXECUTABLE AM_S_ARGS AM_S_TYPE AM_S_NAME AM_S_IOR AM-S_USE_MO AM_S_IS_JAVA AM_S_MO_FILE AM_S_USE_PERF AM_S_PERF_NAME AM_S_PERF_FILE AM_MI_SHUTDOWN AM_CONTAINER_ID Operation If the property AM_S_MI_SHUTDOWN is set, then an invocation to the ORB Management Interface is made on the shutdown operation. 1 Determine if a stop via the managed object is required. 1 If not, the stop operation proceeds directly to the cleanup of services. 2 If yes, an invocation to the shutdown operation on the VisiBroker ORB Management Interface object is made which stops the server gracefully. 2 A cleanup of services is initiated. 3 When the cleanup is completed, the Stopped status will be returned. OAD activated VisiBroker server The OAD Stop for a server will automatically return a TRUE value as the server is a container for OAD registered objects. For more information, see OAD activated VisiBroker server on page 7-4. The remainder of this chapter contains a list of the properties used in AppCenter that relate to VisiBroker. For the sake of brevity, properties are listed only once, though they may appear in numerous templates. VisiBroker CORBA driver properties 7-9

Standard Standard Table 7.1 CorbaObject Key Tab Description AM_IOR Identification Specifies the Inter-operable Object Reference. AM_NAMING_NAME AM_TRADING_NAME AM_NAME_ROOT AM_NAME_ID AM_NAME_KIND Fault Tolerance Fault Tolerance Fault Tolerance Fault Tolerance Fault Tolerance Specifies the name of the object in the Naming Service. Specifies the name of the object within the Trading Service. Specifies the Name service's root context name. Specifies the Id component on the name service entry. Specifies the kind component on the object's name service entry. AM_PARENT_CONTAINER Identification The unique ID of the container that contains this object. For CORBA objects this will be the PID of the containing server process. AM_CHECK_NS AM_CHECK_TS AM_CHECK_OBJECT AM_CHECK_OBJECT_MO Fault Tolerance Fault Tolerance Fault Tolerance Fault Tolerance Check the Naming Service as part of ping. Check the Trading Service as part of ping. Call _non_existent operation on object. Call operations on MO interface to verify ping. AM_STOP_VIA_MO Deactivation Call operations on MO interface to perform a graceful stop. AM_CLEANUP_NS Deactivation Does the driver clean up the Naming Service? AM_CLEANUP_TS Deactivation Does the driver clean up the Trading Service? AM_CURRENT_IOR Identification When an Object is started this value represents the current IOR for that object. Table 7.2 CorbaContainer Key Tab Description AM_CONTAINER_ID Identification The unique string that identifies this container. For Corba servers this is the PID. Table 7.3 OnDemandObject Key Tab Description No unique properties. 7-10 VisiBroker Configuration Reference

VisiBroker Table 7.4 VisiBroker CorbaServer Key Tab Description AM_PING_PID Fault Tolerance Specifies whether to do a ping based on the process id. AM_CMDLINE_IGNORE Drivers Ignore any further properties with a Base Class of cmdline. The default is false. AM_CMDLINE_VALUE_ ONLY Drivers Specifies whether to ignore the name part of command line arguments. AM_VSERVER_DRIVER Drivers VSERVER driver will be invoked. Table 7.5 VB_BaseObject Key Tab Description AM_OBJECT_NAME Identification Specifies the objects name. AM_VISI_CORBA_DRIVER Drivers The VisiBroker CORBA driver. AM_SSL_SECURITY Security Specifies whether to use the SSL security features of VisiBroker. AM_AGENT_SEARCH_SCOPE Identification Specifies whether to search network for location service agents or use the local one. 0 Use local 1 Collect all network agents. AM_AGENT_IP Activation Specifies the IP address of the agent that this object is registered with. AM_AGENT_PORT Activation Specifies the port of the agent that this object is registered with. AM_OBJECT_TYPE Identification Specifies the object type. AM_OBJECT_HOST Identification Specifies the host where this object resides. AM_CHECK_LS Fault Tolerance Check the Location Service as part of ping. AM_PING_REBIND_ON_FAILURE Fault Tolerance Employ VisiBroker s inbuilt fault tolerance to find object on failure. AM_CLEANUP_LS Deactivation 0 No clean up 1 Clean up exactly that IOR 2 Clean up all objects with same type and name 3 Clean up all objects with the same type. Table 7.6 VB_Object Key Tab Description No unique properties. VisiBroker CORBA driver properties 7-11

VisiBroker Table 7.7 OAD_Object Key Tab Description AM_OBJECT_ACTIVATE Activation Specifies whether to start object after it has been registered with the OAD. AM_OAD_REGISTER AM_OAD_TYPE AM_CHECK_OAD Activation, OAD Properties Activation, OAD Properties Fault Tolerance Specifies whether to register with the Object Activation Daemon. 0 means do not register. Specifies the type of the OAD, that is whether it is the C++ or Java implementation. 1 indicates that the OAD will be checked for the existence of this object during a PING. AM_CLEANUP_OAD Deactivation Remove OAD entry as part of stop? AM_ACTIVATION_POLICY Activation, OAD Properties Select shared server/unshared server for operation. AM_OAD_ARGS Activation, OAD Properties Command line arguments for executable. AM_OAD_ENV Activation Environment settings when starting executable. AM_OAD_REFERENCE_DATA AM_OAD_PATH Activation, OAD Properties Activation, OAD Properties Reference data that is passed to the executable object. Path name of executable. AM_OAD_HOST Activation Specifies the host to run on. AM_REGISTRATION_SLEEP Activation Amount of time (seconds) to sleep after registration with the OAD before checking it succeed. Table 7.8 VB_Server Key Tab Description AM_S_TYPE Identification Repository ID of the managed object associated with this server. AM_S_NAME Identification Object instance name of the managed object associated with this server. AM_S_IOR Identification Specific IOR of the management object associated with this server. AM_S_USE_MO Identification Is there a management object associated with this server. 0 No 1 Specify one yourself 2 Automatically generate one. 7-12 VisiBroker Configuration Reference

VisiBroker Table 7.8 AM_S_USE_PERF Performance Do you want this server to be automatically instrumented so that it can have statistics gathered from it? AM_S_MO_PING Fault Tolerance Do you want to ping this server by sending a request to the Managed Object that is associated with it? AM_S_MO_SHUTDOWN Deactivation Do you want to shutdown this server by sending a request to the Managed Object that is associated with it? AM_S_MI_SHUTDOWN Deactivation Do you want to shutdown this server by calling the VisiBroker standard management shutdown interface associated with it? AM_S_IS_JAVA Identification Is this server a Java based server? AM_S_PERF_NAME Performance Unique performance monitor name. AM_S_PERF_FILE Performance Name of file containing performance object. AM_S_MO_FILE Identification Name of file containing managed object. AM_S_MI_PING Fault Tolerance 0 No 1 Ping using Perf Object 2 Ping using Management Object AM_S_EXECUTABLE Activation Full executable path name. AM_S_ARGS Activation Command-line arguments when starting executable. AM_S_VBM_JARFILE Activation This property is only used by the VisiBroker Server Wizard. Table 7.9 VB_Server (continued) Key Tab Description OAD_Server Key Tab Description AM_S_ACTIVATION_POLICY Activation OAD Activation Policy for the server 0 Shared Server 1 Unshared Server 2 Server per operation AM_S_OAD_ENV Activation Environment settings when starting executable. AM_S_OAD_REFERENCE_DATA Activation Reference data that is passed to the executable object. VisiBroker CORBA driver properties 7-13

Command options Command options Table 7.10 ORB options Key Tab Description ORBagentAddr ORB_Init Specifies the hostname or IP address of the host running the Smart Agent the client should use. ORBagentPort ORB_Init Specifies the port number of the Smart Agent. ORBbackCompat ORB_Init If set to 1, this option specifies that backward compatibility with VisiBroker 2.0 should be provided. The default is 0. ORBbackdii ORB_Init If set to 1, this option specifies that support for the 1.0 IDL-to-C++ mapping should be provided. If set to 0 or not specified at all the new 1.1 mapping will be used. ORBconnectionMax ORB_Init Specifies the maximum number of outgoing connections that are allowed. The default is an unlimited number. ORBconnectionMaxIdle ORB_Init This specifies the number of seconds that an outgoing connection can idle before it is shutdown by VisiBroker. The default is 0 (never timeout). ORBir_name ORB_Init Specifies the name of the interface Repository to be accessed when the Object:get_interface() operation is invoked on object implementations. ORBir_ior ORB_Init Specifies the IOR of the Interface Repository to be accessed when the Object:get_interface() operation is invoked on object implementations. ORBnullString ORB_Init A value of 1 specifies the ORB will allow C++ NULL strings to be streamed. The NULL strings will be marshalled as strings of length 0 otherwise the streaming of a NULL string is an exception. ORBrcvbufsize ORB_Init Specifies the size of the TCP buffer (bytes) used to receive responses. ORBsecuresetattr ORB_Init If set to 0, a client can use the ORB management interface to set the server's attributes. By default this value is set to 1 and a CORBA:NO_PERMISSION exception is thrown if a user attempts to set a server's attribute with the ORB management interface. ORBsecureShutdown ORB_Init If set to 0 a user can use the shutdown command from the ORB management interface to shutdown the server. The default value is 1. 7-14 VisiBroker Configuration Reference

Command options Table 7.10 ORBsendBind ORB_Init If set to 1, this option provides backward compatibility between the bind call and VisiBroker for C++ 2.x. If you do not specify the default value is 0. ORBsendbufsize ORB_Init Specifies the size of the TCP buffer (bytes) used to send client requests. ORBshmsize ORB_Init Specifies the size of the send and receive segments (bytes) in shared memory. Only supported on WIndows platforms. ORBtcpNodelay ORB_Init When set to 1, it sets all sockets to immediately send requests. The default value is 0. Table 7.11 ORB options (continued) Key Tab Description BOA options Key Tab Description OAconnectionMax. BOA_init Specifies the maximum number of connections allowed when -OAid TSession is selected. OAconnectionMaxIdle BOA_init Specifies the time (secs) which a connection can idle without any traffic. Connections that idle beyond this time can be shutdown by VisiBroker. A default of 0 means that connections will never timeout. OAagent BOA_init If set to 0, this option specifies that new instances of objects being registered will not be exposed through the Smart Agent. OAgarbageCollectTimer BOA_init Specifies the time (secs) that the adapter waits before checking for idle connections and threads to be cleaned up. OAid BOA_init Specifies the thread policy for multithreaded servers to be used by the OA. OAipAddr BOA_init Specifies the hostname or IP address to be used for the OA. Use this option if the machine has multiple network interfaces and the OA is associated with just one address. OAlocalIPC BOA_init When a client and an object implementation reside on the same host and this is set to 1, a local inter-process communication operation will be used instead of a socket connection. OAport BOA_init Specifies the port number to be used by the OA when listening for new connections. OArcvbufsize BOA_init Specifies the size of the buffer (bytes) used to receive messages. OAsendbufsize BOA_init Specifies the size of the buffer (byes) used to send messages. VisiBroker CORBA driver properties 7-15

Infrastructure Table 7.11 BOA options (continued) Key Tab Description OAshmsize BOA_init Specifies the size of the send and receive segments(bytes) in shared memory. (Only for WIndows). OAtcpNoDelay BOA_init When set to 1, it sets all sockets to immediately send requests. The default value of 0 allows sockets too send requests in batches as buffers fill. OAthreadMax BOA_init Specifies the maximum number of threads allowed when -OAid TPool is selected. OAthreadMaxIdle BOA_init Specifies the time (secs) which a thread can exist without servicing any requests. Threads that idle beyond that time can be returned to the system. OAthreadStackSize BOA_init Specifies the maximum thread stack size (bytes) allowed when -OAid TPool or -OAid TSession is selected. Infrastructure Table 7.12 Name service Key Tab Description NAMING_SERVICE_LOGFILE _NAME NAMIMG_DEBUG_FLAG NAMING_FACTORY_NAME Table 7.13 Location Service Command Line Options Command Line Options Command Line Options Key Tab Description Specifies the full path to the logfile to be passed on the command line to the Naming Service. Either blank or -debug. Specifies the Factory Name passed to the Naming Service. LOCdebug Location If set to 1, enables using the Location Service with debugging turned on. LOCtimeout Location Indicates the number of seconds to wait for a response from a server when verifying the existence of an object. This option is only used when -LOCverify has been set to one. The default is one second. 7-16 VisiBroker Configuration Reference

Infrastructure Table 7.13 LOCverify Location If set to 1, the Location Service will verify the existence of an object before returning an object reference to the client application. If set to 0, the Location Service will offer faster performance, but it may not return the most current information. the default is 0. AM_CMDLINE_PAIR_ SEPARATOR Table 7.14 VB_Configuration Drivers Key Tab Description Specifies the string that separates command line pairs. Normally a space. In the example below the _ character would be the AM_CMDLINE_PAIR_SEPARATOR value. CONFIG_OSAGENT_HOST Identification Setting this field allows you to change the value of the OSAgent Host for every object in the configuration. CONFIG_OSAGENT_PORT Identification Setting this value will set the OSAgent port field for every object in the configuration. Table 7.15 VB_BaseServer Key Tab Description No unique properties Location Service (continued) Key Tab Description VisiBroker CORBA driver properties 7-17

7-18 VisiBroker Configuration Reference

Chapter 8 Chapter8CORBA API for AppCenter AppCenter provides a server appcorba.exe in the AppCenter/DevKit/Corba directory that you can use as a bridge between the world of CORBA/IDL and the AppCenter CAPI layer with SNIP. The categories of operations are defined in the file basic_api.c. This chapter deals with the API interface into AppCenter and is primarily intended for programmers who want to develop applications that make use of AppCenter functionality. Users such as systems administrators should not need to refer to this chapter. List of CORBA API operations The following operations are available for AppCenter objects and are located in the appcenter.idl file: Object operations acfindobject() acgetchildren() accreateevent() Object manipulation operations acgetobjectstatus() acgetobjectlabel() acgetobjecttype() acgetobjecthost() Property manipulation operations acgetpropertyvalue() acsetpropertyvalue() Connection to AppCenter operations aclogin() aclogout() Action operations acstart() acstop() acfailover() acincrement() acdecrement() acidle() accycle() CORBA API for AppCenter 8-1

CORBA API usage considerations CORBA API usage considerations How to find the AppCenter object As with all CORBA programs, first the ORB is initialized. Before your client program can invoke any operation of appcorba server, it must first use the _bind() operation to locate that server. The implementation of the _bind() operation is generated automatically by the idl2cpp compiler. The _bind() operation requests the ORB to locate and establish a connection to the server. If, for example, the AppCenter object name in the server is AppCenter1, that object name argument needs to be specified in the _bind() operation as shown below: // Initialize the ORB. CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Bind to an appcenter. AppCenter::AppCenterI_var appcenter = AppCenter::AppCenterI::_bind("AppCenter1"); Error returns AppCenter operations raise the fail exception upon error. See Exceptions on page 6-2 for details. Exporting the environment settings Before you can use all of these functions, it is necessary to set the environment variables for the BROKER_HOST and BROKER_PORT. If you are using VisiBroker s -bind, you also need to set the OSAGENT_PORT. You must do this so that the applications you build can find AppCenter when they run. How you do this varies somewhat between UNIX and Windows platforms. UNIX export export BROKER_HOST = brokerhost export BROKER_PORT = brokerportnumber If you are using VisiBroker s _bind, you also need the command export OSAGENT_PORT = osagentportnumber Note Windows export set BROKER_HOST = brokerhost set BROKER_PORT = brokerport If you are using CORBA, you also need the command set OSAGENT_PORT = osagentport OSAGENT_PORT can be set in the Regedit utility or in the user s environment properties. 8-2 VisiBroker Configuration Reference

C development kit C development kit accreateevent Included is a simple C test.c program that you can use as an example. To compile and link, a simple shell script has been provided. The information about each API invocation is in the header file basic_api.h CORBA development kit Included in this are a CORBA server appcorba.exe and a sample client program test_client.exe and client source code test_client.cpp that you can use as an example. You need to run the server first and then client. To compile test_client.cpp and link it, two sample shell scripts have been provided. These are Makeidl and Makefile. Use Makeidl first to compile idl file and then use Makefile for test_client.cpp using this commands nmake /f Makeidl nmake /f Makefile The information about each API invocation is in the header file basic_api.h. This can only be used with Visual C++, not with UNIX or BCB. Code examples All code examples should be read in conjunction with Example of API usage on page 8-13. Description Syntax Parameters This creates a user-defined event and sends it to the repository. The type of event is always UserEvent. void accreateevent( in string security, in string uuid, in string severity, in string transition,in string cause, in string message, in string solution ) raises(fail); Parameters for this operation include In Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. severity string The severity of the event. transition string What has happened to the object. cause string The cause of the problem. message string Some message that will show up detailing the event. solution string The suggestion action that can be taken for this event. CORBA API for AppCenter 8-3

accycle Values for security, UUID and severity are mandatory. Values for other parameters are optional and if you don't want to use them, just put NULL as the value. Return value Return values for this operation include Return value Type Meaning None Example //create event for Secure_Transfer object const char *severity = "Major"; const char *transition = "none"; const char *cause = "NOT FOUND"; const char *message = "Ping to Agent failed"; const char *solution = "Start the agent"; appcenter->accreateevent(security, uuid, severity, transition, cause, message, solution ); accycle Syntax Description Parameters void accycle( in string security, in string uuid ) raises(fail); This cycles the specified object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->accycle(security, uuid); acdecrement Syntax Description void acdecrement ( in string security, in string uuid ) raises(fail); This decreases by 1 the number of running objects in a specified group. 8-4 VisiBroker Configuration Reference

acfailover Parameters Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acdecrement(security, uuid); acfailover Syntax Description Parameters void acfailover( in string security, in string uuid ) raises(fail); This instruction fails over the specified object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acfailover(security, uuid); acfindobject Syntax void acfindobject( in string security, in string objectpath, out string uuid ) raises(fail); Description This finds an object in the repository based on a supplied path name. The objectpath should be in the same form used by a UNIX file pathname, for example /Configurations/GroupDemo/min_group A pathname / represents the root object (the repository object). CORBA API for AppCenter 8-5

acgetchildren Parameters Return value Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. objectpath string The object path. Return values for this operation include Example // get uuid of Secure_Transfer object const char *objectpath = "/Configurations/Secure_Transfer"; char* uuid = NULL; appcenter->acfindobject(security, objectpath, uuid); cout << "Out from acfindobject() uuid: "<<uuid<<endl; acgetchildren Return value Type Meaning uuid string The string that is returned in uuid represents a unique handle to that object. This handle is used in many of the other routines in order to identify the object that you want to apply an action to. Syntax void acgetchildren( in string security, in string parentuuid, out uuid_list children ) raises(fail); Description Parameters This gets all of the children of a particular parent object. What is returned is an array of UUID strings that can be used in further operations. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. parentuuid string The UUID of the parent object used. Return value Return values for this operation include Return value Type Meaning children uuid_list The UUIDs of all the children of the selected parent object. Example // Get children const char *parentuuid = uuid; AppCenter::uuid_list *children = NULL; appcenter->acgetchildren(security, parentuuid, children ); cout << "Out from acgetchildren() children: "<<children[0]<<endl; 8-6 VisiBroker Configuration Reference

acgetobjecthost acgetobjecthost Syntax void acgetobjecthost( in string security, in string uuid, out string host_uuid ) raises(fail); Description Parameters Given a specific object s UUID, this instruction gets the UUID of the host object that it belongs to. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning host_uuid string The UUID of the host object. Example objectpath = "/Configurations/Secure_Transfer/Demeter"; uuid = NULL; appcenter->acfindobject(security, objectpath, uuid); cout << "Out from acfindobject() uuid: "<<uuid<<endl; char* host_uuid = NULL; appcenter->acgetobjecthost(security, uuid, host_uuid ); cout << "Out from acgetobjecthost() host_uuid: "<<host_uuid<<endl; acgetobjectlabel Syntax void acgetobjectlabel( in string security, in string uuid, out string label ) raises(fail); Description Parameters Given a specific object s UUID, this instruction gets the label name of the object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning label string The label of the selected object. CORBA API for AppCenter 8-7

acgetobjectstatus Example // Get object label Secure_Transfer char* label = NULL; appcenter->acgetobjectlabel(security, uuid, label ); cout << "Out from acgetobjectlabel() label: "<<label<<endl; acgetobjectstatus Syntax void acgetobjectstatus( in string security, in string uuid, out short status ) raises(fail); Description Parameters Given a specific object s UUID, this instruction gets the current status of that object. The return status is a short integer. The potential values of this integer can be found in the include file db_types.h. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return value Return values for this operation include Return value Type Meaning status short Various object statuses. Example CORBA::Short status; appcenter->acgetobjectstatus(security, uuid, status ); cout << "Out from acgetobjectstatus() status: "<<status<<endl; acgetobjecttype Syntax Description Parameters void acgetobjecttype( in string security, in string uuid, out short type, out short folder ) raises(fail); Given a specific object s UUID, this instruction gets the object type and also whether it is a folder or not. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. 8-8 VisiBroker Configuration Reference

acgetpropertyvalue Return values Return values for this operation include Return value Type Meaning type short Refer to include file db_types.h folder short 0 = The object is not a folder. Any other value means that the object is a folder Example objectpath = "/Configurations/Secure_Transfer/Demeter"; uuid = NULL; appcenter->acfindobject(security, objectpath, uuid); cout << "Out from acfindobject() uuid: "<<uuid<<endl; CORBA::Short type; CORBA::Short folder; appcenter->acgetobjecttype(security, uuid, type, folder); cout << "Out from acgetobjecttype() type: "<<type<<" folder: "<<folder<<endl; acgetpropertyvalue Syntax Description Parameters void acgetpropertyvalue( in string security, in string uuid, in string key, out string value ) raises(fail); This gets a property value for a selected object by specifying the property key and the object s UUID. Property keys can be found in the object s properties inspector in the viewer by clicking on the Key column box. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. key string The specific property key to be used. Return values Return values for this operation include Return value Type Meaning value string The value of the selected property. Example const char *key = "AM_COMMAND"; char* value = NULL; appcenter->acgetpropertyvalue(security, uuid, key, value); cout << "Out from acgetpropertyvalue() value: "<<value<<endl; CORBA API for AppCenter 8-9

acidle acidle Syntax Description Parameters void acidle( in string security, in string uuid ) raises(fail); This instruction makes the specified object idle. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acidle(security, uuid); acincrement Syntax Description Parameters void acincrement ( in string security, in string uuid ) raises(fail); This increases by 1 the number of running objects in a specified object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acincrement(security, uuid); aclogin Syntax void aclogin( in string name, in string password, out string security ) raises(fail); 8-10 VisiBroker Configuration Reference

aclogout Description Parameters This is the instruction to login to AppCenter. This operation must be called before using any of the object operations. You must supply a valid name and password that exists in the AppCenter repository. Parameters for this operation include Parameter Type Description name string The name that the user employs to log in. password string The recognized password for that user. Return value Return values for this operation include Example // login to AppCenter const char *name = "admin"; const char *password = ""; char* security = NULL; appcenter->aclogin( name, password, security); cout << "Out from aclogin() security: "<<security<<endl; aclogout Return value Type Meaning security string This string represents a simple form of user authentication. This string must be used with all other object routines. Syntax Description Parameters void aclogout(in string security) raises(fail); The instruction to logout of AppCenter. You will no longer be able to use any of the object operations once this has been passed. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. Return value Return values for this operation include Return value Type Meaning None Example // logout of AppCenter appcenter->aclogout(security); CORBA API for AppCenter 8-11

acsetpropertyvalue acsetpropertyvalue Syntax void acsetpropertyvalue( in string security, in string uuid, in string key, in string value ) raises(fail); Description Parameters This sets the value of a specific property on a specific object according to your instructions. Even if the property is an integer, you still pass in a string value and the routine will take a copy of this value string. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. key string The specific property key to be used. value string The new value of the specified property. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acsetpropertyvalue(security, uuid, key, value); acstart Syntax Description Parameters void acstart( in string security, in string uuid ) raises(fail); This instruction starts the specified object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None 8-12 VisiBroker Configuration Reference

acstop Example // get uuid of Secure_Transfer object const char *objectpath = "/Configurations/Secure_Transfer"; char* uuid = NULL; appcenter->acfindobject(security, objectpath, uuid); cout << "Out from acfindobject() uuid: "<<uuid<<endl; // start Secure_Transfer object appcenter->acstart(security, uuid); acstop Syntax Description Parameters void acstop( in string security, in string uuid ) raises(fail); This instruction stops the specified object. Parameters for this operation include Parameter Type Description security string This string represents a simple form of user authentication. uuid string The UUID of the object used. Return values Return values for this operation include Return value Type Meaning None Example appcenter->acstop(security, uuid); Example of API usage The following illustrates a sample invocation to some operations from client program. This test_client program can be found in the directory AppCenter/ DevKit/Corba. // test_client.cpp #include <fstream.h> #include "appcenter_c.hh" int main(int argc, char* const* argv) { try { // Initialize the ORB. CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Bind to an appcenter. AppCenter::AppCenterI_var appcenter = AppCenter::AppCenterI::_bind("AppCenter1"); CORBA API for AppCenter 8-13

How to compile the test_client.cpp program // login to AppCenter const char *name = "admin"; const char *password = ""; char* security = NULL; appcenter->aclogin( name, password, security); cout << "Out from aclogin() security: "<<security<<endl; // get uuid of Secure_Transfer object const char *objectpath = "/Configurations/Secure_Transfer"; char* uuid = NULL; appcenter->acfindobject(security, objectpath, uuid); cout << "Out from acfindobject() uuid: "<<uuid<<endl; // start Secure_Transfer object appcenter->acstart(security, uuid); // Get children const char *parentuuid = uuid; AppCenter::uuid_list *children = NULL; appcenter->acgetchildren(security, parentuuid, children ); cout << "Out from acgetchildren() children: "<<children[0]<<endl; AppCenter::uuid_list::_release(children); // create event for Secure_Transfer object const char *severity = "Major"; const char *transition = "none"; const char *cause = "NOT FOUND"; const char *message = "Ping to Agent failed"; const char *solution = "Start the agent"; appcenter->accreateevent(security, uuid, severity, transition, cause,message, solution); // Get object label Secure_Transfer char* label = NULL; appcenter->acgetobjectlabel(security, uuid, label ); cout << "Out from acgetobjectlabel() label: "<<label<<endl; } catch(const CORBA::Exception& e) { return(1); } return(0); } Output: Out from aclogin() security: * Out from acfindobject() uuid: L:. Out from acgetchildren() children: 2 L:.. L:. Out from acgetobjectlabel() label: Secure_Transfer This starts Secure_Transfer configuration, creates an event and sends it to the repository that can be viewed at AppCenter Viewer. How to compile the test_client.cpp program If you compile the idl file appcenter.idl using idl2cpp, you will get the header file appcenter_c.hh and file appcenter_c.cc. You must first compile the file appcenter_c.cc and then compile the test_client.cpp program. Finally, link these 8-14 VisiBroker Configuration Reference

How to compile the test_client.cpp program two object files and the ORB library orb_r.lib to get the executable file, say test_client.exe. The Makefile for NT to compile the program is available in AppCenter/DevKit/Corba directory. Makefile ###Makefile ### Multi-threaded Windows Visual C++ (nmake) definitions ### Platform specific compiler definitions (multi-threaded) CC = CL -DWIN32 /GX /MT DEBUG = /Z7 STDCC_LIBS = wsock32.lib kernel32.lib ### VisiBroker directory locations VBROKERDIR = c:\visigenic\vbroker ORBCC = $(VBROKERDIR)\bin\idl2cpp -src_suffix cpp LIBDIR = $(VBROKERDIR)\lib CCINCLUDES = -I. -I$(VBROKERDIR)\include -I$(VBROKERDIR)\include\dispatch ### Multi-threaded ORB library LIBORB = $(LIBDIR)\orb_r.lib ### Compiler flags for debug CCFLAGS = $(CCINCLUDES) $(DEBUG) ### Standard build rules for.cpp files.suffixes:.cpp.obj.h.hh.cpp.obj: $(CC) $(CCFLAGS) -c $< EXE = test_client.exe all: $(EXE) clean: del *.obj del *.hh del *_c.cpp del *_s.cpp del test_client.exe del *.log # # "appcenter" specific make rules # appcenter_c.cpp: appcenter.idl $(ORBCC) appcenter.idl appcenter_s.cpp: appcenter.idl $(ORBCC) appcenter.idl test_client.exe: appcenter_c.obj test_client.obj $(CC) -o test_client.exe test_client.obj \ appcenter_c.obj $(LIBORB) $(STDCC_LIBS) Use the following command to compile the test_client.cpp: prompt> nmake CORBA API for AppCenter 8-15

How to run this test_client.exe program How to run this test_client.exe program If you want to run test_client, make sure you run osagent, db of AppCenter, server appcorba.exe first and then test_client. You can see the effect using AppCenter Viewer. For example, you will see the configuration Secure_Transfer will start and your created event will be displayed in the event browser. Example of a Java test client // Client.java import java.io.*; import java.util.*; import org.omg.corba.*; class Client { public static void main(string args[]) { try { // Initialize the ORB. System.out.println("Initializing the ORB..."); Properties props = new Properties(); ORB orb = ORB.init(args, props); // Bind to an appcenter. System.out.println("Binding to an AppCenter instance..."); AppCenter appcenter = AppCenterHelper.bind(orb, "AppCenter1"); // login to AppCenter System.out.println("Logging in to AppCenter..."); String name = "admin"; String password = ""; StringHolder securityholder = new StringHolder(); appcenter.aclogin( name, password, securityholder); String security = new String(securityHolder.value); System.out.println( "Out from aclogin() security: " + security); // get uuid of Juno object System.out.println("Getting UUID of Juno object..."); String objectpath = "/Configurations/Juno"; StringHolder uuidholder = new StringHolder(); appcenter.acfindobject(security, objectpath, uuidholder); String uuid = new String(uuidHolder.value); System.out.println( "Out from acfindobject() uuid: " + uuid); // start Juno object System.out.println("Starting the Juno object..."); appcenter.acstart(security, uuid); 8-16 VisiBroker Configuration Reference

Example of a Java test client // create event for Juno object System.out.println("Creating an event for Juno..."); String severity = "Major"; String transition = "none"; String cause = "NOT FOUND"; String message = "Ping to Agent failed"; String solution = "Start the agent"; appcenter.accreateevent(security, uuid, severity, message, solution ); // Get object label Juno System.out.println("Getting the object label for Juno..."); StringHolder labelholder = new StringHolder(); appcenter.acgetobjectlabel(security, uuid, labelholder); String label = new String(labelHolder.value); System.out.println( "Out from acgetobjectlabel() label: " + label); } catch(exception e) { System.out.println( "Caught exception: " + e); System.exit(1); } System.exit(0); } } transition, cause, CORBA API for AppCenter 8-17

8-18 VisiBroker Configuration Reference

Chapter 9 Chapter9CORBA-managed object interface This chapter provides you with details about the AppCenter s managed object interface for VisiBroker objects. It will also explain how you can use the managed object interface to enable you to define object level ping and shutdown functionality for AppCenter. Introduction to the managed object interface IDL definition The managed object interface is made available for users who wish 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 typical pinging procedures are unsuitable for your particular requirements. The actual process of determining the state of an object may be particularly complicated and lengthy. 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 operation CORBA-managed object interface 9-1

IDL definition 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 code example that follows demonstrates an implementation of the four operations. /* * Purpose: Define the management interface for an object * */ // generate java stubs and skeletons with: idl2java -package com.inprise.appcenter module Management { /* * Each server should instantiate an object * which implements this interface */ interface Maintained { // ---------------------------------------------------- /* * Prepares a graceful shutdown of the server; * typical tasks include: * o do not accept any more new "sessions" * - deregister the "session factory" from naming/trading * services and the OSagent * - deactivate the "session factory" * o terminate sessions which run beyond a timeout * * Does not return. */ oneway void prepare_shutdown() ; // ---------------------------------------------------- long canshutdown() ; /* * Allows App Center to check whether prepareshutdown() * has completed yet. AppCenter does not support callback * objects yet. * 9-2 VisiBroker Configuration Reference

Ping operation description * Returns: * 0 if shutdown can be called * -1 if prepareshutdown has not yet been called * -2 not ready, but no time specified * >0 not ready (time before it's ready?) */ // ---------------------------------------------------- oneway void shutdown() ; /* * Really shut down. Does not return. */ // ---------------------------------------------------- boolean ping() ; /* * Returns: 0 if successful */ }; }; Ping operation description A user-defined ping on a specific managed object is executed in AppCenter in the same way as any other ping. Once the ping properties are defined for the object in the AppCenter property editor, the ping cycle will proceed according to the properties that you have set. Ping operation 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. Shutdown operation description The process of stopping a managed object with the management object interface follows a well-defined pattern (see Figure 9.1). The only decision point for the CORBA-managed object interface 9-3

Shutdown operation description 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. Figure 9.1 Shutting down a managed object A code example of a Java service implementing the Managed Object Interface is shown below. import java.util.*; public class AccountManagerImpl extends ManagedBank._AccountManagerImplBase {... public void prepareshutdown() { if (!_readytoshutdown) { _readytoshutdown = true; if (_name.equals("bankmanager")) { _readytoshutdownnow = 0; // Allow immediate shutdown } else if (_name.equals("bankmanager1")) { _readytoshutdownnow = 10;// Can shutdown will return 0 for 10 calls } else if (_name.equals("bankmanager2")) { _readytoshutdownnow = 20;// Can shutdown will return false for 20 calls } } } public int CanShutdown() { if (_readytoshutdown) { if (_readytoshutdownnow == 0) { return 0; } else { --_readytoshutdownnow; return -2; } } else { return -1; } } 9-4 VisiBroker Configuration Reference

Shutdown operation description public void Shutdown() { _boa().deactivate_obj(this); } public int PingFunction() { // An example of what a ping actually means db.updatedatabasecursor() ;// Not shown if ( db.cursor_updated == TRUE ) { return 0; }else{ return 1 ; } } private boolean _readytoshutdown = false; private int _readytoshutdownnow = 0; private String _name = null; } Prepare shutdown 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 Can Shutdown until it either gets a confirmation to do so or after a time-out period calls the shutdown operation. Can shutdown 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 Note This action completes the shutdown process, regardless of whether it was a graceful or forceful one. All objects, when requested to be shutdown will be closed eventually, either by graceful or forceful stops. CORBA-managed object interface 9-5

IDL implementation IDL implementation Implementing the IDL involves generating either Java or C++ skeletons with idl2cpp or idl2java respectively. An interface derives from Manageable Object to support the managed object operations described in this chapter. The following IDL demonstrates how to declare an interface with support for the management operations. // Bank.idl #include "management.idl" module Bank { interface Account { float balance(); }; interface AccountManager : Management::Maintained { Account open(in string name); }; }; 9-6 VisiBroker Configuration Reference

A access 1-4 Interface Repository 3-6 remote 1-3 VisiBroker browsers 3-3 accreateevent( ) 8-3 accycle( ) 8-4 acdecrement( ) 8-4 acfailover( ) 8-5 acfindobject( ) 8-5 acgetchildren( ) 8-6 acgetobjecthost( ) 8-7 acgetobjectlabel( ) 8-7 acgetobjectstatus( ) 8-8 acgetobjecttype( ) 8-8 acgetpropertyvalue( ) 8-9 acidle( ) 8-10 acincrement( ) 8-10 aclogin( ) 8-10 aclogout( ) 8-11 acsetpropertyvalue( ) 8-12 acstart( ) 8-12 acstop( ) 8-13 activated objects 4-9 active objects 1-6 add_attribute( ) 6-3 usage example 5-8 adding objects to cockpits 3-9 to configurations 4-8 to Interface Repository 3-6 to Location Service 3-5 to Naming Service 3-3 to Object Activation Daemon 3-7 adding user-defined statistics 5-8 additional_value member 6-11 agents 5-1 all_attributes( ) 6-4 AllObjectsStatusSeq type 6-4 AM_ACTIVATION_POLICY property 7-12 AM_AGENT_IP property 7-11 AM_AGENT_PORT property 7-11 AM_AGENT_SEARCH_SCOPE property 7-11 AM_CHECK_LS property 7-11 Index AM_CHECK_NS property 7-10 AM_CHECK_OAD property 7-12 AM_CHECK_OBJECT property 7-10 AM_CHECK_OBJECT_MO property 7-10 AM_CHECK_TS property 7-10 AM_CLEANUP_LS property 7-11 AM_CLEANUP_NS property 7-10 AM_CLEANUP_OAD property 7-12 AM_CLEANUP_TS property 7-10 AM_CMDLINE_IGNORE property 7-11 AM_CMDLINE_PAIR_ SEPARATOR property 7-17 AM_CMDLINE_VALUE_ ONLY property 7-11 AM_CONTAINER_ID property 7-10 AM_CURRENT_IOR property 7-10 AM_IOR property 7-10 AM_NAME_ID property 7-10 AM_NAME_KIND property 7-10 AM_NAME_ROOT property 7-10 AM_NAMING_NAME property 7-10 AM_OAD_ARGS property 7-12 AM_OAD_ENV property 7-12 AM_OAD_HOST property 7-12 AM_OAD_PATH property 7-12 AM_OAD_REFERENCE_ DATA property 7-12 AM_OAD_REGISTER property 7-12 AM_OAD_TYPE property 7-12 AM_OBJECT_ACTIVATE property 7-12 AM_OBJECT_HOST property 7-11 AM_OBJECT_NAME property 7-11 AM_OBJECT_TYPE property 7-11 AM_PARENT_CONTAINER property 7-10 AM_PING_PID property 7-11 AM_PING_REBIND_ON_ FAILURE property 7-11 AM_REGISTRATION_SLEEP property 7-12 AM_S_ACTIVATION_POLICY property 7-13 AM_S_ARGS property 7-13 AM_S_EXECUTABLE property 7-13 AM_S_IOR property 7-12 AM_S_IS_JAVA property 7-13 AM_S_MI_PING property 7-13 AM_S_MI_SHUTDOWN property 7-13 AM_S_MO_FILE property 7-13 AM_S_MO_PING property 7-13 AM_S_MO_SHUTDOWN property 7-13 AM_S_NAME property 7-12 AM_S_OAD_ENV property 7-13 AM_S_OAD_REFERENCE_ DATA property 7-13 AM_S_PERF_FILE property 7-13 AM_S_PERF_NAME property 7-13 AM_S_TYPE property 7-12 AM_S_USE_MO property 7-12 AM_S_USE_PERF property 7-13 AM_S_VBM_JARFILE property 7-13 AM_SSL_SECURITY property 7-11 AM_STOP_VIA_MO property 7-10 AM_TRADING_NAME property 7-10 AM_VISI_CORBA_DRIVER property 7-11 AM_VSERVER_DRIVER property 7-11 Any Type statistics 5-2 Index I-1

anyattribute identifier 6-6 API functions categorized 8-1 listed 8-3 AppCenter logging into 8-11 logging out 8-11 system requirements 1-2 AppCenter activated servers 4-10 AppCenter object 8-2 appcenter.idl 8-1 appcorba.exe 8-1 application models 2-1 balancing server demands 2-5 building 2-2 defining fault tolerant relationships 2-5 forming dependencies 2-5 generating statistical information 2-4 setting property values 2-5 starting/stopping components 2-3 applications creating 2-2 getting current status 2-4, 5-6, 8-8 getting object names 1-5 applying templates 4-9 associating objects with servers 4-2 Attribute type 6-4 attribute_name member 6-5, 6-11 attribute_type member 6-5 AttributeConfigElement structure 6-5 AttributeConfigSeq type 6-5 overview 5-8 attributename parameter 6-7 AttributeNotFound( ) exception 6-5 attributes 5-8 current monitor status 6-11 customizing 6-3 deleting 6-7 getting 6-4 invalid names 6-5 setting properties 6-5 AttributeType type 6-6 automatic statistical collection 5-3 B binary components 1-3 browsers 3-1 accessing VisiBroker 3-3 starting VisiBroker 3-2 VisiBroker types 1-2 browsing object instances 1-6 buffers 6-6 BufferSizeFull( ) 6-6 building application models 2-2 bus 1-3 C C++ objects BOA options 1-5 collecting statistics for 5-4 implementing IDL definitions 9-6 shutting down managed objects 9-4 user-defined pings and shutdowns 9-2 Can Shutdown method 9-5 changing property settings 4-7 startup latency 4-6 child naming contexts 1-5 children 8-6 classes CORBA specific 4-1 Java 4-1 server supported information 1-6 client applications getting object names 1-5 client requests 1-6 client stubs 1-3 client/server relationships 1-3 cockpits 3-3 adding objects 3-9 monitoring statistics 5-4 overview 5-2 command-line interface enabling statistical collection 5-3 Common Object Request Broker (defined) 1-2 communication services 1-4 compiling example 8-14 components application models 2-2 getting current status 2-4, 5-6, 8-8 initiating processes for 2-4 interfacing with other components 1-3 name space 1-5 CONFIG_OSAGENT_HOST property 7-17 CONFIG_OSAGENT_PORT property 7-17 configuration objects 4-7 configuration templates 4-8 configurations 4-1 adding objects 4-8 Interface Repository 3-6 Location Service 3-5 Naming Service 3-3 OAD interface 3-7 Performance Monitor 3-8 copying location objects 3-5 CORBA API example of usage 8-13 functions categorized 8-1 functions listed 8-3 Java test client 8-16 usage considerations 8-2 CORBA applications 2-1 creating 2-2 CORBA drivers overview 7-1 pinging OAD objects 7-6 pinging OAD-activated servers 7-7 pinging VisiBroker objects 7-4 pinging VisiBroker servers 7-6 process cycle 7-2 setting properties 7-1 shutting down OADactivated objects 7-8 shutting down OADactivated servers 7-9 shutting down VisiBroker objects 7-7 shutting down VisiBroker servers 7-9 starting OAD objects 7-3 starting OAD-activated servers 7-4 starting VisiBroker objects 7-3 starting VisiBroker servers 7-4 CORBA interface 1-1 basics 1-2 I-2 VisiBroker Configuration Reference

implementation repository 1-6 overview 1-2 VisiBroker-compliant versions 1-2 CORBA networks getting statistical information 1-6 naming conventions 1-6 CORBA Object Bus 1-3 architecture 1-3 management interface 4-5 object adapter 1-4 CORBA objects 1-3 adding to cockpit 3-9 locating 2-5 modeling 4-3 CORBA properties reference 7-9 CORBA servers 4-1 identifying 6-10 CORBA template 4-9 CORBAServer template 4-10 counter statistics 5-2 counterattribute identifier 6-6 crashes 2-6 creating distributed applications 2-2 objects from templates 4-9 server objects 4-8 user-defined states 9-3 user-defined statistics 5-5 current status example for retrieving 5-6 getting 2-4, 8-8 updating 6-9 custom attributes 6-3 D daemons 1-6 adding servers 3-7 VisiBroker specific 3-6 data displaying 5-2 data structures listed 6-2 object monitoring 5-5 user-defined statistics 5-8 data types 6-2 decrementing running objects 8-4 default attributes 6-4 default context 1-5 defining application components 2-2 server readiness 4-2 delays 4-6 delete_attribute( ) 6-7 deleting attributes 6-7 dependencies 2-5 development kit 8-3 displaying active objects 1-6 data 5-2 hierarchies 1-5 distributed applications 2-1 creating 2-2 distribution member 6-11 distribution statistics 5-2 distribution_bounds member 6-5 distributionattribute identifier 6-6 DistributionList type 6-7 documentation 1-1 typographic conventions 1-8 down state 9-3 drag and drop 3-2 driver modules 7-1 E enumerated data type 6-2 environment settings 8-2 events creating 8-3 exceptions 6-2 invalid attribute names 6-5 object not found 6-9 executable files 4-1 F failovers 8-5 failures 2-6 fault tolerance relationships 2-5 finding naming contexts 1-5 objects 2-5, 4-3 objects in repository 8-5 function calls (sample) 8-13 functions alphabetical listing 6-1 CORBA API categorized 8-1 CORBA API listed 8-3 getting statistical lists for 6-9 redefining 9-1 G graceful shutdowns 9-5 graphical tools 1-5 graphs 1-6 H hierarchies 1-5 histogram of values 6-7 hosts, getting UUID 8-7 I identifiers 1-5, 4-3 getting UUID 8-7 IDL (Interface Definition Language) 1-2, 9-1 implementing 9-6 idle 8-10 implementation repository 1-6 incrementing running objects 8-10 inheritance 4-9 initialization process 4-4 instance_name member 6-10 instance_name parameter 6-8 instances 1-6 generating object 3-3 Interceptor (VisiBroker) 5-1 Interface Definition Language (IDL) 1-2, 9-1 implementing 9-6 interface repositories 1-6 adding object implementation to 1-6 adding objects 3-6 locating objects 8-5 Interface Repository 1-6 accessing 3-6 adding object implementation to 1-6 adding objects 3-6 locating objects 8-5 overview 3-6 interface_name member 6-10 interface_name parameter 6-8 J jar files 4-4 performance statistics 5-3 Java classes 4-1 Java code samples adding user-defined statistics 5-8 Index I-3

custom attributes 6-3 retrieving status 5-6 Java servers collecting statistics for 5-4 Java test client 8-16 L labels 8-7 latency 4-6 load balancing 2-5 locating naming contexts 1-5 objects 2-5, 4-3 objects in repository 8-5 Location Service 1-6 adding objects 3-5 LOCdebug property 7-16 LOCtimeout property 7-16 LOCverify property 7-17 loggins 8-11 logouts 8-11 long running processes 4-1 M MAIN_PHASE property 7-2 makefiles 8-15 Manageable Object class 4-4 managed object interface 4-4 implementing IDL definitions 9-6 overview 9-1 specifying IDL definitions 9-1 managed objects running 9-3 shut down procedure 9-3 shutting down 7-7 starting with CORBA drivers 7-3 management interface 4-5 management objects 2-3 overview 4-5 starting 4-5 maximum member 6-11 method_name member 6-9 methods 4-4 alphabetical listing 6-1 CORBA API categorized 8-1 CORBA API listed 8-3 example for calling 8-13 getting statistical lists for 6-9 redefining 9-1 middleware 1-1 minimum member 6-11 models for distributed applications 2-1 building 2-2 modifying property settings 4-7 startup latency 4-6 Monitor Agent 5-1 enabling statistical collection 5-3 enabling/disabing performance monitoring 6-8 Monitor Agent interface 5-11 alphabetical listings 6-3 components summarized 6-1 data structures 5-5 exceptions 6-2 methods listed 6-1 monitor( ) 6-7 monitor.idl 5-11 monitoring performance 4-4 monitoring tool 1-6 N name binding 1-5 name space 1-5 names 1-5, 8-7 NAMIMG_DEBUG_FLAG property 7-16 naming contexts 1-5 Naming Service (VisiBroker) 1-5 adding objects 3-3 overview 3-3 naming service factory 1-5 naming services 1-5 NAMING_FACTORY_NAME property 7-16 NAMING_SERVICE_LOGFILE _NAME property 7-16 newstatus parameter 6-9 O OAagent property 7-15 OAconnectionMax property 7-15 OAconnectionMaxIdle property 7-15 OAD interface 3-7 configuring 3-7 overview 3-6 OAD objects 4-3 checking existence 7-6 pinging 7-6 setting properties 4-10, 7-3, 7-6, 7-8 shutting down 4-7 starting 4-6, 7-3 OAD repository 1-6 OAD servers 4-1 applying templates 4-10 configuring 3-7 pinging 4-7 pinging from CORBA drivers 7-7 starting 4-5, 7-4 OAD template 4-10 OAD_Server template 4-10 OAgarbageCollectTimer property 7-15 OAid property 7-15 OAipAddr property 7-15 OAlocalIPC property 7-15 OAport property 7-15 OArcvbufsize property 7-15 OAsendbufsize property 7-15 OAshmsize property 7-16 OAtcpNoDelay property 7-16 OAthreadMax property 7-16 OAthreadMaxIdle property 7-16 OAthreadStackSize property 7-16 Object Activation Daemon (OAD) 1-6 object adapter 1-4 Object Adapter (OA) 1-4 options 1-4 object classes 4-4 object manipulation methods 8-1 object methods 8-1 object_data member 6-10 object_status( ) 6-8 object_status_all( ) 6-8 usage example 5-6 object_status_update( ) 6-9 usage example 5-8 ObjectNotFound( ) exception 6-9 objects 2-2 adding implementation to repository 1-6 adding to cockpits 3-9 adding to configurations 4-8 adding to Interface Repository 3-6 I-4 VisiBroker Configuration Reference

adding to Location Service 3-5 adding to Naming Service 3-3 as binary components 1-3 associating with servers 4-2 browsing 1-6 caution for transience 4-3 checking existence 7-5, 7-6 client/server relationships 1-3 creating from templates 4-9 creating server 4-8 data structures 5-5 decrementing running 8-4 displaying active 1-6 driver functions 7-2 getting current status 2-4, 6-8 getting names 1-5, 8-7 getting property values 8-9 getting statistical information 1-6 getting types 8-8 incrementing running 8-10 instantiating 3-3 iterating through 8-4 locating 2-5, 4-3 locating in repository 8-5 pinging 4-7, 7-4 referencing 1-5 registration delays 4-6 setting properties 4-9 setting properties for specific 8-12 shutting down 4-6, 7-7 shutting down specified 8-13 starting 4-5 starting specified 8-12 updating 4-10 updating status 6-9 ObjectStatusElement structure 6-9 ObjectStatusSeq type 6-9 ObjectTimeElement structure 6-10 ObjectTimeSeq type 6-10 overview 5-5 on demand servers 4-1 starting 4-5 online documentation 1-1, 1-2 typographic conventions 1-8 online resources 1-8 operations 4-4 ORB (CORBA Object Bus) 1-3 architecture 1-3 management interface 4-5 object adapter 1-4 ORBagentAddr property 7-14 ORBagentPort property 7-14 ORBbackCompat property 7-14 ORBbackdii property 7-14 ORBconnectionMax property 7-14 ORBconnectionMaxIdle property 7-14 ORBir_ior property 7-14 ORBir_name property 7-14 ORBnullString property 7-14 ORBrcvbufsize property 7-14 ORBsecuresetattr property 7-14 ORBsecureShutdown property 7-14 ORBsendBind property 7-15 ORBsendbufsize property 7-15 ORBshmsize property 7-15 ORBtcpNodelay property 7-15 OSAgentPort property 4-8 override 9-1 P parents 8-6 Performance Monitor adding user-defined statistics 5-8 configuring 3-8 enabling statistical collection 5-3 opening 3-8 overview 3-8 Performance Monitor Engine overview 5-2 performance monitoring 4-4 collection process 5-1 enabling statistical collection 5-3 enabling/disabling 6-7 from the cockpit 5-4 process illustrated 5-3 per-method objects 1-4 PIDs 4-3 ping function 9-3 overview 9-3 usage example 9-2 pinging objects 7-4 servers 4-7 servers with CORBA drivers 7-6 user-defined 9-1, 9-3 pinging delays 4-6 polling 5-2 POST_PHASE property 7-2 PRE_PHASE property 7-2 printed documentation 1-1 typographic conventions 1-8 process IDs 4-3 processes 2-2 getting current status 2-4 initialization 4-4 initiating 2-4 long running 4-1 properties attributes 6-5 CORBA drivers 7-1 getting assigned values 8-9 inheriting values 4-9 modeling 2-5 OAD objects 7-3, 7-6, 7-8 setting for specific objects 8-12 VisiBroker objects 7-3, 7-4, 7-7 VisiBroker servers 7-4 property editors 4-9 property keys 8-9 property manipulation methods 8-1 purge_data parameter 6-8 R references 1-5 registration delays 4-6 remote access 1-3 removing attributes 6-7 reporting tool 1-6 repository 1-6 adding object implementation to 1-6 adding objects 3-6 locating objects 8-5 requests 1-4 client initiated 1-6 resources 1-8 root context 1-5 running managed objects 9-3 running test_client program 8-16 S sample calls 8-13 scalability 2-1 server classes 4-1 server_id( ) 6-10 Index I-5

servername member 6-10 servers activation policies 1-4 adding to configurations 3-7 applying templates 4-10 associating objects with 4-2 balancing demands 2-5 creating objects for 4-8 handling failures 2-6 managing 4-5 monitoring performance 4-4 pinging 4-7 pinging with CORBA drivers 7-6 setting startup latency 4-6 shutting down 4-6 shutting down with CORBA drivers 7-9 starting 4-5 starting with CORBA drivers 7-4 types described 4-1 setting properties 4-9 attributes 6-5 CORBA drivers 7-1 for specific objects 8-12 OAD objects 7-3, 7-6, 7-8 VisiBroker objects 7-3, 7-4, 7-7 VisiBroker servers 7-4 setting startup latency 4-6 setting up Performance Monitor 3-8 shared libraries 4-4 shared objects 1-4 shutdown functions 9-3 overview 9-5 usage example 9-2 Shutdown method 9-5 shutting down application components 2-3 objects 4-6, 7-7 servers 4-6 servers with CORBA drivers 7-9 specified objects 8-13 user-defined 9-1, 9-5 standalone objects 1-4 starting application components 2-3 OAD objects 7-3 OAD servers 7-4 objects 4-5 Performance Monitor 3-8 servers 4-5 servers with CORBA drivers 7-4 specified objects 8-12 VisiBroker browser 3-2 VisiBroker objects with CORBA drivers 7-3 startup latency 4-6 states 2-4 defining 9-3 statistics 1-6 adding user-defined to Performance Monitor 5-8 creating user-defined 5-5 enabling collection 5-3 enabling/disabling monitoring 6-7 for individual methods 6-9 modeling 2-4 monitoring with cockpits 5-4 performance monitoring and 4-4 process overview 5-1 updating current status 6-9 status creating user-defined states 9-3 example for retrieving 5-6 getting 2-4, 8-8 updating 6-9 status member 6-9 StatusElement structure 6-11 overview 5-5 stopping application components 2-3 objects 7-7 servers 4-6 servers from CORBA drivers 7-9 specified objects 8-13 stubs 1-3 system failures 2-6 system requirements 1-2 T templates 4-8 applying to new objects 4-9 test_client program 8-13 compiling 8-14 running 8-16 thenewattribute parameter 6-3 tools (VisiBroker Manager) 1-5 total member 6-11 transient objects 4-3 turnon parameter 6-7 U unavailable state 9-3 unique universal identifiers (UUIDs) 8-7 UNIX driver modules 7-1 up states 2-4, 9-3 updating objects 4-10 status 6-9 user-defined events 8-3 user-defined pings 9-1 creating 9-3 user-defined shutdown 9-1 creating 9-5 user-defined statistics 5-2 adding to Performance Monitor 5-8 creating 5-5 UserEvent type 8-3 UUIDs 8-7 V VBJ BOA options 1-5 viewer 3-2 viewing active objects 1-6 data 5-2 hierarchies 1-5 VisiBroker browsers 1-2, 1-5 accessing 3-3 available tools 3-2 starting 3-2 usage overview 3-1 VisiBroker compliant versions 1-2 VisiBroker drivers 7-1 VisiBroker interface 1-5 VisiBroker jar files 4-4 VisiBroker Object Adapter (OA) 1-4 options 1-4 VisiBroker objects 2-3 checking existence 7-5 overview 4-5 pinging 4-7, 7-4 running 9-3 setting properties 7-3, 7-4, 7-7 shutting down 4-6, 7-7 starting 4-5 starting with CORBA drivers 7-3 types described 4-3 updating 4-10 I-6 VisiBroker Configuration Reference

VisiBroker Performance Monitor adding user-defined statistics 5-8 configuring 3-8 enabling statistical collection 5-3 opening 3-8 overview 3-8, 5-2 VisiBroker reference 1-1 VisiBroker servers 4-1 associating objects with 4-2 collecting statistics for 5-3 pinging 4-7 pinging from CORBA drivers 7-6 setting properties 7-4 shutting down 4-6 starting 4-5 starting with CORBA drivers 7-4 Visual Basic C++ objects BOA options 1-5 collecting statistics for 5-4 implementing IDL definitions 9-6 shutting down managed objects 9-4 user-defined pings and shutdowns 9-2 visual interface 1-6 W Windows driver modules 7-1 wizards collecting performance statistics 5-3 creating server objects 4-2, 4-8 updating VisiBroker objects 4-10 Index I-7