Introduction to TME 10 ADE

Transcription

1 Introduction to TME 10 ADE Version 3.2 July 30, 1997

2

3 Introduction to TME 10 ADE (July, 1997) Copyright Notice Copyright 1991, 1997 by Tivoli Systems, an IBM Company, including this documentation and all software. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of Tivoli Systems. The document is not intended for production and is furnished as is without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation. Trademarks The following product names are trademarks of Tivoli Systems or IBM Corporation: AIX, IBM, OS/2, RISC System/6000, Tivoli Management Environment, and TME 10. Microsoft, Windows, and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited. Other company, product, and service names mentioned in this document may be trademarks or servicemarks of others. Notice References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to Tivoli System s or IBM s valid intellectual property or other legally protectable right, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Patents may be pending.

4

5 Introduction to TME 10 ADE Preface... ix Chapter 1 Introduction to TME 10 TME 10 Framework TME Product Structure Architecture Overview Application Programming Interfaces Heterogeneity and Interoperability Management Services CORBA The CORBA 1.1 Specification Scalability One-way and Two-way Connections Name Registry Inter-region Resource Exchange TMRs and the Administrator s Desktop Other Concepts for the TME 10 Framework Managed Resources Policies and Policy Regions Profiles and Profile Managers Chapter 2 Framework Services Introduction to Framework Services TME 10 Object Request Broker (ORB) Communication between Objects Persistent Storage Tivoli Extended IDL (TEIDL) Transactions Service Introduction to TME 10 ADE v

6 Transaction Hierarchies Transaction Types Two-Phase Commit Transaction Events Concurrency and Locking Service Critical Section Locking Transaction Duration Locking Security Service Authentication and Authorization Kerberos Operating System Privileges Object Groups Machine Boundaries and Cascaded Operations Secure Method Invocation Method Activation Policies Server Types Server Execution Chapter 3 Application Services Introduction to Application Services Enabling Services Collection Service Instance Management Service Policy Service Customization Management Service Advanced Application Services Managed Nodes Scheduling Service Jobs Time-Based Scheduling Frequency-based Scheduling Retry on Failure vi Version 3.2

7 Schedule Management Job Status Notification Scheduling and Multiple TMRs Notification Service Configuration and Change Management Service Database Interface APIs TAS Run-time Library Distributed Exception Handling Memory Management File I/O Inter-object Message Service Message Catalogs Regular Expression Data Encryption Data Manipulation Directory Services Task Library Chapter 4 Desktop Services Introduction to Desktop Services Dialog Specification Language (DSL) and Compiler Active Gadgets Inactive Gadgets DSL Features TME 10 Desktop Desktop Services Library Desktop Commands (DTC) Dialog Editing Library (DEL) Desktop Services Miscellaneous Functions Gadget Library Introduction to TME 10 ADE vii

8 Chapter 5 TME 10 ADE Documentation Library Documentation Library Introduction to TME 10 ADE Framework Services Manual Application Services Manual, Volumes 1 and Desktop Services Manual Application Development with TME 10 ADE Application Development for the Lightweight Client Framework Programmer s Reference Manual TME 10 ADE Master Index Chapter 6 Installing TME 10 ADE Software Requirements Hardware Requirements Clients Servers Installation Procedure Desktop Command Line Upgrade Procedure viii Version 3.2

9 Preface Preface The Tivoli Management Environment 10 (TME 10) is a powerful environment in which to run applications for managing distributed systems. The TME 10 Advanced Development Environment (TME 10 ADE) provides the added advantage of access to an equally powerful development environment. This manual provides an overview of TME 10 ADE. TME 10 ADE is compliant with the features specified by the Common Object Request Broker Architecture (CORBA), version 1.1, provided by the Object Management Group (OMG). The CORBA specification defines a client/server system in which the client and server are completely separated. The system uses object encapsulation to achieve this separation, which improves the development process on distributed, heterogeneous networks. TME 10 ADE provides the following services: Framework services, which support the development process. Application services, which reduce the cost of and simplify application development in complex heterogeneous networks. Desktop services, which are designed to facilitate the development of a graphical user interface (GUI) for your application. Finally, a set of tools (called the Productivity Kit) is available that can further facilitate the development of your application. This manual describes these services and tools, how to use them, and how to install them. Who Should Read This Manual This manual introduces concepts you must know to effectively use TME 10 ADE to develop applications in a heterogeneous environment. You should have a knowledge of the UNIX operating system and the C programming language before reading this manual. Introduction to TME 10 ADE ix

10 Preface Related Documents The information in this manual describes the services available from TME 10 ADE. These services are documented in greater detail in the following manuals: The Framework Services Manual Discusses the CORBA-compliant framework and the Interface Definition Language (IDL) in the context of TME 10 ADE. The Application Services Manual, Volumes 1 and 2 Describes high-level services available from TME 10. Application Development with TME 10 ADE Documents a complete sample ADE application. The Desktop Services Manual Explains how to develop a graphical user interface (GUI) for your application. Application Development for the Lightweight Client Framework Describes how to develop applications to work with lightweight client framework (LCF) endpoints. What This Manual Contains Introduction to TME 10 ADE provides the following information: Chapter 1, Fundamental Concepts of TME 10 ADE Provides an introduction to fundamental concepts of TME 10 ADE. Chapter 2, Framework Services Describes the services available to developers of applications using TME 10 ADE. Chapter 3, Application Services Describes the application-level services available to developers using TME 10 ADE. Chapter 4, Desktop Services Describes the desktop-level services, such as for developing the GUI, available to developers using TME 10 ADE. Chapter 5, TME 10 ADE Documentation Library Describes the documentation set for TME 10 ADE. x Version 3.2

11 Preface Chapter 6, Installing TME 10 ADE Describes how to install TME 10 ADE. Typeface Conventions This manual uses several typeface conventions for special terms and actions. These conventions have the following meaning: Bold Italics Bold Italics Monospace Platform-specific Information Commands, keywords, filenames, or other information that you must use literally appear in bold. Names of windows, dialogs, and other controls also appear in bold. Variables and values that you must provide appear in italics. New terms appear in bold italic the first time they are used. Code examples appear in a monospace font. The following markers are used to identify platform-specific information or procedures: Icon AIX AT&T DG/UX HP-UX Motorola Supported Platform IBM RS/6000 series running AIX AT&T 3000 series running AT&T UNIX SVR4 MP-RAS Release Data General AViiON series running DG/UX version 5.4R3.00. HP9000/700 and 800 series running HP/UX 9.00 through 9.05, 10.01, or Motorola 88K series running SVR4 version R40V4.2. Introduction to TME 10 ADE xi

12 Preface Icon NT Solaris SunOS SVR4 Supported Platform Clients or servers: IBM-compatible PCs 486 or higher running Microsoft Windows NT version Sun SPARC series running Solaris 2.3 or 2.4. Sun SPARC series running SunOS or All SVR4-based platforms including: AT&T UNIX SVR4, DG/UX version 5.4R3.00, Motorola, Solaris, and UnixWare 2.0. Contacting Tivoli Customer Support We are very interested in hearing from you about your experience with the products in TME 10. We welcome your suggestions for improvements. If you encounter difficulties with any TME 10 product, please contact your customer support representative. Tivoli also includes the wsupport command. This command prompts you for problem information, which can be ed to your support provider or saved as a text file. You can then print the saved file and fax the resulting TME Problem Report form to your support provider. xii Version 3.2

13 1 1Introduction to TME 10 Introduction to TME 10 Today s computing environment increasingly comprises a distributed client/server setup for information system needs. The distributed computing environment can tie people, information, and resources together very closely, but it is a challenge to manage these computing resources. Maintaining many different types of hardware and operating systems is a major challenge in large enterprises. Tivoli Systems answers this challenge with a suite of management applications that, collectively, are the Tivoli Management Environment (TME) 10. TME 10 enables you to manage distributed computing resources of many different types from a single point. Tivoli products provide a consistent interface to different operating systems and services. TME 10 allows administrators to control users, systems, and applications from one desktop and provides a streamlined way to automate and delegate routine, time-consuming tasks. TME 10 is a suite of distributed systems management products that address these system managed needs in distributed computing enterprise: Heterogeneity Runs on many different platforms. System administrators need not be concerned with the machine architecture. The network environment can support multiple architectures. Interoperability Enables many different platforms to operate together. A system administrator using one machine can manage Introduction to TME 10 ADE 1 1

14 TME 10 Framework resources on other machines regardless of architecture. Such interoperability extends system heterogeneity, enabling system administrators to seamlessly manage any type of machine from any other type of machine. Scalability Handles large computing enterprises. Managing networks comprising thousands of nodes can produce serious difficulties for system administrators. Using Tivoli Managed Regions (TMRs), system administrators can easily distribute changes (such as creating a new user) to large networks. Distributed services Provides services across distributed systems. A robust framework with APIs Enables all products and customer-developer applications to work together and leverage standard APIs. Dependability Management transactions ensure consistency and can back-out half-completed operations across the network. This is potentially important in large distributed environments where multiple administrators can simultaneously perform operations. CORBA 1.1 compliance The Object Management Group (OMG) proposed CORBA 1.1 as a standard for all common Object Request Broker (ORB) systems. TME 10 is compliant with this standard. This chapter briefly describes the TME 10 Framework, the TME products, and then introduces the architecture of the TME 10 Framework. It provides background for understanding TME 10 ADE and the three sets of services it provides: framework services, application services, and desktop services. TME 10 Framework The TME 10 applications all share a common framework, the TME 10 Framework. The TME 10 Framework is an open, object-oriented framework that includes a set of managers, brokers, and agents that conform with Object Management Group/Common Object Request Broker Architecture (OMG/CORBA) specifications. 1 2 Version 3.2

15 TME Product Structure This technology allows major differences between computer operating systems to be hidden from the TME 10 user, and it allows key services to be encapsulated in objects that can be used by multiple management applications. The TME 10 Framework provides platform-independence, a unifying architecture for all applications, and the ability for third-party vendors to easily adapt, or plug in to, the framework. In addition, a robust set of APIs and services enables customers to write applications that also plug in to, or leverage, the TME 10 Framework. Introduction to TME 10 TME Product Structure The following figure illustrates the TME 10 product structure. Third-party Application TME 10 Inventory TME 10 Software Distribution Third-party Application TME 10 Event Integration Facility TME 10 Plus Modules TME 10 User Administration TME 10 Enterprise Console TME 10 Framework TME 10 Distributed Monitoring TME 10 Net.Commander TME 10 Application Extension Facility TME 10 Application Development It is important to understand that the TME 10 Framework is distinct from other TME 10 applications. It can be purchased and installed separately from any management application, either from Tivoli or a third party. Introduction to TME 10 ADE 1 3

16 Architecture Overview In TME 10, facilities such as installation, the management desktop, notification subsystem, and policy regions are part of the TME 10 Framework, rather than one of Tivoli s applications. When customers install the TME 10 Framework by itself, they see the management graphical user interface complete with the following: Managed node icons Policy regions Notification bulletin board Administrator definitions Policy and task libraries Scheduler Architecture Overview TME 10 represents several major advancements for managing large networks of heterogeneous, distributed systems. It has two primary components: a comprehensive management platform (TME 10 Framework) and a set of X/Open-compliant APIs. Application Programming Interfaces The application programming interfaces (APIs) to the TME 10 Framework are open and documented in TME 10 ADE. These APIs enable both Tivoli and independent third-party software developers to build systems management applications. The TME 10 Framework is built around an implementation of the OMG CORBA 1.1 environment. It also provides an implementation of the enabling services adopted by X/Open as the basis for a systems management framework. On top of the CORBA ORB and the enabling services are a set of management services, user interface services, and advanced application services. These services together form the application programming interface to which systems management applications are written, and which make up TME 10 ADE. 1 4 Version 3.2

17 Architecture Overview The following figure identifies the application programming interfaces and their relationship to each other in TME 10 ADE: Tivoli and Third-party Applications Advanced Application Services UI Services Enabling Services Introduction to TME 10 CORBA ORB and Security Operating System/Transport The TME 10 ADE API is available in these ways: By linking to one or more ANSI C run-time libraries Through client stubs generated from interface descriptions specified in OMG IDL You can choose to write to one or more layers from this API, or substitute alternate services and libraries from third parties as appropriate. Tivoli provides support for the same programming interfaces across all supported architectures, which provides a significant portability layer. You can combine these services using the GNU C and C++ compilers (provided as part of the Tivoli Productivity Toolkit). The result is a highly portable set of services, APIs, and tools for systems management application development. Heterogeneity and Interoperability TME 10 supports heterogenous systems management. This means that the TME 10 server can be of any supported architecture type and TME 10 clients can be any mix of supported architecture types. The TME 10 Framework is available on the following architectures: IBM RS/6000 series running AIX 3.2.5, 4.12, 4.13, or 4.2. HP9000/700 and 800 series running HP/UX 9.00 through 9.05, 10.01, 10.10, or Introduction to TME 10 ADE 1 5

18 Management Services Sun SPARC series running Solaris 2.3, 2.4, 2.5, or Sun SPARC series running SunOS or Microsoft Windows NT 3.51 and Windows NT 4.0. In heterogeneous networks, applications have traditionally been required to explicitly cope with the data requirements for each platform. Each time the application transmits data, it must be able to convert the data from the native format to the destination format. The TME 10 Framework ORB removes this consideration from application programmers. When a request to run an operation on some object is made, a client stub initiates the request, collects the data associated with the request, and converts the data from its current format to a common format. This process (known as data marshaling) is performed in accordance with the ASN.1 standard. ASN.1 converts data to a canonical form for transmission to a machine of undetermined platform type. When the data conversion is complete, the client stub passes the marshaled data to the ORB. The ORB then sends the data to the Basic Object Adaptor (BOA), and ultimately to the appropriate server skeleton. The server skeleton then reformats the data according to the requirements of the object implementation. This process is known as data unmarshaling. The advantage of this procedure is that developers can focus their efforts on the task of application development. Without this process, developers must also be concerned with the requirements imposed on the data format by each architecture in the distributed system. Management Services The system management framework fits into the X/Open reference model and is built on top of an OMG CORBA 1.1 foundation. It provides a set of enabling management services for your application. These services include policy, extensibility, scheduling, collections, and instance management. When used with other interfaces and services found in TME 10, they enable you to develop sturdy, feature-rich systems management applications. 1 6 Version 3.2

19 CORBA 1.1 The following figure illustrates the X/Open reference model and shows the management services component, indicating those areas that the TME 10 Framework targets. Common Facilities User Interface Management Applications Hosts Data Source Managed Objects File System Printers Object Request Broker (OMG CORBA) Management Services Introduction to TME 10 Object Services (OMG) Policy Customization Scheduling Instance Manager Collections CORBA 1.1 Non-object Interface Object Interface The systems management application domain is a vertical application market with specialized requirements. This differs from the work OMG is performing at the ORB and Object Services level, which is common across most application spaces. TME 10 specifically focuses on managing policy-driven objects. This management includes the mechanisms and facilities that enable the establishment and enforcement of policy on these objects. The Object Management Group (OMG) is a non-profit international association of more than 300 companies. Its goal is to define an Introduction to TME 10 ADE 1 7

