VisiBroker Configuration Reference

Transcription

1 VisiBroker Configuration Reference VERSION 1.6 InpriseAppCenter Inprise Corporation, 100 Enterprise Way Scotts Valley, CA

2 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. ACE0016WW E1R PDF

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

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

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

6 Tables 4.1 Supplied VisiBroker runtime libraries CorbaObject CorbaContainer OnDemandObject CorbaServer VB_BaseObject VB_Object OAD_Object VB_Server OAD_Server ORB options BOA options Name service Location Service VB_Configuration VB_BaseServer Figures 1.1 CORBA architecture Accessing the VisiBroker browsers Selecting root name Copying a location object Opening the Interface Repository Copying an OAD Opening the Performance Monitor Copying to a cockpit Creation wizard options Templates for objects actioned by AppCenter Templates for objects actioned by the OAD Templates for servers actioned by AppCenter Templates for servers actioned by the OAD Performance monitor architecture Statistics gathering with a wizard Object data structure Attribute data structure Shutting down a managed object iv

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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 call Inprise Assist at (800) , or contact our Sales Department at (800) 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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 VisiBroker Configuration Reference