VisiBroker
®Configuration Reference
V E R S I O N 1 . 6
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 6 5 4 3 2 1 PDF
i
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
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
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
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
Tables
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 byAppCenter . . . 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
I n t r o d u c t i o n 1-1
C h a p t e r
1
Chapter1
Introduction
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.
This manual’s target
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.
V i s i B r o k e r - c o m p l i a n t v e r s i o n s
• This manual, which provides information about dealing with distributed applications that employ VisiBroker as their middleware.
Note All books are available online in HTML and PDF format.
VisiBroker-compliant versions
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 type
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,
AppCenter 1.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
CORBA basics
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
C O R B A o b j e c t s
I n t r o d u c t i o n 1-3 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.
O b j e c t A d a p t e r
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 • OAthreadMaxV i s i B r o k e r b a s i c s I n t r o d u c t i o n 1-5
VBJ only
• OAthreadmin • VBC++ only • OAagent • OAgarbageCollectTimer • OAlocalIPC • OArcvbufsize • OAsendbufsize• OAshmisze (Windows only) • OAtcpNoDelay
• OAthreadStackSize
VisiBroker basics
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.
A b o u t t h e P e r f o r m a n c e M o n i t o r
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.
W h a t ’ s i n t h i s b o o k
I n t r o d u c t i o n 1-7 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.
What’s in this book
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.
M a n u a l c o n v e n t i o n s
Manual conventions
This manual uses the typefaces and symbols described in the table below to indicate special text.
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.
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
M a n a g i n g C O R B A o b j e c t s a n d p r o c e s s e s 2-1
C h a p t e r
2
Chapter2
Managing CORBA objects
and processes
CORBA and application modeling
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.
B u i l d i n g a n a p p l i c a t i o n m o d e l
• 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?
S t a r t i n g a n d s t o p p i n g c o m p o n e n t s
M a n a g i n g C O R B A o b j e c t s a n d p r o c e s s e s 2-3 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.
G e t t i n g t h e s t a t u s
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.
D e p e n d e n c i e s
M a n a g i n g C O R B A o b j e c t s a n d p r o c e s s e s 2-5
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.
C l e a n i n g u p
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.
U s i n g V i s i B r o k e r b r o w s e r s 3-1
C h a p t e r
3
Chapter3
Using 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.
B r o w s e r s a v a i l a b l e
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
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
Note 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.
U s i n g b r o w s e r s w i t h t h e c o c k p i t
U s i n g V i s i B r o k e r b r o w s e r s 3-3
Using browsers with the cockpit
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.
Naming Service
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.
L o c a t i o n S e r v i c e
4 Click the Root Name combo box and select the root context that you want to
use.
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.
Location Service
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 right-clicking 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.
A d d i n g o b j e c t s t o a c o n f i g u r a t i o n i n A p p C e n t e r
U s i n g V i s i B r o k e r b r o w s e r s 3-5
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.
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.
I n t e r f a c e R e p o s i t o r y
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.
Object Activation Daemon
Interface features
The AppCenter Object Activation Daemon incorporates a number of features that make it easy to use within AppCenter.
A d d i n g s e r v e r s t o a c o n f i g u r a t i o n i n A p p C e n t e r
U s i n g V i s i B r o k e r b r o w s e r s 3-7 • 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.
P e r f o r m a n c e M o n i t o r b r o w s e r
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.
A d d i n g C O R B A o b j e c t s t o a c o c k p i t
U s i n g V i s i B r o k e r b r o w s e r s 3-9
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.
G e t t i n g s t a t i s t i c s f r o m a C O R B A c o n f i g u r a t i o n e x a m p l e
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).
Note 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.
A d d i n g a n o b j e c t t o a c o n f i g u r a t i o n
U s i n g V i s i B r o k e r b r o w s e r s 3-11 • 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
M o n i t o r i n g t h e o b j e c t
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
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.
Note The instrument will not display any activity if the object is not being used. You
B u i l d i n g C O R B A c o n f i g u r a t i o n s 4-1
C h a p t e r
4
Chapter4
Building 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.
D e f i n i n g V i s i B r o k e r s e r v e r r e a d i n e s s
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.
O b j e c t s
B u i l d i n g C O R B A c o n f i g u r a t i o n s 4-3
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.
P e r f o r m a n c e c o n c e p t s
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.
M a n a g e m e n t o b j e c t c o n c e p t s
B u i l d i n g C O R B A c o n f i g u r a t i o n s 4-5
Management object concepts
A server can optionally have a management object associated with it. This object must be uniquely defined for every server (that is, the object instance name needs to be unique). The uniqueness is necessary to guarantee that the object is actually inside a particular server.
You need to write this object and create it when the server starts up. The management object implements the Manageable Object Interface, described in the previous section. The difference is that when the ping operation is called it is pinging the server. When shutdown is called, it is shutting down the server not just one object.
The AppCenter Server wizard allows you to declare the Management Object associated with a server and how it should be used.
VisiBroker management interface concepts
The VisiBroker ORB also contains a management interface that can be used to shutdown a server (but not individual objects). In order to use this interface to shutdown a server, AppCenter needs to know how to locate an object that is inside the server. This can be the Performance Agent object (if used), the Management Object (if used) or you can specify some other object to use. The AppCenter Server wizard allows you to define these things to AppCenter.
Starting
VisiBroker servers
The starting of VisiBroker servers is controlled by AppCenter, so AppCenter (or the AppCenter Agent running on the appropriate host) will start the executable or start the Java VM as appropriate.
OAD servers
AppCenter does not start OAD servers. OAD servers are started on demand by the OAD itself. AppCenter will simply mark these servers as up when the OAD with which they are registered is available.
VisiBroker objects
VisiBroker objects (those that exist within a VisiBroker server) do not need to be explicitly started. When the server starts up, they will be started automatically by it. The concept of starting a VisiBroker object inside of AppCenter is merely to find the object’s IOR (Interoperable Object Reference), that is, the “handle” to the object.
O A D o b j e c t s
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.
O A D o b j e c t s
B u i l d i n g C O R B A c o n f i g u r a t i o n s 4-7
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.