20 CORBA 1.1 architectural object framework through a series of detailed interface specifications. OMG s CORBA specification introduces the Interface Definition Language (IDL) and the concepts of an object request broker (ORB) and basic object adaptor (BOA). The ORB and BOA provide a mechanism for invoking objects and returning results to requestors. The CORBA 1.1 Specification The CORBA 1.1 specification presents an open system of service requestors and service providers in which the requestors are isolated from the providers. Requests are initiated without regard to the location or implementation of the service provider. The CORBA 1.1 specification specifies interfaces to a set of low-level object services. It does not, however, specify implementation, security, or installation. Nor does it offer a means for multi-vendor ORB inter-operability or C++ language bindings. The architecture uses three concepts to achieve the integration of a wide variety of object services in many different languages and systems: Object encapsulation The object providing a requested service does so within its own context, which means that each object has the ability to respond differently to the same request. Thus, two different objects can support the same interface and each can maintain a different implementation of that interface. Complete service requestor/provider isolation Allows service requestors to make requests of a provider regardless of the provider location or implementation. A service request includes a service identifier (operation name), a provider identifier (object reference), and other optional data. Interface and implementation separation Interfaces are defined without regard to the way in which they are implemented. Within the CORBA 1.1 architecture, there are three primary components: the client, the object implementation, and the ORB/BOA. The client is the requestor of a service that an object implementation provides. The ORB delivers the request from the client to the object 1 8 Version 3.2

21 CORBA 1.1 implementation through the BOA. The object implementation then performs the requested service, and any return data is delivered back to the client. The client and the object implementation are isolated from each other. Neither has any knowledge of the other except through their interfaces to the ORB and BOA. Client requests are independent of the object implementation location and the programming language in which they are implemented. Furthermore, clients and object implementations are not capable of direct communication clients can only initiate requests and object implementations can only provide services at the request of a client. The following figure shows the steps involved when a client requests an operation of some object implementation. Introduction to TME 10 Clients Object Implementation (Server) Dynamic Invocation Interface Client Stub Direct ORB Interface Server Skeleton BOA Object Request Broker 2 Client Request Results 5 The ORB delivers the request to the BOA, which activates the process under which the object implementation runs. The BOA then invokes the method associated with the request by way of the server skeleton. When the method is finished, the BOA manages the termination of the method and coordinates the return of any results to the client. Alternately, if a request is unknown until run-time, the Dynamic Introduction to TME 10 ADE 1 9

22 Scalability Scalability Invocation Interface (DII) is used to build a request used in place of a client stub linked at compile time. To meet the needs of customers with very large and geographically dispersed networks, a major focus of TME 10 is to significantly expand the scalability parameters of traditional management tools and techniques. TME 10 enables an installation to be logically broken down into a series of loosely connected TMRs, each with its own server for managing local clients. The result is multiple TME 10 servers that can coordinate activities across the network and permit remote site management and operation. One-way and Two-way Connections Selectively connecting TMRs enables senior administrative staff members to control the scope and effect of local configuration changes. It also facilitates centralized management and propagation of new policy rules, configurations, and authorization changes to remote sites. TMR inter-region connections are directed, which means that they are not necessarily symmetric with respect to the two connected TMRs. Connections can be either one-way or two-way. In a two-way connection, each of the TMRs in the connection is aware of the existence of the other, and each exchanges information about local resources. In a one-way connection, only one TMR has knowledge of the other. In this case, the first TMR receives information about the resources in the second TMR. However, the second TMR doesn t receive any 1 10 Version 3.2

23 B Scalability information about the resources in the first, making it impossible to view or manage resources in the second. A D B A D Introduction to TME 10 C C. A: one-way B: two-way Figure A of this diagram illustrates a TMR configuration containing one-way connections. In this configuration, TMR A acts as a central administration site for TMRs B, C and D. Such configurations are useful in management environments with the following characteristics: A central site is responsible for administering several remote sites. None of the remote sites have any need to manage resources at the central site or at other remote sites. Each remote site can have its own local Tivoli administrator who is responsible for managing local resources, although doing so is not a requirement. If, for example, the network link between TMR A and TMR D fails, it would be advantageous to have a Tivoli administrator local to TMR D. The local Tivoli administrator could then continue administering the TMR D until the connection is again available. This configuration is useful for any situation in which a central management authority must maintain control over one or more other management entities. The division between these management entities can be geographical (such as an Austin Region and a Dallas Region), or it may be logical (such as a marketing region and an engineering region). Introduction to TME 10 ADE 1 11

24 Scalability Figure B of the diagram illustrates a TMR configuration consisting of two-way connections. In this configuration all of the TMRs act as peers, each capable of managing resources in all of the others. Such configurations are useful in management environments with the following characteristics: A very large local area network is to be managed using TME 10. There is no single identifiable central management point. There is not a set of obvious logical entities into which the network should be partitioned. In such cases, the network can be broken up into multiple TMRs (along sub-net boundaries for example). These TMRs can then be interconnected with TME 10 administrators defined in any TMR that is capable of managing other TMR resources. The connection permutations are highly flexible. They can be tailored to an individual company s needs and can include one- and two-way connections in the same installation. It is important to note that TMR connections do not represent hierarchical relationships. A hierarchical connection is illustrated in Figure A of the following diagram: A A C B D B C D A: hierarchical connection (not supported) B: TME 10 representation of a hierarchy 1 12 Version 3.2

25 Scalability This configuration is not supported. If it were supported, TMR A would be able to manage resources in TMR C because they are connected. TMR A would also be able to manage resources in TMRs B and D because TMR C is connected to these two TMRs. TMR connections, however, are flat and can best be thought of as directed graphs. A connection as shown in Figure A of the diagram would only allow TMR A to manage resources in TMR C, but it would have no knowledge of resources in TMRs B and D. Figure B depicts the proper configuration for the hierarchical TMR management depicted in Figure B. The process of connecting TMRs is completely separate from the installation process for each TMR. TMRs can be connected immediately after they are installed, or the Tivoli administrator can connect TMRs at a later time. Also, machines can be added to an existing TMR or removed from one TMR and added to another. Finally, TMR boundaries and connections are independent of any other types of configurations in place, such as NIS domains, Kerberos Realms, and DCE cells. TMRs are not presented on the user interface and do not affect the way resources are grouped and managed. It is likely, however, that the same decision-making process that results in other configuration choices will apply to TMRs as well. Introduction to TME 10 Name Registry Within TME 10, most objects can be divided into two categories: distinguished objects associated with the platform and other objects typically associated with an application that model some system resource. A distinguished object is usually a unique object with a well-known name. Distinguished objects are frequently used as service providers (the notification registry or the scheduler for example). Resources are instances of TME 10 classes that are generally used to represent some system resource. Usually there is more than one instance of a resource type. Examples of resources include TME 10 administrators, managed nodes, profile managers, and so forth. Introduction to TME 10 ADE 1 13

26 Scalability Application methods and external command line interface (CLI) programs require access to a service that maps user-friendly names to object references. Such a service is often referred to as a directory service because it provides a means for simple lookup and referencing of resources in a structured manner. The Tivoli Name Registry (TNR) is the only service responsible for registering object names and for looking up the associated object reference upon request. As a name registry, it is the focal point for the prevention of name-space conflict. As a lookup service, it provides a portable and efficient means for determining the object reference of a named resource. The TNR is also a single point from which applications can quickly and efficiently generate lists of resources such as Available Machines. Finally, the TNR functions as the overseer of names for an entire TMR. As such, it is the focal point for exchanging information about known resources when multiple management regions are connected. When a TMR is initially installed, the TNR is created. The user-friendly names are then registered with their associated object references for the local distinguished objects. As additional resource types (such as policy regions, TME 10 administrators, and profile managers) are created they too are registered with the TNR. When an application is installed, new resource type names are also registered with the TNR. When instances of these resource types are created, the specified names with the new object references are registered under the appropriate resource types. This information within the TNR is stored for use in subsequent lookup and retrieval operations. When an instance of a resource is deleted, the entry in the TNR is removed. A set of directory service functions in the application services run-time library provide a simple interface to the operations of the name registry. By using the name registry in this manner, applications have a single and efficient service with which to consult when creating, looking up, and deleting resources Version 3.2

27 Inter-region Resource Exchange Scalability TMRs and the name registry are closely related. When two TMRs are connected to each other in a two-way connection, the TNR in each region exchanges information with the other about registered resources. For one-way TMR connections, the information is passed only from the region being connected to the one initiating the connection request. The result of such resource exchanges is that an application must have access to all the known resources in all connected TMRs. This information is obtained solely from information contained within the local TMR. This resource exchange enables the generation of lists and lookup of object references for named instances of a resource. These lists can be generated and look-ups performed without the requirement of knowing in which TMR the resource is actually located. Additionally, administrator requests that have such requirements can be managed without issuing lookup operations to TNRs in remote TMRs. The caching of global resource information in each TNR that is periodically updated from one or more remote TMRs is quite advantageous. It enables an administrator to query and initiate requests to many distributed resources solely from information contained in the local TMR. Network problems and resource availability in remote TMRs that prevent immediate action can be scheduled to be retried later. Introduction to TME 10 TMRs and the Administrator s Desktop As previously mentioned, TMRs are logical abstractions and have no particular correlation to network topology, Kerberos realms, or DCE cells. Rather, they are simply a collection of client machines for whom a designated TME 10 server has been identified. Multiple TMRs are key components of the TME 10 design and they enable the distribution of management responsibility to multiple servers. TMR boundaries and associations are not presented in the Administrator s Desktop. Instead, an administrator has delegated responsibility for the resources in one or more policy regions. Introduction to TME 10 ADE 1 15

28 Scalability Policy regions contain logically related resources (all the machines in R&D for example) for which a similar policy is desired. Resources in a policy region may be located in one or more TMRs, but this is a detail with which no one but the senior administrator need be concerned. The following figure shows the relationship of the Administrator s Desktop to a policy region and the resources contained within it to the underlying TMR organization. TMR A 4 TMR B In this figure, an administrator initiates an operation from the Administrator s Desktop for multiple machines contained within the single policy region (step 1). This request is routed from the workstation in TMR A on which the management user interface is located to the TME 10 server for TMR A (step 2). The TME 10 server then routes the request in parallel to the clients in the local TMR (step 3). Additionally, the TME 10 server determines that several of the requests are directed at resources in the remote TMR B. It therefore multiplexes these requests into a single inter-region request routed to the TME 10 server in TMR B (step 4) Version 3.2

29 Other Concepts for the TME 10 Framework This remote TME 10 server then simultaneously routes requests to the appropriate clients in remote TMR B (step 5). The TMR boundaries and server routing are all transparent to the administrator performing the operation. As the managed resources increase in number and geographic separation the number of TMRs, each with its own server, grows as well. As a result, an administrator who has been delegated the authority to manage several policy regions may be performing operations across multiple TMRs. Some of these operations might occur over one-way connection, while others occur over two-way connections. Regardless of the number of TMRs or the way they are connected, all operations from the Administrator s Desktop behave as local operations from the administrator s perspective. Furthermore, drag and drop operations from one policy region to another function as if all the associated resources are local. Introduction to TME 10 Other Concepts for the TME 10 Framework This section provides a brief, high-level introduction to several significant concepts that are part of the TME 10 Framework and extend across all TME 10 applications. These concepts are important because they have an overarching influence on how data is modeled, organized, and managed with the TME 10. These concepts are: Managed resources Policies and policy regions Profiles and profile managers Managed Resources TME 10 uses object technology to model real-world resources. In the context of TME 10, resources are TME representations of elements in a computing enterprise. They may be things such as computers or they may be a set of rules that governs a system or set of systems. Resources that are subject to certain sets of rules within TME 10 are called managed resources. The predefined rules that govern them are called policies. Introduction to TME 10 ADE 1 17

30 Other Concepts for the TME 10 Framework Managed resources provide a model of the physical resources to be managed by TME 10 applications. In addition, they can abstract away platform-specific characteristics that present problems for portability and interoperability. These resources provide a basis application users or developers can depend and build on as they implement applications that manage these resources on the network. Key point: The concept of managed resources is an overarching metaphor within TME 10. This concept combines with the concepts of policies and policy regions. Policies and Policy Regions A policy is a set of rules that is applied to managed resources. Policy is used to: Control the default values of newly-created resources (default policy) Maintain guidelines or limits when administrators modify or operate on resources (validation policy) A specific rule in a policy is a policy method. A default policy method supplies a constant value or runs a shell script or program that generates a value. A validation policy method runs a program or script to verify that the values are within the limits set by the administrator. An example of a TME 10 policy is a rule requiring user login names to be 8 characters or less. The administrator can create a script that uses the full user name to construct a login name (default policy) and create a validation script to check the length of a login name (validation policy). Policy regions are containers for managed resources that use the same set of policies. Each policy region represents a collection that is subject to common policies. Policy regions enable administrators to model how they want to organize and manage the data in their computing environment. Policy regions help organize the managed resources in the desktop and are used to define administrator access to these resources Version 3.2

31 Profiles and Profile Managers Other Concepts for the TME 10 Framework Profiles and profile managers make up the configuration management facility in TME 10. These two are used together to organize, create, and distribute information to remote systems. A profile is a collection of information that corresponds to a system resource. It contains information specific to a certain application and a certain profile type. A profile is stored centrally in a profile database and can be distributed to numerous locations. For example, in the TME 10 User Administration product, a user profile contains information such as user name, user ID, and user group. A profile manager provides a place to create and organize groups of profiles and link recipients to them. Introduction to TME 10 Introduction to TME 10 ADE 1 19

32 Other Concepts for the TME 10 Framework 1 20 Version 3.2

33 2 2Framework Services TME 10 ADE provides three basic sets of services for developing your application: Framework services Application services Desktop services This chapter gives an overview of the framework services and how to use them as you develop your application. For more information about specific services, see the TME 10 ADE Framework Services manual. Framework Services Introduction to Framework Services TME 10 uses a distributed object environment for its architectural framework. It uses object-oriented technology to model information and the methods that operate on that information. The objects communicate with each other by means of a request broker. These three the distributed environment, object-oriented technology, and the request broker form the backbone of the TME 10 Framework. Because it is object-based, the TME 10 Framework is a powerful and flexible architecture. It provides support for encapsulating methods and data within objects, which hides many of the implementation details from applications. Many types of data, methods, and hardware dependencies can be incorporated, and the framework provides the communication between them. Introduction to TME 10 ADE 2 1

34 TME 10 Object Request Broker (ORB) The Framework services provide basic object specification, creation, interaction, and method invocation services for TME 10 management applications. These services are built into the framework runtime. Tivoli has added services to this backbone or framework, so applications can plug in to this framework and use these core services. This chapter describes the elements in this backbone and the services it provides: The Object Request Broker (ORB) Communication between objects Databases, or persistent storage TEIDL The TME 10 ORB implementation is the main component of the run-time framework. It consists of several components including an object request broker, authorization service, object location service, and object adapter. The TME 10 ORB is implemented as a multi-threaded process that runs on each TME 10 client within a TMR. The TME 10 ORB also provides other services, including security and dynamic implementation inheritance resolution. TME 10 Object Request Broker (ORB) CORBA 1.1 only specifies the architecture of the ORB model. It specifies the provision of the ORB interfaces but not the ORB implementation. The ORB could, for example, be implemented as part of the operating system or as a stand-alone process. The TME 10 Framework provides a server-based implementation of a CORBA 1.1 ORB and basic object adaptor (BOA). It also provides related object, management, and desktop services and includes an implementation of the APIs adopted by X/Open for a systems management framework. The TME 10 object dispatcher (oserv) is the main component of the framework runtime. It is implemented as a single multi-threaded process and runs on each TME client within a TMR and on the TME 10 server for that TMR. The object dispatcher consists of an ORB, the 2 2 Version 3.2

35 Communication between Objects BOA, and related services. The object dispatcher running on the TME 10 server provides additional services, including security and implementation inheritance resolution. The TME 10 ORB is a continually running program, separate from the operating system. The TME 10 ORB communicates with both the server and the client through separate stubs and skeletons via an inter-process communication facility. A secure remote procedure call (RPC) used to invoke operations on remote objects provides both principal authentication and authorization. The framework services support all the major CORBA 1.1 components: An ORB A BOA An extended IDL compiler with both ANSI C and Bourne shell language bindings An interface repository The interfaces required for a Dynamic Invocation Interface (DII) Framework Services Communication between Objects The object dispatcher (oserv) provides communication between objects in the TME 10. It runs on all TME 10 systems, both clients and servers. The dispatcher on the TME 10 server provides additional services that client dispatchers do not. These include additional security and authorization, inheritance resolution, and inter-region communication. The TME 10 ORB uses a secure RPC service layered on top of TCP. This provides secure peer-to-peer communication between ORBs when an operation is invoked on a remote object. The secure RPC service is layered on top of TCP/IP, using either domain sockets or the TLI (transport layer interface). An application is never aware of the particular protocol in use; it just invokes the operation on an object by calling the client stub (produced by the TEIDL compiler) or using the dynamic invocation interface to build a request at runtime. Introduction to TME 10 ADE 2 3

36 Communication between Objects The following figure depicts the interaction between two ORBs when an object on one machine invokes an operation on an object on a remote machine: TMR Server DB DB ORB ORB Object 1 Object 2 DB When a method of object 1 invokes the client stub of a method of object 2, a message is sent to ORB 1. The message specifies the method, object, and arguments of the request (step 1). ORB 1 communicates with the TME 10 server for the TMR to determine whether the principal is authorized to invoke the operation on object 2 (step 2). If the principal is authorized to invoke the operation, the server also determines the location of object 2 and resolves any implementation inheritance as necessary. This information is then returned to ORB 1 in a cryptographically sealed credentials package (step 3). ORB 1 then forwards the request to ORB 2 (step 4), which in turn invokes the desired method of object 2 (step 5). When the method completes, the results are passed back to ORB 2 (step 6), which returns them to ORB 1 (step 7). Finally, the results are delivered to the invoking object (step 8). 2 4 Version 3.2

37 Persistent Storage Persistent Storage TME 10 provides several different data storage implementations. An application can choose the storage implementation most suitable for its data and the work being done on it. TME 10 stores object information in an internal, distributed, object-oriented database. The database stores object information in a physical location. This means that if the process operating on the object is destroyed, the object is still intact. There is also persistent storage for object attributes. Distributed transaction services, described in Transactions Service on page 2-9, make sure that all modifications to the database occur. Database commands are included to do consistency checks on the database and do any restoration it might need. Besides providing its own database, TME 10 also provides an object-oriented interface to third-party relational database management systems (RDBMSs). Called the RDBMS Interface Module (RIM), these APIs enable applications to store data in RDBMSs (such as Sybase, Informix, and DB2), instead of in the TME 10 database. Storing application data in these types of databases enables you to use their query, reporting, and SQL capabilities. It also means that data from one application can be visible to other applications. Framework Services Tivoli Extended IDL (TEIDL) The purpose of IDL is to provide a standard for defining interfaces that client objects call and object implementations provide. It does not, however, provide a standard for specifying object implementation, installation, or initialization details. As a result, when you define your interface in IDL, you are still left with the task of providing not only method implementation, but a program that generates and installs the appropriate object(s) into the environment. The details of such programs can be tedious and error prone. To ease the implementation and installation aspects of CORBA-based program development, Tivoli provides an IDL compiler. The compiler also Introduction to TME 10 ADE 2 5

38 Tivoli Extended IDL (TEIDL) supports extensions for the specification of implementation details (including security), installation, and initialization. These extensions are provided in a parallel but separate language called Tivoli Extended IDL (TEIDL). TEIDL is a proper super-set of OMG IDL and it is fully upward compatible. It facilitates a single specification for application objects with either ANSI C or shell language bindings. TEIDL supports the details associated with the definition of the object interface, implementation, and installation with specific support for the following: Implementation inheritance from multiple processes across the network Instantiable class, abstract class, meta-class, and mix-in class specification Distributed security model with the ability to a set per-method/per-object Access Control List (ACL). (See the Framework Services Manual for information about ACLs.) A rich set of method activation policies including shared/unshared server, external, and multi-threaded Initialization and installation features to automate application installation into a live running system Compiler option for strict OMG/CORBA compliance The compiler generates the framework run-time machinery for object implementation, installation, initialization, and start-up. Thus, the developer can focus on writing the method implementations while the compiler generates the code for the following: Communicating with the TME 10 ORB Managing method activation and execution models Security Persistence The TEIDL back-end supports both an ANSI C code generator that is CORBA compliant as well as a Bourne shell code generator. Both back-ends generate the following: 2 6 Version 3.2

39 Tivoli Extended IDL (TEIDL) Client and server stubs Public and private header files Configuration Installation script (shown in the next diagram) Support for Java language bindings is planned for a future release. Framework Services Introduction to TME 10 ADE 2 7

40 Tivoli Extended IDL (TEIDL) t_<pfx1>_imp.h TME private header <pfx1>_imp.h private header t_<pfx2>_meth.c TME meth templates <pfx2>_meth.c meth templates t_<pfx1>.h TME public header <pfx1>.h public header <pfx1>.cfg install script <pfx1> ist.tar install tar file Developer interface implementation installation program TEIDL <pfx1> ir.tar IR tar file <pfx1>_aux.c auxiliary source Key: pfx1: prefix of input file name pfx2: prefix of input file name or program name pfx3: program name <pfx1>_aux.h auxiliary header <pfx1>_defs.h defines header t_<pfx1>_imp.c t_<pfx2>_skel.c <pfx2>_skel.c <pfx3>.c TME private src TME skeleton liner skeleton src main program <pfx1>_imp.c <pfx1>_stub.c t_<pfx1>_stub.c private src stub src TME stub wrapper 2 8 Version 3.2

41 Transactions Service Transactions Service The TME 10 Framework provides features to make it easier to write distributed applications. Unfortunately, the distributed nature of these applications compounds many of the common problems programmers face when designing software, for example: The management of shared state The management of persistent data In some environments, shared state has been implemented using a persistent data store. However, errors in programming and a lack of system resources frequently leave both the persistent store and system resources in an inconsistent state. Transaction Hierarchies TME 10 supports multi-threaded methods, and thus, shared state can be embedded in process memory. Applications that take advantage of this model can reduce their reliance on the object database for inter-method communication. However, a multi-threaded model does not improve application reliability or data consistency. A distributed, nested transaction service is provided to enable applications to avoid data consistency errors. Transactions can provide you with a rich set of tools and interfaces that are different from those typically available. This is especially true when you use them together with the various method execution models, a CORBA-compliant IDL interface compiler, and distributed exceptions. Transactions are not a new concept to programming. Traditionally, transaction models have been provided to group several distinct operations into a single, atomic operation. Nested transaction models provide a way to combine one transaction with many others. The nesting of the various transactions imply an order, or hierarchy, to the transactions and defines the dependencies between them. The addition of the term distributed suggests the obvious: transactions that span multiple processes, programs, and machines. Framework Services Introduction to TME 10 ADE 2 9

42 Transactions Service The nested transaction model is a natural fit for the way applications are written using the TME 10 Framework. Each method can run atomically, dependent upon or irrespective of the success of any other methods it may invoke. Thus, you can control how transactions are used within your method invocation. Transactions and their associated state are maintained inside the TME 10 ORB. All accesses to the persistent object store from within a method are grouped into a single atomic operation without extra effort by the programmer. A component of the TME 10 ORB, the transaction manager, coordinates the two-phase commit protocol used TME 10 transactions. This protocol guarantees consistency and atomicity across multiple processes spanning multiple machines. The programmer has a limited role in the commit processing and can control the success or failure of a transaction through the use of error codes and exceptions. The transaction relationships of a set of methods can be represented graphically using a tree. In any transaction hierarchy, there is a single parent or root node from which all other transactions in that hierarchy descend. In the following figure, method A invokes methods B, C and D; method B invokes method E; and method D invokes methods F and G. A B C D E F G In this example, method A is the direct parent of the invocation of methods B, C, and D. It is also an indirect parent of methods E, F, and G. In the TME 10 nested transaction model, each method can run as a transaction. Relationships between the transactions are determined 2 10 Version 3.2

43 Transactions Service when new methods are invoked with the invoking method as the parent and the invoked method as a child. The child method runs as a sub-transaction of the parent s transaction. Any methods spawned by a child method may be in the same transaction hierarchy. In this example, the transaction associated with method A is an ancestor of methods E, F, and G as well as B, C, and D. In the simplest form, if method A encounters an error, it can exit by throwing an exception. Consequently, all object database operations made by methods B, C, D, E, F, and G (as well as A) will be automatically undone by the transaction manager. This rollback occurs regardless of whether B, C, D, E, F, and G were successful. Transaction Types The previous example is a simple depiction of how transactions can be grouped. The applications programmer can create much more complex transaction hierarchies as dictated by the application problem space. A method is invoked using one of the following transaction types: No transaction Top-level transaction Sub-transaction Revocable sub-transaction A method that does not run as a transaction has exactly the same semantics as methods in a non-transaction-oriented environment. The method runs without any of the data consistency protection provided through the use of transactions. A top-level transaction is the root of a transaction hierarchy. When a method runs as a top-level transaction, it has control over whether its changes and any of its sub-transactions are committed or aborted. A method invoked as a sub-transaction means that the invoking method requires that the invoked method must succeed for it to succeed. Finally, in the case where a method is run as a revocable sub-transaction, the invoking method does not depend upon the success of the invoked method. It can choose to succeed or fail regardless of the success or failure of the invoked method. Framework Services Introduction to TME 10 ADE 2 11

44 Transactions Service Two-Phase Commit Two-phase commit refers to the protocol that transaction monitors use to commit transactions.this protocol guarantees that a set of operations are atomically committed. In simple terms, the protocol consists of two phases: the prepare and the commit (sometimes referred to as the complete phase). A transaction coordinator is used to move the sub-transactions through the specific phases and uses other messages to detect errors and early aborts. The use of the transaction coordinator eliminates the requirement of applications programmers to manage two-phase processing. The TME 10 ORB functions as a transaction manager, coordinator, persistence storage manager, and transaction logger. Generally, applications programmers are merely required to provide transaction types in calls, make calls to lock data, change data, and commit or abort methods. Committing transactions is easy: simply returning from the method implementation successfully causes the transaction to be committed. There is no guarantee, however, that it will commit successfully, since a parent or child transaction may still abort. Aborting a transaction is also as easy: if the method implementation throws an exception, the method and its corresponding transaction are aborted. Transaction Events Many methods merely manipulate attribute data: transaction aborts automatically back out any changes to the object databases made on behalf of the transaction. It is common, however, for some of the data associated with an object to reside outside of the object. Modifications to system files and other configuration files, for example, also need to be backed out if a method aborts. Methods that attempt to commit might still abort due to the effects of other related sub-transactions. Undo operations cannot, therefore, be performed within the context of the individual method invocation. Instead, an application can register interest in abort transaction events and provide a callback to be called if the event takes place Version 3.2

45 Transactions Service Consider the example of a new user being added to the system. Somewhere during this operation a method physically adds a line to the /etc/passwd file. If the add user operation must abort after the password file has been modified, the old contents of the password file must be restored. Undo operations are provided by the transaction implementation using abort transaction events. An application programmer can log undo operations (such as methods and data) with the transaction manager. Then, in the case where the transaction aborts, the method is automatically invoked with the data as an argument. When the transaction is committed, the logged undo operation is discarded. In addition to backing out changes, there is a class of methods that need to be involved in the two-phase commit protocol. An example of this is when a method interacts with an external database manager such as Sybase. Such a method can create foreign transactions in the external database context. To enable these foreign transactions to be prepared, committed, or aborted in sync with TME 10 transactions, methods may register for transaction events. If a method needs to be notified when a transaction is prepared, committed, or aborted, it can register event methods with the transaction manager. When the transaction changes its state, the event method is called. If it returns successfully, the transaction moves to the next state. The event method not only is notified, but it can even effect the outcome of the transaction in some situations. Currently, there are three types of transaction events: Framework Services Event Type Prepare Description When the transaction is sent a prepare message from the transaction coordinator, any prepare event methods are invoked. Prepare event methods must perform any local processing necessary to prepare the transaction. Once a transaction claims to be prepared, only the transaction coordinator can choose to abort the transaction. If the event methods return successful, the transaction is prepared. If any return an error, the transaction will be aborted. Introduction to TME 10 ADE 2 13

46 Concurrency and Locking Service Event Type Commit Abort Description When the transaction is sent a commit message from the transaction coordinator, any commit event methods are invoked. They will be called repeatedly until they all return successful. After the commit message is received, any internal data associated with the transaction can be released. If the transaction aborts, all of the abort event methods are invoked. They must do whatever is necessary to undo any work performed within the transaction context. Concurrency and Locking Service When writing distributed, multi-threaded applications, guaranteeing consistency of the datastore becomes complex. When multiple processes or multiple threads within a process are modifying the same data, the programmer must address consistency issues. Generally, access to data must be serialized either by the programmer using various locking mechanisms or by the underlying subsystems. There are many solutions to these concurrency issues. The framework services provide a variety of locking schemes with a varying degree of control. This solution enables you to choose which is optimal to use in each specific application. The term protection domain describes the bounds of an operation and the data that needs to be serialized or protected from other threads of execution. A thread of execution may be a separate process (in the UNIX paradigm) or a separate thread in a single process (the POSIX pthreads paradigm). The framework services support both paradigms. Using objects is another way for grouping a set of data into a protection domain. In some environments, this is sufficient; in TME 10, however, it is not. TME 10 objects provide coarse control and several methods may be active at the same time for the same object on behalf of different administrators. All objects exhibit state. This state might be completely persistent, in which case it is represented by attributes in the object database. An object might have other state that might or might not be persistent Version 3.2

47 Concurrency and Locking Service An example of other persistent state is entries in the /etc/machines file. An example of non-persistent state might be the current list of machines that are down and being maintained in an in-memory list. When a method changes any of this state, it must ensure that it is the only method changing the state at that point in time. There are many locking mechanisms provided by the framework services for protecting object state. These mechanisms can all be divided into one of two categories: critical section locks and transaction duration locks. Critical Section Locking A critical section lock is used by a program to protect access to data structures and critical code sections within its address space. These locks are used by multi-threaded methods and programs to serialize access to data and operations. Doing so ensures that internal state or mechanisms are not corrupted by multiple threads within the process. Usually, the state that is being protected is global in the process address space (not on the stack), although there are cases when this might not always be true. The framework services support the following critical section lock types: Simple mutexes simple, fast, efficient locking mechanism Friendly mutexes reference counting locks for multiple entry points Read/write locks shared/exclusive locking providing reader/writer semantics Semaphores message, mutual exclusion, and synchronization Critical section locks are generally held for a very short time, acquired and released in a single process, and terminate when a method exits. Framework Services Transaction Duration Locking Transaction duration locks are used to serialize access to data and operations. The lock is held for the duration of the entire transaction and across method and address space boundaries. The locks are not released until the transaction commits or aborts. An application uses transaction duration locks when trying to protect data outside its Introduction to TME 10 ADE 2 15

48 Security Service Security Service address space (such as attributes in the object database) or to serialize a set of operations. TME 10 applications acquire transaction duration locks using the transaction pseudo object. This object is provided to implementations as a distinguished argument via the special Tivoli implementation liners. The security service is one of the most critical services to systems management applications. A distributed application that can modify system configuration files on mission-critical machines is a powerful tool that significantly enhances productivity. If, however, this capability is not secure, it will never be used. The framework services support a roles-based security using TEIDL. This security service satisfies the following security concerns: Addresses both authentication and authorization issues Security model and API is independent of operating system specifics (setuid root) Facilitate effective non-intrusive implementations Provides secure, encrypted communication between objects Supports delegation of credentials (distributed vs. client/server) Addresses mismatch between object boundaries and operating system security envelopes Allows cooperation between mutually suspicious objects Authentication and Authorization The concept of application security consists of two primary components: The article you are trying to protect Those things that offer an actual threat Security schemes protect data against unauthorized destruction, interception, or modification. Communication between programs and 2 16 Version 3.2

49 Security Service users on a network opens a window of opportunity for persons who break into networks and are intent on doing damage. Intruders and vandals typically try to circumvent controls for authentication and authorization. Authentication verifies the identity of a principal. Vandals may attempt to convince the network, through stealth for example, that they are something (a program) or someone (a user) that they are not. A fake identity on the network allows a vandal access to data or resources that are normally unavailable. A password that a user must enter when logging into a system is an example of an authentication mechanism. Kerberos is an example of a more secure authentication mechanism that helps to ensure that programs and users are accurately identified. TME 10 can support either mechanism. Authorization verifies that an identified principal has sufficient privilege to perform a specific operation. Each method has an associated set of roles that control access to the method. For any operation on an object, the authorization process verifies that the principal has at least one of the roles required by the method. If so, the attempt to run an operation is permitted. If not, it is refused. Framework Services Kerberos Kerberos is a network authentication service developed for M.I.T. s Project Athena. Kerberos adds an extra layer of security to networks by registering users and services as Kerberos principals. A Kerberos principal is a service or user that is registered in the Kerberos database. With Kerberos, a service on one machine in a network can talk to a service on another machine in the network. This communication is secure because the identity of the service or user has been previously authenticated. Kerberos makes it more difficult for users and services to masquerade as other users or services by using the Data Encryption Standard (DES) algorithm for encrypting passwords. Each Kerberos principal has a principal name. Principal names consist of three parts: A principal name Introduction to TME 10 ADE 2 17

50 Security Service An optional instance name A realm name A realm is a set of machines that share the same Kerberos database. For example, a principal name could describe the authorization role the user has in a particular realm, such as jose.user@realm1 for a user principal. A principal name can also describe the location of a service on a machine, for example ftp.machine@realm2 for a service principal. When a user logs in as a Kerberos principal, Kerberos assigns the user a ticket. Each ticket has a ticket lifetime, which determines the length of time the ticket is valid. The lifetime is assigned in five-minute increments. At the end of the ticket lifetime, the ticket expires. Kerberos authentication fails for a user whose ticket has expired. Each Kerberos principal also has a Kerberos principal password that is assigned when the principal is registered in the Kerberos database. Kerberos principals have one password per Kerberos realm for all machines in the realm. When a Kerberos principal attempts to access or change the contents of a realm, the principal must enter the Kerberos master password. Operating System Privileges The operating system privileges with which a method executes when an operation is invoked on an object is also related to security. When TME 10 executes a method, it will normally execute that method by default with the lowest available privileges. On a UNIX system, this is typically the user nobody. By default, TME 10 also uses this same ID number as the executing method s group ID. For many system management operations, many operations must execute with a higher privilege in order to succeed. On typical UNIX systems, for example, the /etc/machines file is owned by root and has its permissions set to 644. Any method that modifies this file must run as the user root. TME 10 manages this necessity with its setid feature, which is the TME 10 parallel to the UNIX setuid feature. A programmer sets a particular privilege for a method using TEIDL so that when the 2 18 Version 3.2

51 Security Service method is invoked, it runs as if a particular privileged user had invoked it. Object Groups To simplify security management, objects created in the TME 10 are assigned as members of one or more object groups. An object group is a named logical entity to which one or more objects belong and over which an administrator is granted one or more roles. The result is an access matrix in which a role for a principal can be added for many resources in one step. The use of object groups simplifies role management by substantially reducing the number of entries that must be changed when a principal s credentials are modified. An operation initiated on one object may cascade and invoke an operation on another object that may be in a different object group. To manage such situations, the security service supports both the ability to delegate and acquire additional authorization. Machine Boundaries and Cascaded Operations Another security concern is the condition in which a cascaded operation crosses machine boundaries. In such cases, the first object acting as a server for a client now becomes a client of a second object on a remote machine, and so on. If one of the machines involved in a cascaded operation is not secure, the possibility of tampering with the credentials package must be considered. As a result, an application must be designed such that privileged methods only run on objects located on secure or trusted machines. Additionally, the underlying security service must be able to strip the credentials to the lowest level. Stripping credentials is necessary when a cascaded operation leaves an insecure machine and invokes an Framework Services Introduction to TME 10 ADE 2 19

52 Security Service operation on a secure machine. The following figure shows an example of cascaded operations: Machine A Machine B Machine C Object 2 Object 1 Object 3 Group 1 Group 2 Group 3 Object 4 In this example, a high-privilege method invoked on the first object cascades and invokes a method on the second object. This second object resides both on a different machine and in a different object group. The underlying security system in the framework must therefore provide two things: A mechanism to facilitate inter-object group operations. A typical example of such interoperability is the amplification of rights by combining the clients cascaded context with additional rights from a security server. The ability to strip any rights from the credentials package when the request to invoke an operation on subsequent objects is made. Such is the case when the third object invokes an operation on the fourth object, both of which reside on an insecure machine. The example scenario is common when applications are constructed from components supplied by different groups that are distributed around the network Version 3.2

53 Security Service Secure Method Invocation Although authentication and authorization are separate concepts, they are closely related. The identity of a program or user determines which operations it has permission to perform. False authorization and false authentication are serious breaches in network security. The protection provided by the TME 10 security service offers both fine-grained and hierarchical control: Fine-grained authorization can be controlled for each application and for each policy region Hierarchical delegated authority can be re-delegated to other TME 10 principals This provision enables TME 10 to support a secure service that is manageable in environments that might contain tens of thousands of objects. The provision is necessary because TME 10 methods call other methods to obtain data and perform operations on the system. Each operation invoked on an object represents a potential security hazard. TME 10 maintains a database of principal privileges and defines a simple means of controlling which principals have access to which methods. For authorization purposes, a TME principal is a TME 10 administrator or user with an entry in the TME 10 database of principals. If Kerberos is in use, the TME 10 principal is a Kerberos principal name. If Kerberos is not in use, the principal name has the format user@machinename. When an administrator or a user invokes an operation on an object, the TME 10 looks up the principal s name (of whichever form is appropriate) and associated roles in the TME 10 database. A TME 10 administrator is defined to have one or more roles over the objects in one or more object groups. These object groups typically, but not always, align with policy regions in which managed resources are grouped. Using TEIDL, an application programmer defines the acceptable roles for each operation of each interface. Administrators attempting to invoke an operation on some object must have the role required by the Framework Services Introduction to TME 10 ADE 2 21

54 Method Activation Policies method for the object group in which the object resides. If either one is missing or incorrect, an authorization exception is raised. Method Activation Policies Using OMG IDL, you specify only the interface to an object. Using TEIDL, however, you can also describe the implementation approach for an object. Doing so typically requires the specification of attributes, method types, and method grouping. The method or server type defines the execution style in which the method will be written and run. The framework services support the following method activation polices: Intrinsic fast, low-level, and built-in to the ORB Command uses helper process to manage stdin/stdout for shell scripts Server-per-method one process for each method Shared daemon multiple methods, one process for multiple objects, long running Unshared daemon multiple methods, each object has own process, long running External daemon that is, CORBA persistent server Multi-threaded any of the long running method activation policies can be multi-threaded A POSIX draft 6 pthreads interface is supported by TME 10, which enables the development of multi-threaded methods. Such methods use fewer processes on server and client machines and they are simpler to develop. This simplification is especially important for complex system administration tasks that often require process coordination, shared data, or state-machine implementations. The design and use of threaded methods also facilitates improved method performance. This increased performance will be especially true for future management platform releases that support true multi-processor machines and operating systems. Such systems when they are available from hardware vendors will 2 22 Version 3.2

55 Method Activation Policies support preemptive thread implementations and fully exploit the performance capability of multi-threaded methods. Server Types When you provide your object implementation, you must specify the server type and the execution style. TEIDL program constructs specify these characteristics. Server types can be specified as per method, daemon, or external daemon. The process under which a per-method server runs will terminate when the method completes the last task. Consider, as an example, a TEIDL program that executes methods A, B, and C that have each been defined and implemented as per-method servers. Each of those methods run as a separate server and each will run under a separate process. The fact that per-method servers terminate upon completion is important because you must weigh the advantages against the disadvantages associated with such servers. Per-method servers are flexible and easy to develop and manage, but they also consume a significant portion of available system resources every time a method is called. The process under which a daemon server runs does not terminate when the method completes the last task. The process continues until it is aborted or times out. A daemon server process can manage a large number of methods from the same process. This efficient management eliminates the overhead of starting a new process each time a method is invoked. Instead, the BOA starts a new process the first time it invokes such a method. Subsequent invocations of that method, or any other method within that server, will run under the same process. If a program executes methods A, B, and C, the methods can run as a single server under the same process. Processes that continue to run when the methods are not active, do consume some system resources. Therefore, a daemon server should only be specified when the methods grouped within are frequently invoked. Additionally, a daemon server might need a time-out Framework Services Introduction to TME 10 ADE 2 23

56 Method Activation Policies specification to prevent it from consuming system resources during long periods of inactivity. Server Execution Server execution styles can be specified as shared or unshared, and parallel or nonparallel through TEIDL. Both of these server execution variations are only valid for daemon servers. The execution style of per-method servers is predefined. A shared server accommodates more than one object. Consider the following example: A program executes methods A, B, and C. The server is specified as unshared. Two different objects, object 1 and object 2, share this program by way of TEIDL implementation inheritance. A client makes a call to object 1 and requests the operation associated with method A. Simultaneously, another client makes a call to object 2 and also requests the operation associated with method A. In the case of an unshared server, the BOA will start a process for object 1 and invoke method A. It will then start another process for object 2 and invoke method A a second time. Method A will then concurrently run in two separate processes, each as a daemon server. In the case of a shared server the BOA will start a process for object 1 and invoke method A. It will not, however, start a second process for object 2. It will instead either queue the request for object 2 or immediately invoke the method within the same process. The actual behavior depends on whether it is a parallel or non-parallel server. A parallel server allows multiple invocations of methods within the same process using execution threads to execute concurrently. As previously mentioned, the framework services support a POSIX draft 6 pthreads API that is implemented on top of a co-routine-based C threads package from CMU. In the previous example using a threaded server, the BOA invokes method A in the context of object 1 and object 2. Both invocations run under the same process. A non-parallel server will queue the second invocation and will begin execution when the first invocation is 2 24 Version 3.2

57 Method Activation Policies complete. A parallel server will create a new execution thread and begin executing method A immediately. Framework Services Introduction to TME 10 ADE 2 25

58 Method Activation Policies 2 26 Version 3.2

59 3 3Application Services TME 10 ADE provides three basic sets of services for developing your application: Framework services Application services Desktop services This chapter describes the application services and how to use them as you develop your application. Introduction to Application Services Application services provide the fundamental services for logically modeling or physically storing objects for management purposes. These services define the set of intrinsic operations that all policy-driven objects can inherit and implement. The set of services submitted by Tivoli to X/Open include an enabling set of core management services. These services promote the portability and interoperability of system management applications. The management services comprise three categories: A set of enabling services for managed objects A set of advanced application services A set of run-time services Application Services Introduction to TME 10 ADE 3 1

60 Enabling Services Managed objects provide a model of the physical resources that will be managed by applications developed using the Tivoli application services. They also remove platform specifics that make portability and interoperability problematic. Examples of this type of resource include machines, users on the network, and printers. These resources provide a basis upon which application developers can depend and build as they implement applications that manage these resources on the network. Administrators want to subject these managed objects to policy. These objects are the entities in a distributed computing environment that are being managed. In this context, managed objects are referred to as policy-driven objects, which are objects for which policy has been defined and whose behaviors are determined by these policies. Enabling Services The fundamental enabling services in the Tivoli X/Open submission are driven by the need to have a minimal set of common building blocks. These building blocks must enable developers to structure and organize systems management applications. These services include the following: A collection service for arbitrary grouping, navigation, and filtering A policy service for enforcement of end user-defined rules An instance management service for object creation, location, and persistence A customization service for enhancing and changing the configuration of applications Collection Service The collection service defines operations required to have two-way reference relationships between objects. It enables the resulting collections to be queried or have operations applied to the members of the collection. Objects within a collection are called members. In the collection relationship, collected objects know all collections of which they are 3 2 Version 3.2

61 Enabling Services members, and all collections know all objects collected in the collection. Each participant in the relationship maintains a set or list of the other participants object reference. An example of a collection is the users within a system who are members of the company volleyball team. Another example is all the users that receive mail regarding company marketing plans. Collections offer a way for system administrators to organize resources into logical groups. Because collections can refer to other collections, they can be organized into hierarchies. Further, because collections are groups of references to objects, an object can belong to any number of collections. Users of an application can organize their managed resources into a suitable hierarchy, and create multiple collections of those resources. A collection can be heterogeneous, meaning that it can collect objects of different types. Application developers can create a sub-class from collections that have as members a combination of machines, users, or other types of Application Services Introduction to TME 10 ADE 3 3

62 Enabling Services objects. Filtered and nested collections support methods that iterate over a set of members, performing operations on each member. Although a collection may be heterogeneous, you can invoke operations that iterate over a homogeneous subset of the collection. UNIX File System Root Directory Collections Machines etc usr bin Engineering Marketing system files bin users commands lib Chicago Office Atlanta Office Houston Office chuck neal North Office West Office This figure illustrates the common nature of collections and UNIX directories. Both collections and directories contain various types of items, including other collections and directories. You can think of a collection as a directory and an object as a file. The figure shows the Machines collection object as an example of an object that is a collection but not contained in a collection. In this way it is similar to the root directory of a file system. As shown in the figure, the Machines object contains the Engineering and Marketing objects that contain the machines maintained by these departments. In addition, a collection can contain either an object or a reference to an object, which is similar to the notion of symbolic links in a UNIX file system. 3 4 Version 3.2

63 Enabling Services The analogy of a UNIX file system is not exact, however, because you can remove a collection without deleting its members. In fact, you can remove the last collection to which an object belongs without deleting the object, although doing so orphans the object. Instance Management Service The instance management service provides much of the required infrastructure for objects to be logically associated with and managed by other objects. These objects support a common interface and they are subject to a set of common policies. The instance management service includes the library interface and zero or more object instances supporting the instance manager interface. The instance manager interface defines the fundamental operations that support the management of multiple instances of an object type. This support includes policy management and maintaining a record of the managed instances of the object type. The relationship between an instance and an associated instance manager is one-to-one. The application services, however, support several instance managers that manage objects of the same type, one for each TMR. Multiple instance managers are used for a variety of reasons, including scalability, availability and configuration control. An object that supports the library interface a library object maintains a list of all instances of instance manager objects within a TMR. In this way a library object serves as the common source of information about the known types of objects within a TMR. A library object also maintains information about each type of object managed by instance managers, including whether they have policies associated with them. Finally, as with instance managers, there is one library object per TMR. There is no explicit support for managing policy-driven objects at the ORB layer. However, it is useful at the application level to use traditional object-oriented concepts to manage the objects within the framework. The instance management service provides the structure necessary for designing objects to support system administration applications. The Application Services Introduction to TME 10 ADE 3 5

64 Enabling Services instance manager system encapsulates a series of client operations, and thus simplifies interaction with the policy-based mechanisms of system management applications. Applications are constructed from a set of standard object types that together constitute a general applications architecture. These standard object types are closely inter-related and are used to build objects for system management applications. The objects provided by a management application can be divided into one or more object types that may be managed by one or more instance managers. An object type is a set of objects that share a common interface. Each object of the same type is called an instance of the type. Within the systems management framework, object types are associated with a particular instance manager. The instance managers are registered with and stored in a library, which provides a central repository for system administration object information within a TMR. An instance manager can have references to one or more policy regions. In this case, the manager is said to represent a managed resource type. The policy default objects and policy validation objects associated with an instance manager are used by policy regions to encapsulate a set of management policies. They also support high-level operations that manage a particular object type. Policy default objects support operations to coordinate the creation of objects as well as to define the initial (default) values of the 3 6 Version 3.2

65 Enabling Services policy-driven object attributes. Policy validation objects support methods that validate initial values or changes to object attributes. LO (reference) (reference) IM 1 IM 2 IM p... PDO PDO Policy Default Object Instance Instance Instance (reference) PDO PDO Policy Valid. Object Policy Service LO=Library Object IM=Instance Manager Policies give administrators a way to customize applications to their specific needs. A policy is a rule that an administrator places on the system. A policy can determine, for example, which users belong to a group, which users have access to a particular machine, or where a user s home directory must reside. Policy makes it easier for administrators to customize applications by allowing administrators to make the applications reflect the way their systems are to be managed. Using policy, administrators can implement their own organization-specific rules for system management. Application Services Introduction to TME 10 ADE 3 7

66 Enabling Services Like any other set of rules, policy must be enforced to be effective. Policy regions enforce policy and associate specific policies with instances of policy-driven object types. A policy region is a special type of collection: it is a collection of policy-driven objects. Like collections, policy regions can be arranged hierarchically according to organization- and administrator-specific criteria. Furthermore, they can contain any set of managed objects as specified by an administrator. The policy service defines five interfaces related to policy and the management of policy. These interfaces relate to the establishment of policy regions, the objects within a policy region, the reporting of associated policy, and the definition of policies themselves. Policy regions are nested collections, which allows them to be grouped and managed in an organization that is natural to the administrator. The selection of members for a policy region is arbitrary, allowing policy regions to be used to model real-world organizations. For example, an administrator can create a policy region that represents the network resources belonging to the Engineering Department. Member objects of the policy region then follow policies governed by the Engineering Department. 3 8 Version 3.2

67 Enabling Services A policy region can also contain other policy region objects. A policy region object that is a member of another policy region is known as a subregion and may inherit its parents policies or specialize them. PDO PDO Instance Manager Policy Region Manager (reference) (reference) PDO Policy Default Object Region 1 Region 2 Region n... Policy Validation Object Subregions PO PO members This figure shows the object relationships between a policy region and its managed resources. There is a reference to an instance manager for each managed resource type. Instances of the managed resources are shown as members of the policy region. The enforced policies are shown separated into default and validation types. Customization Management Service The customization management service enables the administrator to extend the capabilities of an application. In this way applications can more comfortably suit the local organization-specific style of system management. The customization service enables the administrator to update the behavior of existing operations and to add new operations to existing interfaces through aggregation. The allowable customizations include Application Services Introduction to TME 10 ADE 3 9

68 Enabling Services the ability to customize existing operations and to add new operations to interfaces. After the customization, the new implementation is able to access the original one. This accessibility allows the customization to augment the original behavior, rather than replace it. Customization is possible using the language of choice. That is, many executable types can potentially be used for the implementation of custom methods. These might include shell scripts or compiled and interpreted languages. Traditionally, programmers produce customizable applications by building in customization features (for example, the application-defaults files in X). It is difficult, however, to anticipate all the possible customization requirements of administrators. Behavioral customizations are required to satisfy many system administration application requirements. The customization interfaces supported by the application services address the following concerns: Discretionary use of customization If a developer chooses to close an application and not allow customization or extensibility, none of the objects in the application will inherit the customization interface. Therefore, although this capability is generally available, it is enabled by the application developer rather than the environment. Limited ORB effect The definition of interfaces for extensibility that are inherited by objects enables individual ORB providers to implement the operations appropriate for their design and environment. Specifying interfaces for objects rather than as extensions to the ORB interfaces allows the defined operations to be implemented using ORB-specific repository interfaces. This keeps the addition of extensibility functionality from unnecessarily affecting an ORB implementation. Flexible security The customization service supports the extensibility of operations on objects rather than on a central repository. This support provides greater control over the extensibility of authorization and policy. Flexible configuration A large set of implementation and authorization strategies are available to developers and 3 10 Version 3.2

69 Advanced Application Services administrators. This availability is due to separating the administration of extensibility from the ability to have an object s behavior extended. These strategies range from centralized control to completely distributed control where each object can only extend itself. Encapsulation of customization It might be argued that a close following of object-oriented principles requires that objects completely encapsulate their own behavior. If they are to be extended, then the object itself should have the ability to do so. Coexistence with standards The OMG standard for Interface and Implementation Repositories does not standardize all the required operations. A system administration object model is not the place to specify interfaces for industry standard entities. If the standards are modified in the future to embrace extensibility concepts, then this object model will allow migration to those standards. Advanced Application Services The following advanced application services are supported: Managed nodes Scheduling service Notification service Managed Nodes Change and configuration management service A managed machine interface that is common across all platforms is available through a resource type called the managed node. When the management platform is installed on a set of machines, a managed node icon is displayed for each machine. Applications can integrate with this object, providing a machine-centric integration facility while freeing the managed node from any specific application ties. For example, the TME 10 Software Distribution application uses the file I/O operations of the managed node. Application Services Introduction to TME 10 ADE 3 11

70 Advanced Application Services The managed node provides services that can be used by many applications to perform the following tasks: Querying system resources Assisting installation of applications Providing basic machine management operations such as changing IP address or creating files and directories. Additionally, the managed node inherits operations from the customization interface so that it can extend its behavior by inheriting operations of new machine-centric applications. Likewise, the user interface can also be extended to include new dialogs and menus. Finally, the managed node acts as a collection that can be opened to display installed application-specific entries. Scheduling Service TME 10 application services support a task scheduling service to allow administrators to perform time-consuming or repetitive management tasks at scheduled times. These services enable administrators to perform activities during periods of low system use. They also allow the future scheduling of operations that are unable to complete due to a temporary outage or unavailability of network resources. The scheduler offers time and frequency-based scheduling (with at(1) and cron(1) semantics), yet is free from any operating system service or dependencies. The application services also provide an automatic retry facility that frees application code from the need to check for and handle down machines across the network. This retry facility is a practical requirement for tasks targeted at many systems. The schedule queue can be queried either programmatically or graphically from the management platform, altering job times and priorities as necessary. Finally, the scheduling service invokes scheduled methods with the roles of the requestor, thus preserving the global integrity of the distributed security model Version 3.2

71 Advanced Application Services Jobs A job is an administrator-defined activity that performs a specific duty. The actual job being performed is stored as a CORBA-defined Request Object. This object is executed at the specified time using the DII. Jobs can be added to the scheduler by any authorized administrator as long as the administrator also has the proper permission to execute the job being scheduled. Jobs that have the same execution time are executed in the order in which they were scheduled (FIFO). When a job is added to the scheduler, it is saved in the scheduler s persistent database. This ensures that the list of activities to be performed by the scheduler is persistent and survives machine reboots. The administrator who enters the job is listed as its owner until the job is edited by another administrator. Ownership of jobs is important for authorization and determines who is allowed to change the state of a job. Time-Based Scheduling A job can be scheduled to execute once at a given time. This feature is similar to the UNIX at command. The job is executed only once and must be rescheduled if it is to be executed again. The administrator can schedule a job at a time that has already passed. In such a case, the desktop will post a warning stating that the time has already passed and ask the administrator if he wants to re-enter the data or continue. If the administrator continues, the job will be executed immediately. Frequency-based Scheduling A job can be scheduled that executes at a regular frequency. This feature is similar to the UNIX cron command. The job is executed at a specified time and then is rescheduled to be executed again later. This can continue indefinitely or occur for an administrator-specified number of times. The administrator can set the repeat frequency to be an increment of a given number of minutes, hours, days, months, or years. Jobs scheduled to repeat at monthly Application Services Introduction to TME 10 ADE 3 13

72 Advanced Application Services intervals present a problem, because the number of days in a calendar month vary. To cope with this variable, the scheduler increments the time to the same day of the next month. If the next month does not have the same number of days, then the day will be set to the last day of the month. The scheduler keeps the originally scheduled date so that the event can be scheduled on the proper day for the appropriate months. Retry on Failure Scheduled jobs fail for various reasons, some of which might not be fatal and which are due to circumstances outside an administrator s control. A typical example of such a failure is an unavailable network. Such failures make it necessary to be able to retry jobs when they fail. Failure in this context means that a job can not be executed for a specific reason: it does not mean that a scheduled job is executing and dies due to an error. Once a job begins executing it is no longer the responsibility of the scheduler to monitor the job. If the job can not be executed, the scheduler can try to execute the job again later. When a job is scheduled, the administrator can specify whether it is to be retried until it succeeds or for a given number of tries for success, before it gives up. For example, a software distribution operation could be scheduled to start at midnight and retrieve every night at midnight until the operation is successful. For any subscribing machines that are unavailable at this time, the scheduler can automatically retry the operation to this subset of machines at some regular interval such as every hour until it succeeds. Alternately, it could try for a specified number of times, give up, and then report a failure after the specified number has been reached. Schedule Management Scheduled jobs can be browsed in the job queue and the status of completed jobs can be examined. After a job has been scheduled, the scheduling data can be edited at a later time Version 3.2

73 Advanced Application Services The job itself can not be edited; the method call and its arguments can not be changed. When a job is updated, it is rescheduled with the new information entered by the administrator. Because the job is rescheduled, it will be scheduled after all other jobs that have the same execution time. A job can be cancelled, which means it is removed from the queue entirely. Alternately, a time-based job can be disabled which means the job is left in the queue but will not be executed should its scheduled time arrive. Job Status Notification When the scheduler executes a job or encounters a condition that is unusual, the administrator is notified of the event. The following is a list of actions that cause the administrator to be sent a notification, if one was requested: A scheduled job is executed A scheduled job failed A scheduled job failed and is retried A job is edited, removed, or disabled by an administrator other than the one who originally scheduled it A job could not be executed within the specified time frame The administrator can also avoid notification entirely by not specifying any notification options. The following is a list of the different notification mechanisms supported by the scheduling service from which an administrator can choose to be notified: Posting a TME 10 notice to a specified notice group to one or more addresses Posting a status dialog to an administrator s desktop Posting to all active administrator s desktops Logging to a file Application Services Introduction to TME 10 ADE 3 15

74 Advanced Application Services Scheduling and Multiple TMRs There is one scheduling service per TMR within TME 10. Each scheduler has identical behavior but exists in a different location to service requests for clients of the local TMR. When a job is scheduled, it is scheduled relative to the time zone for the TMR. It is then stored in the scheduler database that is local to the region in which the request is made. Jobs are not restricted to executing in the local TMR. Consider the example in the following diagram: TMR Bedrock TMR Slatesville Barney Scheduler A Scheduler B Fred Betty Wilma Job Scheduled from Barney Job Scheduled from Fred Job Scheduled from Wilma In this example, an administrator is running the management user interface from machine Barney in the TMR Bedrock. From Barney, the administrator is able to schedule a job to execute on the machine Betty in the remote TMR Slatesville. As discussed in TMRs and the Administrator s Desktop on page 1-16, the administrator is not aware of the TMR boundaries. All inter-region operations are performed by the framework as if the targeted resources and requests are local. Similarly, examples of jobs being scheduled from machines Fred and Wilma also cross inter-region boundaries. These jobs are scheduled 3 16 Version 3.2

75 Advanced Application Services without any knowledge by the administrator of the inter-region operation. In all cases, jobs are scheduled relative to the time zone of the TME 10 server in which the scheduler is running; not the time zone(s) of the machines or resources where the job will execute. Notification Service The notification service allows applications to post notices for review by an administrator. Notices are posted in a language-neutral format using a message catalog service built on top of the X/Open XPG4 message catalog API. This message catalog service enables administrators who are viewing the same notice in different locales to see the notice in their own language. Notices are categorized as they are posted and placed in a notice group. An administrator subscribes to one or more notice groups as set by the senior administrative staff. Notices have a priority assigned when they are posted, which allows filtering and sorting when viewed. In addition, notices have a time stamp indicating the time an operation was performed and a principal name specifying who performed the operation. Notices are retrieved by a notification server, one for each TMR. Finally, notices expire after a specified time. The notification architecture is similar to the Usenet news paradigm. An application posts notices to a collection of pre-defined notice groups to which administrators subscribe. Notice groups are similar in concept to news groups to which individuals may subscribe. Senior administrators control the subscription lists of the junior administrators to limit viewing of notices by unauthorized users. Like Usenet news, the notification implementation keeps a single copy of a notice for all administrators. Because a single copy of the notice is kept, it must be stored in a language neutral format. Doing so enables administrators who speak and read diverse languages to view the notice. The notification service consists of the following four basic components: Application Services Introduction to TME 10 ADE 3 17

76 Advanced Application Services Notification delivery Notification storage Notification group management and registration Notification viewing Notification delivery is the mechanism an application uses to send a notice to some number of notice groups. The notification service provides two kinds of delivery mechanisms. A post operation on the notification server interface provides an object-based means to post a single notice. A second operation is provided that allows one server to stream many notices to the notification server without making multiple requests of an object. Notification storage provides for the persistence of the notification messages. This persistence is required so that server failures do not cause all of the previously delivered notices to be lost. Because the notification service only keeps a single copy of the notice, the notice data must be stored in a language neutral format. As a result, notice data is in binary format and must be flattened or streamed to save the notice data in its database. A notice group is typically created for each application installed in TME 10. Management interfaces allow applications to create new notice groups dynamically when they are installed. An interface that allows administrators to see the available notice groups and to set up subscription lists is also available. Only four default notice groups are supported: TME 10 Administration used to log messages pertaining to general TME 10 functions such as the following: Installation of new machines and applications Adding new administrators Connecting TMRs Creating and removing policy regions TME 10 Authorization used to log authorization errors and changes to the set of roles assigned to an administrator 3 18 Version 3.2

77 Advanced Application Services TME 10 Diagnostics used to log diagnostic error messages such as the following: Could not access administrator object This message means that the administrator object either no longer exists or is corrupted and inaccessible. TME 10 Scheduler used to log messages for events, such as starting a job, that use the scheduler. If these four notice groups are insufficient, the application is responsible for creating any additional notice groups. The application should create as many groups as it needs as part of the installation. When notices are viewed, they are read from the notice database and translated into the language of the administrator that is reading the notice. The view manager then performs the following tasks: It keeps track of the notices the administrator has read It provides some simple filtering of notices It allows the administrator to save the notice text in a file or forward it using mail. Configuration and Change Management Service The Configuration and Change Management Service (CCMS) enables administrators to perform distributed configuration management tasks. These tasks can be described as management by subscription. Profile configurations are created that describe a certain capability or setup such as the following: User accounts in the engineering group Printer configurations for the first floor Monitoring activities for the servers in R&D Profile managers subscribe to one or more profile configurations. They are also used for flexible grouping and optional overrides of configuration information for sets/collections or types of machines. Application Services Introduction to TME 10 ADE 3 19

78 Advanced Application Services Profile endpoints such as machines and NIS domains are subscribed to one or more profile managers. They receive their configuration information and actions using distributed propagation for local interpretation by an application agent. Programmers building distributed applications without CCMS that effect the configuration of many systems, must develop all of the logic to perform the following tasks: Identify target systems Propagate changes Record changes Support exceptions CCMS, however, enables applications to create abstract, architectureand platform-independent profiles that describe configuration settings for the resources and services they manage. Collections of profiles can be created and saved as a profile manager to describe the configuration aspects of a number of system parameters. Hundreds of machines can then be set up as subscribers to the profile manager and their configurations altered appropriately. Subsequent changes to a profile manager or the addition of new profile configurations are automatically propagated to the subscribing machines in the network. This change propagation provides the system 3 20 Version 3.2

79 Advanced Application Services administrator with a configuration framework and distribution service into which application modules are plugged. Corporate Profile Manager P 1 P2 P3 Sales Profile Manager Marketing Profile Manager R&D Profile Manager P1 P2 P3 P1 P2 P3 P1 P2 P3 P4 P5 P5 P5 P6. In this figure a corporate top-level profile manager has been established containing three application configuration profiles. Various profile managers at the work group level are defined, each subscribing to the profile configurations contained at the corporate level. Within the work groups, those entries in the configurations that are not fixed by the policy established in the corporate profile manager can be overridden as necessary. Additionally, work group-specific configuration profiles are also defined. A set of profile endpoints subscribed to the work group profile managers perform the following tasks: Receive information and actions described in the profile configurations and update system files Change system configurations Augment system operations as directed by the configurations An administrator is then able to change one item at the corporate profile manager level and affect all machines by merely pressing a button. Application Services Introduction to TME 10 ADE 3 21

80 TAS Run-time Library Database Interface APIs Besides providing its own database, TME 10 also provides an object-oriented interface to third-party relational database management systems (RDBMSs). Called the RDBMS Interface Module (RIM), these APIs enable applications to store data in RDBMSs (such as Sybase, Oracle, and DB2), instead of in the TME 10 database. Storing application data in these types of databases enables you to use their query, reporting, and SQL capabilities. It also means that data from one application can be visible to other applications. This interface offers improved data sharing between applications. Multiple applications can access and use data gathered from multiple sources and stored in a third-party database. TAS Run-time Library TME 10 ADE includes a library of convenience run-time functions to simplify the task of creating robust, distributed, heterogenous applications. Areas covered by the TAS run-time library include: Distributed exception handling Memory management File I/O and versioning Inter-object message facility Message logging and a message catalog service Regular expression pattern matching Data encryption Data manipulation Directory services Distributed Exception Handling The TME 10 distributed exception handling service offers true termination semantics instead of the CORBA return-code approach. This termination-based approach is central to the development and deployment of dependable, distributed applications Version 3.2

81 TAS Run-time Library This service enables you to define exception classes for signalling application-specific exceptions and unanticipated events. Exceptions are implemented as a class-based termination model facility patterned after the design adopted for the C++ language. This exception handling service supports both C and C++ language bindings and is independent of architecture or platform. Exceptions may be raised in a method on one platform and caught and handled by a method on a second platform. Furthermore, exceptions are integrated with the message catalog service (described below) and allow applications to identify specific parameters, message formats, and arguments as appropriate. Memory Management The following sections discuss the functions for managing global storage (that is, outside of function scope) and local storage (inside function/block scope) provided in the TAS library. The global memory management functions provide a convenient mechanism for allowing an application to safely allocate and manage global storage within a process. These functions parallel those for local memory management, throw exceptions when necessary, and provide a consistent memory management facility. These characteristics ensure the ability of the application to control allocation and release of memory at the appropriate times. The local memory management functions provide a convenient mechanism to allow an application to safely allocate and manage local storage within a method. Additionally, these functions facilitate the management of memory allocated and returned by libraries and other services that are called by a function. The local memory management functions build and maintain a list of blocks with pointers to the heap-allocated storage that can be released, returned, and destroyed. You can provide this management either from the application or automatically when exceptions are thrown. Within a function or new scope block of a method, a local memory management handle is created and passed as an argument to one of the TAS functions. These functions allocate, reallocate, manipulate, and finally free heap-based storage. Application Services Introduction to TME 10 ADE 3 23

82 TAS Run-time Library A single local memory management handle can manage multiple allocation requests and services. It does so by maintaining a linked list of allocated blocks of storage. Using a TAS memory management function is very similar to using the system-defined malloc(3) function: a pointer to the allocated memory is used and passed in the function code in much the same way. There is only one difference: the block is also referenced from a linked list maintained by the local memory management handle. If an abnormal exit from the function occurs, each block of memory managed by the local memory management handle is released. An application method should use the local memory management functions rather than malloc(3). Doing so not only safely allocates and releases storage within a method; it also ensures that any heap-based storage is automatically released by an appropriate de-allocation routine when an exception is thrown. The automatic release of memory eliminates the requirement of explicitly catching all exceptions types solely for the purpose of memory management. It also ensures that long-running methods manage their memory effectively. File I/O The file I/O service offers support for read/write locking, versioning, and automatic rollback on transaction abort events. TME 10 ADE supports a set of interfaces for reliably accessing, updating, and versioning system files in an architecture and operating system independent manner. This service provides UNIX stream-like access for creating, opening, searching, reading, writing, and closing files. An enhanced regular expression pattern matching capability makes construction of filters and update methods simple and efficient. Additionally, file operations are integrated with both the exception and transaction services to facilitate versioning and rollback of files when errors are encountered. Finally, an optional file header and comment registration mechanism provides for automatic date/time stamps, descriptions, and/or administrator IDs. These can be used for the audit of system files in much the same manner as that used by RCS or CVS Version 3.2

83 TAS Run-time Library Inter-object Message Service The inter-object message (IOM) service provides a connection-oriented bidirectional service between methods of different objects that is independent of the object services layer and operating system. This service is designed for applications that require an asynchronous bidirectional method-to-method communication and transport facility. The inter-object message service requires participating methods or client programs to be threaded. Using threaded methods is necessary for one of two reasons: A thread in the client is required for method invocation A thread in the server is needed for communication after the client has been started The IOM design and functions are built around two opaque data structures, a key and a handle. These data structures are used in the IOM functions that are part of the TAS run-time. The IOM data structures are opaque type-wrappers around framework data structures. Their contents and structure is hidden from the application developer to better insulate applications code from potential framework changes in the future. A method attempting to initiate a method-to-method connection first creates a key and uses it to generate a handle. The key is then passed as an argument when activating the remote method, which uses the key to create a different handle for itself. Requiring both methods to use identical keys ensures the correct connection at each end. Message Catalogs TME 10 provides complete language independence, which enables application use worldwide. To achieve this, TME 10 supports a message catalog facility that is X/Open XPG4 compliant. This compliance permits both internationalized and localized applications development. When an administrator posts a dialog the appropriate message catalog is loaded and presents the correct translation based on the viewer s locale. Notices posted to the bulletin board are translated when read, Application Services Introduction to TME 10 ADE 3 25

84 TAS Run-time Library enabling a single notice to have multiple translations as required by the locale of each administrator. Information about message catalogs and creating them is available in the Application Services Manual. The Dialog Specification Language (DSL) supports a directive (the Msg directive) for using message catalogs to internationalize dialogs. DSL is a declarative language used for specifying dialogs in a GUI. Information about DSL and the Msg directive is available in the Desktop Services Manual. The exception handling service also provides mechanisms for describing message format and context, which automates much of the definition and translation process. The message catalog facility, and TME 10 management platform services are 8-bit clean and multi-byte compatible. The display and input of Cyrillic, Kanji, and other Asian languages, however, will be supported in a future release. Regular Expression A portable set of regular expression manipulation routines supporting searching and substitution within streams and strings is provided with the TAS run-time library. TME 10 regular expressions are specified using Perl notation, which defines a number of special character sequences. These character sequences provide two advantages: They permit compact description of common character classes. They provide a mechanism for sub-expression capture that is much easier than that given by sed variations. As a convenience, the TAS run-time provides several symbolic string constants that represent complex expressions. Typical examples include such things as matching valid machine names, absolute and relative paths, and NFS mount points. These constants can then be combined using an ANSI pre-processor (which concatenates sequences of strings separated only by white-space) to define arbitrarily complex expressions Version 3.2

85 TAS Run-time Library Data Encryption Requests passed between ORBs are always cryptographically sealed so as to prevent unauthorized operation requests. However, application data passed as arguments is not by default encrypted. Two encryption services are available for use by applications when data must be stored or passed around in a non-readable format. The encryption routines are provided with the TAS run-time library for the convenience of application programmers. These routines offer a simple, portable mechanism for encrypting and decrypting user-supplied data using either the following techniques: A simple, effective TME 10 Framework encryption algorithm A more secure DES algorithm. For those cases where the high-level security offered by the DES algorithm is not necessary, you should use the TME 10 Framework encryption functions. They can provide a simple and non-trivial encryption and decryption facility so that user-defined data need not be passed around the network as ASCII text. For those cases where only the highest level of security through encryption is acceptable, use the encryption functions that employ the DES algorithm. They can provide a simple interface to a powerful encryption mechanism so that user-defined data passed between methods around the network is completely secure. Data Manipulation The TAS run-time library provides two families of convenience routines for manipulating data. The first is a traditional doubly-linked list implementation with a rich set of functions and features. The second is an equally rich set of functions for manipulating the standard CORBA sequence data type. The doubly-linked list service provides for a list of nodes that point to arbitrary data. Each node maintains pointers to the previous and next entries in the list, as well as the number of bytes in the item to which the data field points. The use of IDL in concert with the TME 10 CORBA architecture, limits the use of the described doubly-linked list routines. They are Application Services Introduction to TME 10 ADE 3 27

86 Task Library primarily used as convenience routines for callbacks from the GUI and CLI programs. In a CORBA object system, sequences are the preferred data type providing a list oriented abstraction instead. The CORBA 1.1 specification, however, defines no functions to manipulate and work with sequences. To fill this void, TME 10 ADE provides a set of functions for adding, finding, and removing items in sequences. Directory Services Task Library The directory services functions are provided with the TAS run-time library for the convenience of application programmers. These functions provide two things: Easy access to distinguished objects within a Tivoli Management Region (TMR). The ability to locate a specific object of a given type. The functions serve as a user-friendly front end to the name registry (see Name Registry on page 1-14 for details). They also provide a convenient mechanism for determining the object reference of a specific named resource or set of resources of a given type. Note: All references to type indicate a named resource type as stored in the inter-region resource cache. The TME 10 Framework is a powerful tool for system administrators who manage a distributed network of machines. The task library is a mechanism that exposes this distributed nature through a graphical user interface in a way that a system administrator can use. This mechanism enables administrators to create shell scripts that can run on any managed node. A shell script integrated with managed nodes in this manner is called a task. When administrators want to create a task, they provide a machine and a path to an executable file. The executable can be a shell script, a Perl script, a compiled program, or any other kind of valid executable Version 3.2

87 Task Library When a task is created, the executable is stored as an attribute in the object database. The original file that contained the executable is no longer needed. When the task is executed on one or more managed nodes (through drag and drop or subscription), the executable file is retrieved from the attribute. It is then run on the specified machines, and the results displayed on the screen or saved in a file. After a task is created, it is added to the task library and displayed as an icon. The task library provides a location from which to manage tasks without adding additional clutter to the administrator s desktop. Each TMR can contain one or more task libraries and they can be copied onto any administrator s desktop, sub-libraries created, and so on. The ability to copy a library to other resources enables different administrators to have access to and management responsibility for different sets of tasks. Examples of tasks a senior administrator might want to create for use by junior administrators include: A script that finds and removes all core files from a system to free up disk space. A script that finds and removes all FrameMaker backup files to free up disk space. A script to remove all files in the /tmp directory that are more than one day old. A script that runs the lpshut program and then runs lpsched to restart the print service on Solaris. A SunOS program to find and report on user accounts with passwords that are easy to crack. A script that ensures that no idle sessions remain logged in after 12 hours. Tasks support the concept of machine type and enable an administrator to specify multiple versions of the same task one for each machine type in the installation. If several of the machines can run the same task, a default machine type is also provided. When an administrator makes a request to invoke the task on some managed node, the correct version of the task for that machine type will be executed. Because a task has only one icon, it provides a senior administrator with a means of creating custom solutions to site-specific problems. Application Services Introduction to TME 10 ADE 3 29

88 Task Library Administrators can create these custom solutions even if there are multiple versions for different machine types. The responsibility to resolve these problems can then be delegated to a junior administrator who might otherwise not be able to work effectively in a heterogenous environment. Junior administrators interact with only one icon to perform some operation, regardless of the machine type(s) on which the associated operation is executed. An extension of the task concept is that of a job, which is defined as a task with a pre-selected set of managed node subscribers. This can be useful, for example, if a certain operation is often executed on the same set of managed nodes. Alternately, a senior administrator might use this feature as a means to limit the machines on which a task may be executed by a junior administrator. Jobs and tasks have one primary difference in the way they are executed. When a task is invoked, the administrator is required to specify the set of machines to run again unless it is dragged-and-dropped onto a managed node icon. A job, however, can be executed immediately either by double-clicking on the icon or dragging and dropping it onto the scheduler icon to be run at a later time Version 3.2

89 4 4Desktop Services Desktop Services TME 10 ADE provides three basic sets of services for developing your application: Framework services Application services Desktop services This chapter describes the desktop services and how to use them as you develop your application. Introduction to Desktop Services Each authorized TME 10 administrator has access to a TME 10 desktop containing one or more icons representing system resources. As administrators interact with dialogs available from these icons, they are able to change system configurations and create new resources in the distributed environment. When an administrator interacts with the desktop, callbacks are invoked from the user interface on underlying objects representing some system resource or component. These callbacks are translated Introduction to TME 10 ADE 4 1

90 Introduction to Desktop Services into a series of method invocations that actually perform the work and return any results or status to the administrator. Application dialogs 5 6 TME 10 desktop 1 4 Application callbacks 2 3 The information flow begins when an administrator selects an icon or interacts with a dialog. The information is then sent to the TME 10 desktop (step 1), at which time the appropriate application callback method is invoked (step 2). The callback method then invokes core application methods, which communicate with the application object(s) to perform some system management operation (step 3). Any return information or state is passed back (steps 4 and 5). If an update to the user interface is 4 2 Version 3.2

91 Dialog Specification Language (DSL) and Compiler required, the TME 10 desktop interprets the output and updates the dialogs on the administrator s desktop (step 6). The TME 10 desktop services offer a set of platform and presentation independent user interface services to simplify application design and construction. These services support X11R5 Motif 1.2 and Windows 3.1 (DOS and NT). The following components are provided: DSL language and compiler used to specify dialog layout and interaction TME 10 desktop display manager and command/callback engine Desktop services library run-time convenience functions Gadget library object-oriented abstraction for manipulating dialogs Each TME 10 dialog serves as a two-way communication link between an administrator and one or more TME 10 resources. TME 10 resources work with dialog descriptors, which are data structures that define dialog contents and behavior. Dialog descriptors are specified using the Dialog Specification Language (DSL), compiled with the DSL compiler, and stored as attribute values on an object. Each dialog has controls that enable an application to perform its required tasks, which includes the ability to invoke operations on objects. These methods interact with and change the user interface in response to administrator actions. The gadget library and desktop services library provide the run-time functions to enable this dialog and gadget interaction to occur. Desktop Services Dialog Specification Language (DSL) and Compiler The DSL and compiler offer support for specifying the gadget control and layout of a dialog without tying an application user interface to a particular presentation system. A gadget is a dialog control that presents application output in some form and provides a way for an application to receive administrator Introduction to TME 10 ADE 4 3

92 Dialog Specification Language (DSL) and Compiler Active Gadgets input. DSL provides support for gadgets that are classified as either active gadgets or inactive gadgets. Active gadgets are those that can accept user input. Active gadget types are further classified as either command gadgets or value gadgets. Command gadgets invoke operations when they are selected. Value gadgets display one or more values and allow a user to change the gadget value. The following table lists the active gadget set supported by DSL: Gadget Button Item Icon Choice List Switch Page Text Table Purpose Invokes an object callback to start an operation An item in a menu Presents a visual representation of an object and a set of operations for the object via a pop-up menu Presents a list of choices and returns one entry Presents a list of choices and returns one or more entries Presents a switch with a simple on/off state Presents a multi-line text field Presents a one-line text string Presents a multi-row/multi-column editable table 4 4 Version 3.2

93 Dialog Specification Language (DSL) and Compiler Inactive Gadgets Gadget Message Separator Group Menu Inactive gadgets can only display data, contain other gadgets, or help with layout or presentation. The following table lists the inactive gadget set supported by DSL: Purpose Presents a non-editable one line text string Presents a single-line horizontal separating line Presents a set of gadgets as a group, which can contain most other gadgets, including other groups Presents a menu of item gadgets Desktop Services DSL Features Although limited in number, each of the gadgets supported by the DSL compiler has many attributes that can control position, color, sensitivity, and so on. DSL gadgets also support the following attributes: Mixed iconic and gadget views Split windows Scrollable regions Mouse-less support (mnemonics) Keyboard accelerators on menus Full XPM multi-color icons Button glyphs Bitmap labels Additionally, DSL supports a comprehensive drag-and-drop specification, which provides control of both source and target resources on a per-resource type basis. Finally, although dialogs and menus are initially established for an entire class of objects, DSL supports complete per-instance customization of the following: Introduction to TME 10 ADE 4 5

94 TME 10 Desktop Colors, bitmaps TME 10 Desktop Popup/pull-down menus Drag-and-drop rules The TME 10 desktop is the heart of the desktop services and enforces a specific interpretation of a dialog descriptor for a given look and feel. The TME 10 desktop is the software component positioned between the end user and the application objects. In a sense, it can be considered the traffic officer, directing operations to application objects and providing feedback and information upon their completion. The TME 10 desktop has a number of significant features to facilitate application development and customization, including: A high-performance connection-oriented callback mechanism to long-running daemon method clusters An enhanced presentation object model with separation of drag-and-drop rules, popup/pull-down menu definition, bitmap, and color A public set of IDL interfaces supporting basic GUI operations and functionality (mix-in class) for use by applications An inter-client X11 drag-and-drop protocol to enable integration of existing X-based applications with TME 10 objects and GUI An efficient message catalog lookup scheme supporting caching to allow all the text/messages in a set of related dialogs to be transparently retrieved in one step The TME 10 desktop is integral to the functioning of the TME 10 distributed environment. It provides administrators access to multiple resources distributed across remote machines and the ability to manage them. This distributed management is possible because the GUI process is separated from the objects with which administrators interact. That is, the GUI process runs on the administrator s machine. The method process for the requested operation, however, runs on the machine that 4 6 Version 3.2

95 Desktop Services Library accommodates the managed resource. This separation also enables you to write applications without regard for a particular presentation system. Desktop Services Library TME 10 provides a set of desktop services in run-time libraries to facilitate the full exploitation of the underlying user interface technology. These services also simplify the creation of applications with a distributed user interface. The desktop services library provides a set of convenience functions and services that are available in the run-time library. You can use these functions and services in application callback method implementations to simplify interaction with icons, views, and dialogs. The desktop services run-time comprises three families of functions, each with its own common prefix for identification: dtc functions that manipulate/generate desktop commands del functions that edit dialogs in the edit buffer tds functions that provide miscellaneous TME 10 desktop services Desktop Services Desktop Commands (DTC) Desktop commands are intrinsic to the user interface server method (uiserver) and are used to manipulate a dialog, or more precisely, a dialog instance. A dialog instance is a unique copy of a generic dialog description provided in a dialog descriptor. You can generate dialog descriptors using either of the following techniques: You can compile a DSL file and stored it as an object attribute for later retrieval. You can create it dynamically using a series of Dialog Editing Library (DEL) routine calls. Dialog instances permit simultaneous use of multiple copies of a single dialog descriptor, without confusing the desktop or dialog callback routines. Introduction to TME 10 ADE 4 7

96 Desktop Services Library Desktop commands are used to create new dialog instances and to manage existing dialog instances already cached in the desktop. For example, to create a new dialog instance, an application method must retrieve or create a dialog descriptor. The application must then assign the descriptor to a dialog instance identifier (instance id) to give it a unique identity. Finally, the application must call the appropriate desktop commands to prepare the dialog instance for use by the user interface server on the desktop. To manage an existing dialog instance, an application method must pass the associated dialog instance id as an argument to a series of desktop command functions. Passing the instance id to the desktop commands builds a command stream, which is then sent to the desktop to manipulate the dialog instance as desired. The desktop command functions include categories for the following: Managing a sequence of commands Binding, posting, presenting, and dismissing Dialog modification Icons and collections Special-purpose messages and dialogs Asynchronous desktop command execution These routines generate desktop commands that cause one or more changes in a dialog or dialog editing buffer. The commands are generated by the routines when the user interface component of an application is specified with DSL and traditional callback methods are used. The desktop command functions (DTC) generate desktop commands that cause the uiserver to perform one or more operations. These functions are not used when an application is written using the gadget library. Dialog Editing Library (DEL) The Dialog Editing Library (DEL) is a C function library that permits dynamic, persistent creation and editing of dialog descriptors at run 4 8 Version 3.2

97 Desktop Services Library time. DEL complements the Dialog Specification Language (DSL), used for static creation of dialog descriptors before run time. DEL functions are typically used by callback methods and enable an application to perform tasks such as the following: Create a new dialog descriptor Edit a dialog descriptor Add a new gadget to a dialog descriptor Edit the value of a dialog or gadget attribute in a dialog descriptor Delete a gadget from a dialog descriptor Define dialog variables in a dialog descriptor DEL functions use an edit buffer that contains the dialog descriptor being created or edited. Writing the changed dialog descriptor back to the application attribute from which it came makes the change permanent. The desktop editing functions generate desktop commands that cause the TME 10 desktop to perform one or more operations. These functions are not used when an application is written using the gadget library. Desktop Services Desktop Services Miscellaneous Functions The following functions are provided in the TME 10 desktop services (TDS) run-time library provided by the TME 10 ADE. These routines provide miscellaneous services when the user interface component of an application is specified with DSL and traditional callback methods are used. A summary list of all miscellaneous desktop service categories include: Formatting functions Choice list functions Administrator desktop functions The miscellaneous desktop functions (TDS) generate desktop commands that cause the uiserver to perform one or more operations. These functions are not used when an application is written using the gadget library. Introduction to TME 10 ADE 4 9

98 Gadget Library Gadget Library The gadget library provides a high-level abstraction for modelling and interacting with user interface components and their associated callbacks. The gadget library provides a high-level interface to the DEL, DTC, or TDS run-time libraries. You should therefore avoid using these libraries in concert with the gadget library. When you use the gadget library, a dialog is read from a descriptor and is represented in memory as a set of light-weight transient objects. Multiple application callbacks are packaged within a single daemon method to retain state, reduce the amount of required code, and improve interactive performance. Callbacks initiated by the end-user that affect the dialog state (such as insensitive regions) communicate using a connection-oriented protocol. When final commit is initiated, all state and data is already present in the daemon process, thus facilitating easy and simpler application development. Daemon state consists primarily of a hierarchy of in-memory dialog objects, each of which is the root of a sub-hierarchy of gadget objects. The dialog hierarchy expands and shrinks as an application creates, presents, dismisses, and destroys dialogs. By default, when new dialogs are created, they are made children of the current dialog (that is, children of the dialog that generated the current callback). This can be overridden so that new dialogs can be created at top-level. A hierarchical dialog name-space provides access to any dialog in the application. A sub-hierarchy of that dialog s gadgets (also represented as in-memory objects) is contained in each dialog object. Here, too, the (sub-)hierarchy expands and shrinks as the application creates gadgets, adds them to or removes them from a dialog, and destroys them. A separate hierarchical gadget name-space is maintained for each dialog. All access to and manipulation of the display is done through these dialog and gadget objects. Dialogs and gadgets can be accessed by using either a full or relative path. Gadget attributes can be accessed or modified by conventional function calls. Gadgets can be moved from one dialog to another. Dialogs can be loaded from DSL, presented, and dismissed Version 3.2

99 Gadget Library Subordinate dialogs are dismissed automatically if their parent is dismissed. In all cases, the library automatically updates the display accordingly, freeing the programmer from tedious tasks of managing the display at its lowest level. Application-specific code consists almost entirely of callback functions defined for the various gadget and dialog classes. The callback mechanism is type-safe, yet callback functions defined for one gadget class can be reused as callbacks by that class s subclasses. Callback functions can be mapped onto DSL names and used directly in DSL. Each gadget class maintains its own set of name mappings to callback functions of its type. These maps thus form a hierarchy corresponding to the gadget class hierarchy. When a DSL dialog descriptor is loaded by the gadget library, the library looks up each gadget s callbacks in its class s function map. If the callback is not found, the maps in the gadget s base classes are recursively searched until the function is found. An internal callback structure is then created with that function and the arguments specified in DSL. Thus, in DSL, callback functions behave like virtual member functions, which may be inherited, redefined in derived classes, and so on. High-level control in the application resides in an event manager that performs the following tasks: Initializes the application Invokes its start-up function Responds to TME 10 desktop events The event manager responds to events by locating, initializing, and dispatching the appropriate callbacks and updating the internal state of the application. Callbacks are managed by the gadget library and invoked from the daemon method, not by the TME 10 desktop. The TME 10 desktop sees only a single, hidden callback to the daemon method, which then takes control and invokes the actual callbacks sequentially. Each callback in a callback list is invoked until either the list is exhausted or one of the callbacks throws an exception. If one of Desktop Services Introduction to TME 10 ADE 4 11

100 Gadget Library the callbacks does throw an exception, the state is unwound back to the start of the first callback. Any dialogs or resources that have been changed are then cleaned up, and the exception is thrown back to the TME 10 desktop Version 3.2

101 5 5TME 10 ADE Documentation Library This chapter provides information to help you effectively use the ADE documentation set. It describes which manuals contain the appropriate information for a given development task. Documentation Library The TME 10 ADE documentation set contains the following manuals: Introduction to TME 10 ADE Framework Services Manual Application Services Manual, Volumes 1 and 2 Desktop Services Manual Application Development with TME 10 ADE Application Development for the Lightweight Client Framework Programmer s Reference Manual TME 10 ADE Master Index The following sections describe each document. Each section contains a document summary, a brief outline, and a list of prerequisite reading material. TME 10 ADE Documentation Library Introduction to TME 10 ADE 5 1

102 Introduction to TME 10 ADE Introduction to TME 10 ADE Introduction to TME 10 ADE presents basic conceptual material about TME 10 ADE and the manuals that document it. The information in this manual has several functions: It provides context. TME 10 ADE enables you to develop applications that conform to standards provided by organizations such as X/Open and OMG. This manual provides high-level information about these organizations and the relevant standards produced by them. It introduces you to the TME 10 ADE services. The TME 10 ADE provides many services to facilitate reliable application development. This manual describes these services, and how each can be used to enhance your application. It enables you to use the documentation set. The TME 10 ADE documentation is large, and this manual presents an overview of the set. The Introduction to TME 10 ADE also presents the installation and set-up procedures for TME 10 ADE. The target audience is C/UNIX programmers who want to develop Tivoli applications, but have no prior knowledge of the TME 10 ADE. This manual presents the following topics: Fundamental concepts of TME 10 ADE Framework services Application services Desktop services TME 10 ADE documentation library TME 10 ADE installation Framework Services Manual The Framework Services Manual is a concept-oriented document describing CORBA 1.1 and IDL within the context of the TME 10 ADE. The first chapter of this manual describes object-oriented 5 2 Version 3.2

103 Application Services Manual, Volumes 1 and 2 programming concepts, such as object classes and instances of those classes. Chapter 2 describes Tivoli s implementation of CORBA 1.1, which includes a high-level discussion of security. TME 10 ADE enables you to build security into your applications. This chapter explains the advantages of this increased security, and it explains how to minimize the expense associated with it. Chapters 3 and 4 describe OMG IDL and Tivoli s extension to it, TEIDL. It also explains how IDL and TEIDL can make application development less expensive and applications more reliable. Chapters 5 and 6 explain how to implement your server (object implementation) and client. TME 10 ADE supports the implementation of daemon servers with concurrent multiple threads in your application. These chapters explain how to successfully employ such techniques as well as avoiding common pitfalls such as deadlocks and memory leaks. The target audience is that of C/UNIX programmers who want to write TME 10 applications but have no prior knowledge of CORBA 1.1, or IDL. You should read this manual before attempting to develop any part of your application. TME 10 ADE Documentation Library Application Services Manual, Volumes 1 and 2 The Application Services Manual, Volumes 1 and 2 are concept-oriented documents that describe the services TME 10 can provide to applications. Examples of such services include exceptions, nested transactions and rollback, file I/O, and scheduling. The target audience is that of C/Unix programmers who want to develop TME 10 applications, and whose only knowledge of the TME 10 ADE is that provided by the Framework Services Manual. Application Services, Volume 1 presents the following topics: The TAS library Exceptions Memory management Transactions Introduction to TME 10 ADE 5 3

104 Desktop Services Manual File I/O services Message catalogs Notification services Tivoli name registry Managed nodes Job scheduling Security and authorization Administrators Application Services, Volume 2 presents the following topics: Instance managers Collections Policy regions and policy Table management API Configuration and change management Task library RIM Application Installation and licensing Well-behaved applications Desktop Services Manual The Desktop Services Manual is a concept-oriented document describing the available desktop services, which include DSL, and the gadget library. This manual provides the following information: It describes the TME 10 ADE User Interface. It describes the concepts associated with communication among applications on a heterogeneous network, dialog presentation, and drag and drop. 5 4 Version 3.2

105 Application Development with TME 10 ADE It presents a detailed discussion of dialogs, which includes the following: Dialog descriptors Associating dialogs with applications in a CORBA-compliant framework Gadgets Callbacks Reasons It describes DSL and the procedures for composing dialogs. It describes the object-oriented gadget library, the desktop command library, and the dialog editing library. The target audience is C/UNIX programmers who want to develop Tivoli applications but have no prior knowledge of the TME 10 GUI. The book discusses the following major topics: TME 10 desktop TME 10 dialogs DSL Creating dialogs Object-oriented gadget library TME 10 drag-and-drop protocol Desktop command library Dialog editing library TME 10 ADE Documentation Library Application Development with TME 10 ADE Application Development with TME 10 ADE describes a sample profile application that you receive with TME 10 ADE. The guide provides an overview of the sample application and explains how to develop it from beginning to end. The guide explains the following aspects of application development using the sample application as a development model: TME 10 ADE Development Cycle Introduction to TME 10 ADE 5 5

106 Application Development for the Lightweight Client Framework Application analysis and design IDL specification Compiling an IDL Specification The initializ method Representing application data Record creation, retrieval, deletion, and modification Policy-related methods Removing a profile Moving and Copying Records Scalable input data with IOM Scalable output data with iterators Sample Application Graphical Interface Components of a GUI Manipulating controls within a method The launch method The Table Manager Profile GUI design considerations Profile support dialogs Command line utilities Managing tabular data Application Development for the Lightweight Client Framework Application Development for the Lightweight Client Framework provides information about how to develop applications to run on the Lightweight Client Framework (LCF). It introduces the LCF, describes the programming environment, discusses the special application library for use by LCF applications, and discusses the components an LCF application should have. 5 6 Version 3.2

107 Application Development for the Lightweight Client Framework Application Development for the Lightweight Client Framework contains these chapters: Chapter 1, "Introduction to LCF" Introduces LCF and the new components it adds to the TME 10 Framework architecture. Chapter 2, "LCF Application Design" Describes elements in the LCF application development environment, such as LCF objects, endpoint methods, and gateway methods. Also describes the components of an LCF application, such as endpoint, upcall collector, and server components. Chapter 3, "The LCF Programming Environment" Describes the programming tools, compiler, and debugging tools you use in developing LCF applications. Chapter 4, "The LCF Application Runtime Library" Describes the application programming interfaces (APIs) available in the application runtime library (libmrt) for use in LCF applications. Chapter 5, "The Common Porting Layer" Describes libcpl, the common porting layer for LCF. Chapter 6, "Dependencies" Describes how to specify and manipulate method dependencies in LCF applications. Chapter 7, "CCMS for LCF Applications" Describes the CCMS functions available to your LCF application and how to include them in your code. Chapter 8, "Task Library" Describes how to include data types from the Task library in your LCF application. Chapter 9, "LCF Sample Application" Describes a sample LCF application: its structure, the build environment, and the steps in writing an LCF application. Appendix A, "Reference" Contains manual pages for libmrt functions. TME 10 ADE Documentation Library Introduction to TME 10 ADE 5 7

108 Programmer s Reference Manual Programmer s Reference Manual The Programmer s Reference Manual is a comprehensive reference guide for all functions, methods, objects, services, and libraries that constitute the API to the development environment. This manual presents the following topics: Directory services Command line interfaces Encryption functions Policy functions Inter-object message service functions Sequence functions Memory management functions I/O Stream functions Regular expression functions Message functions Distributed exception handling Predefined exception class Doubly-linked list functions POSIX threads API Tivoli multiple request (DII) functions Tivoli extended CORBA runtime functions CORBA runtime functions Tivoli Desktop Services functions Dialog editing functions Desktop command functions DSL desktop commands IDL APIs 5 8 Version 3.2

109 TME 10 ADE Master Index TME 10 ADE Master Index The TME 10 ADE Master Index is a comprehensive index for every book in the TME 10 ADE documentation library. Each index entry is listed alphabetically by topic and gives the document title (and volume if applicable), and page number. The document titles are abbreviated according to the following list: Introduction to TME 10 ADE Intro Framework Services Manual FSM Application Services Manual, Volume 1 ASM 1 Application Services Manual, Volume 2 ASM 2 Application Development for the Lightweight Client Framework LCF Application Development with TME 10 ADE Wkbk Desktop Services Manual DSM Programmer s Reference Manual REF TME 10 ADE Documentation Library Introduction to TME 10 ADE 5 9

110 TME 10 ADE Master Index 5 10 Version 3.2

111 6 6Installing TME 10 ADE A TME 10 installation consists of one or more connected Tivoli Management Regions (TMRs). A TMR consists of a TME 10 server and a set of directly associated TME 10 clients. The TME 10 server manages the authorization, location, and inheritance of TME 10 objects within the TMR. It is recommended that you install TME 10 ADE after the you have established the TMR. See the TME 10 Framework Planning and Installation Guide, TME 10 Installation, for details on setting up a TMR. Before you install TME 10 ADE, review the following sections: Software Requirements Hardware Requirements This chapter describes two types of installation procedures: an installation (installing the entire TME 10 ADE product) and an upgrade (installing a patch). The TME 10 ADE Release Notes that you receive with your product media contain the most up-to-date information about hardware and software requirements. Be sure to read them before performing either an installation or an upgrade. Installing TME 10 ADE Software Requirements To do an upgrade installation using the Install Patch...facility, you must have a TME 10 ADE 3.1 installation. If you are running TME 10 ADE 3.0, first upgrade to TME 10 ADE 3.1, then upgrade to 3.2. Introduction to TME 10 ADE 6 1

112 Hardware Requirements If you do not have TME 10 ADE installed, you must do a full installation using the Install Product... option. For instructions on how to install TME 10 ADE see Installation Procedure on page 6-3. For instructions on how to upgradetme 10 ADE, see Upgrade Procedure on page Hardware Requirements Clients The following tables provide the client and server disk space requirements for TME 10 ADE. This space is in addition to the space requirements for the management platform. Platform Libraries Binaries Database Man Pages Message Catalogs AIX AT&T DG/UX HP-UX Motorola Solaris SunOS UnixWare NA 3MB NA 1MB NA NA 5.5MB NA 1MB NA NA 4MB NA 1MB NA NA 3MB NA 1MB NA NA 3MB NA 1MB NA NA 4MB NA 1MB NA NA 5MB NA 1MB NA NA 3MB NA 1MB NA 6 2 Version 3.2

113 Installation Procedure Servers Platform Libraries Binaries Database Man Pages Message Catalogs AIX AT&T DG/UX HP-UX Motorola Solaris SunOS UnixWare NA 3MB NA 1MB NA NA 5.1MB NA 1MB NA NA 4MB NA 1MB NA NA 3MB NA 1MB NA NA 3MB NA 1MB NA NA 3MB NA 1MB NA NA 5MB NA 1MB NA NA 3MB NA 1MB NA Installation Procedure Use this procedure if you do not already have TME 10 ADE installed or if you need to reinstall from scratch. If you already have TME 10 ADE installed, see Upgrade Procedure on page 6-11 for instructions on using the Patch Install facility. You can install TME 10 ADE from either the desktop or command line. Installing TME 10 ADE Desktop Use the following procedure to install the product from the TME 10 desktop. You must have the senior authorization role to install this product. Introduction to TME 10 ADE 6 3

114 Installation Procedure 1. Select the Install -> Install Product... option from the Desktop menu to display the Install Product dialog. 6 4 Version 3.2

115 Installation Procedure If the Select Product for Install: scrolling list does not present the TME 10 ADE item, proceed to step 2; otherwise, skip to step 3. Installing TME 10 ADE Introduction to TME 10 ADE 6 5

116 Installation Procedure 2. Press the Select Media... button to display the File Browser dialog. The File Browser dialog enables you to identify or specify the path to the installation media. If you already know the path to the CD-ROM image a. Enter the full path in the Path Name field. b. Press the Set Path button to change to the specified directory. c. Press the Set Media & Close button to save the new media path and return to the Install Product dialog. The dialog now contains a list of products that are available for installation. If you do not know the exact path to the CD-ROM image a. From the Host scrolling list, choose the host on which the install media is mounted. Choosing a host updates the Directories scrolling list to show the directories of the host you chose. 6 6 Version 3.2

117 Installation Procedure b. From the Directories scrolling list, choose the directory containing the install media. Choosing a directory updates the Files scrolling list to show the files contained in the directory you chose. - If necessary, enter a regular expression in the File Name Filter field to limit the number of file names in the Files scrolling list. See Chapter 1 of the TME 10 Framework Planning and Installation Guide for information on regular expressions. - Press the Filter button to update the Files scrolling list with only those files matching the regular expression. You can then select the correct file. c. Choose a file from the Files scrolling list. d. Press the Set Media & Close button to save the new media path and return to the Install Product dialog. The dialog now contains a list of products that are available for installation. Installing TME 10 ADE Introduction to TME 10 ADE 6 7

118 Installation Procedure 3. Select TME 10 ADE from the Select Product to Install: scrolling list. 4. Use arrow buttons to move the clients from one choice list to another. The product will be installed on the clients in the Clients to Install On list. 6 8 Version 3.2

119 Installation Procedure 5. Press the Select Install Options... button to display the Install Options dialog. a. In the Header Files: field, enter the path to the directory in which the TME 10 ADE header files will be installed. Note: If you must re-install TME 10 ADE on one or more clients, enter an exclamation point (!) at the end of the path. The exclamation point forces TME 10 to re-install the header files when they already exist. b. Select the Create Directories If Missing option if this is the first time you have installed TME 10 ADE in the specified directory. c. Press the Set button to save the directory path and return to the Install Product dialog. 6. Press the Install & Close button to install the product and close the Install Product dialog. OR Press the Install button to install the product and keep the Install Product dialog open. You can then install the same product on another set of clients or you can install another product. Installing TME 10 ADE Introduction to TME 10 ADE 6 9

120 Installation Procedure The installation process prompts you with a Product Install dialog similar to the following. This dialog provides the list operations that will take place when installing the software. This dialog also warns you of any problems that you may want to correct before you install the product. 7. Press the Continue Install button to display the Product Install status dialog. This dialog returns status information as the installation process proceeds Version 3.2

121 Upgrade Procedure When the installation is the complete, the Product Install status dialog returns a completion message similar to the following: Command Line 8. Press the Close button to close the dialog. For information about using the command line to install a TME 10 ADE, see the manual page for the winstall command. Installing TME 10 ADE Upgrade Procedure If you are upgrading from TME or 3.1, use the TME 10 Framework Patch Install facility: Introduction to TME 10 ADE 6 11

122 Upgrade Procedure 1. From the command line, mount the TME 10 Framework, 3.1 to 3.2 Service Pack CD-ROM using the UNIX mount command: # mkdir /CDROM # mount device /CDROM where device is the name of the device containing the TME 10 Framework, 3.1 to 3.2 Service Pack CD-ROM. Consult your operating system documentation for instructions on determining the actual device name. 2. From the TME desktop, select the Install -> Install Patch... option from the Desktop menu 6 12 Version 3.2

123 Upgrade Procedure to display the Install Patch dialog. Installing TME 10 ADE Introduction to TME 10 ADE 6 13

124 Upgrade Procedure 3. If the patch you want to install is not listed in the Select Patch to Install dialog, press the Select Media... button to display the File Browser dialog. The File Browser dialog enables you to identify or specify the path to the installation media. Perform the following procedure to access the patches on the TME 10 Framework, 3.0 to 3.1 Service Pack CD-ROM: a. Enter the full path in the Path Name field (/CDROM). b. Press the Set Path button to change to the specified directory Version 3.2

125 Upgrade Procedure c. Press the Set Media & Close button to save the new media path and return to the Install Patch dialog. 4. Select TME 10 ADE Upgrade to Version 3.2 from the Select Patch to Install list. 5. Use the arrow buttons to move clients from one choice list to another. The patch will be installed on the clients in the Clients to Install On list. Note: You must install the currently available patches on all clients. 6. Press the Install & Close button to install the patch and close the Install Patch dialog. OR Press the Install button to install the patch and keep the Install Patch dialog open. You can then install the same patch on another set of clients or you can install another patch. Installing TME 10 ADE Introduction to TME 10 ADE 6 15

126 Upgrade Procedure The installation process prompts you with a Patch Install dialog similar to the following. This dialog provides the list operations that will take place when installing the software. This dialog also warns you of any problems that you may want to correct before you install the patch. 7. Press the Continue Install button to start the installation procedure. The installation will begin and the status of the installation will be displayed in the Patch Install dialog Version 3.2

127 Upgrade Procedure When the installation is complete, the Patch Install dialog returns a completion message similar to the one below. 8. Press the Close button to close the dialog. Installing TME 10 ADE Introduction to TME 10 ADE 6 17