Professional Documents
Culture Documents
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE. USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN TIBCO ENTERPRISE MESSAGE SERVICE CENTRAL ADMINISTRATION INSTALLATION) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME. This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc. TIB, TIBCO, TIBCO Adapter, Predictive Business, Information Bus, The Power of Now, TIBCO ActiveMatrix BusinessWorks, TIBCO Enterprise Message Service, TIBCO Enterprise Message Service Central Administration, TIBCO Rendezvous, and TIBCO SmartSockets are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM. THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME. THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES. Copyright 2008 TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information
| iii
Contents
Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Structural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Central Administration Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Access Control and Central Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
iv
| Contents
Chapter 3 The Central Administration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
The Central Administration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 The Deployment Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 The Administration Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 How Conflicts are Resolved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figures v
Figures
Figure 1 Figure 2
vi
| Figures
Tables vii
Tables
Table 1 Table 2
viii
| Tables
| ix
Preface
TIBCO Enterprise Message Service Central Administration provides a way for administrators of a TIBCO Enterprise Message Service deployment to make configuration changes to multiple Enterprise Message Service servers and deploy the changes simultaneously, all from a centralized location.
Topics
Related Documentation, page x Typographical Conventions, page xii How to Contact TIBCO Support, page xiv
| Related Documentation
Related Documentation
This section lists documentation resources you may find useful.
Preface xi
Third-Party Documentation
Eclipse STABLE Documentation, available through http://www.eclipse.org/documentation/ Java Message Service specification, available through http://java.sun.com/products/jms/index.html Version Control with Subversion, available through http://svnbook.red-bean.com/ Apache HTTP Server documentation, available through http://httpd.apache.org/ Apache Tomcat documentation, available through http://tomcat.apache.org/
xii
| Typographical Conventions
Typographical Conventions
The following typographical conventions are used in this manual. Table 1 General Typographical Conventions Convention
TIBCO_HOME ENV_HOME EMSCA_HOME
Use Many TIBCO products must be installed within the same home directory. This directory is referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends on the operating system. For example, on Windows systems, the default value is C : \ t i b c o . Other TIBCO products are installed into an installation environment. Incompatible products and multiple instances of the same product are installed into different installation environments. The directory into which such products are installed is referenced in documentation as ENV_HOME. The value of ENV_HOME depends on the operating system. For example, on Windows systems the default value is C:\tibco. TIBCO Enterprise Message Service Central Administration installs into a directory within ENV_HOME. This directory is referenced in documentation as EMSCA_HOME. The value of EMSCA_HOME depends on the operating system. For example on Windows systems, the default value is C : \ t i b c o \ e m s \ c a \ 1 . 0 .
code font
Code font identifies commands, code examples, filenames, pathnames, and output displayed in a command window. For example: Use M y C o m m a n d to start the foo process.
Bold code font is used in the following ways: In procedures, to indicate what a user types. For example: Type a d m i n . In large code samples, to indicate the parts of the sample that are of particular interest. In command syntax, to indicate the default parameter for a command. For example, if no parameter is specified, M y C o m m a n d is enabled:
MyCommand [enable | disable]
Preface xiii
Use Italic font is used in the following ways: To indicate a document title. For example: See TIBCO ActiveMatrix BusinessWorks Concepts. To introduce new terms For example: A portal page may contain several portlets. Portlets are mini-applications that run in a portal. To indicate a variable in a command or code syntax that you must replace. For example: M y C o m m a n d pathname
Key combinations
Key name separated by a plus sign indicate keys pressed simultaneously. For example: Ctrl+C. Key names separated by a comma and space indicate keys pressed one after the other. For example: Esc, Ctrl+Q. The note icon indicates information that is of special interest or importance, for example, an additional action required only in certain circumstances. The tip icon indicates an idea that could be useful, for example, a way to apply the information provided in the current section to achieve a specific result. The warning icon indicates the potential for a damaging situation, for example, data loss or corruption if certain steps are taken or not taken.
xiv
|1
Chapter 1
Overview
This chapter contains a general overview of TIBCO Enterprise Message Service Central Administration components and architecture.
Topics
Benefits, page 2 Structural Overview, page 3 Central Administration Projects, page 5 Access Control and Central Administration, page 6
| Chapter 1
Overview
Benefits
Centralized Configuration
With TIBCO Enterprise Message Service Central Administration, you can apply configuration changes across multiple TIBCO Enterprise Message Service servers from a single location. Central Administration uses the Eclipse framework to provide a graphical user interface (GUI) for configuring TIBCO Enterprise Message Service servers. Central Administration integrates with the Subversion version control system, allowing multiple administrators to collaborate without fear of introducing conflicts. Revision control also permits you to easily roll back to an earlier deployment. Central Administration validates configuration settings, showing any conflicts or invalid settings in the Problems view. Central Administration gives you the ability to assign tags to servers, letting you group and query for a specific set of servers to perform an action on. You can save rules and rule sets to run at a later date.
Validation
Queries
Structural Overview 3
Structural Overview
TIBCO Enterprise Message Service Central Administration has two main parts, the Central Administration Client and the Central Administration Server. The Client is installed on an administrators local system, and provides a GUI for administering TIBCO Enterprise Message Service deployments. A user creates projects in the Client, with each project corresponding to one Enterprise Message Service deployment. The Central Administration Server is installed in a centralized location, and acts as the hub between the Client and an Enterprise Message Service deployment. The Server hosts a Subversion repository, which provides source control for the Enterprise Message Service deployments configuration files. Two other objects inside the Central Administration Server, the deployment server and the agent, manage the Servers connections to the Client and the Enterprise Message Service deployment: Central Administration deployment servers are the Clients connection to the Central Administration Server, and through that to the Enterprise Message Server. There is one deployment server for each project (or Enterprise Message Service deployment) administered by the Central Administration Server. The Central Administration agent manages the connection between the Central Administration Server and an Enterprise Message Service server. There is one agent for each server in the Enterprise Message Service deployment.
The Client connects to the Central Administration Server through the deployment server and retrieves source-controlled configuration files from the Server. Through the Client, the user makes the desired configuration changes and saves the changes to the Subversion repository. When a user issues a deploy command to the Central Administration Server, the agent then updates the deployed TIBCO Enterprise Message Service server configuration. Figure 1 shows the connections between the Central Administration components and TIBCO Enterprise Message Service:
| Chapter 1
Overview
DS1
Subversion Repository
DS2
Deployment 1
Deployment 2
Client C
Client A
Client B
Legend Subversion Repository DS1 DS2 Central Administration Deployment Servers Central Administration Agent EMS Server Central Administration Client
Figure 1 shows a Central Administration Server with two deployment servers, DS1 and DS2. DS1 administers the TIBCO Enterprise Message Service deployment called Deployment 1. It connects to the servers in Deployment 1 through agents, and stores files for those servers in the Subversion repository. Similarly, DS2 connects to the EMS servers in Deployment 2 using agents. DS2 also stores Deployment 2 files in the repository. Central Administration Clients connect to DS1 or DS2, depending on which Enterprise Message Service deployment the Client administers. Client A administers both deployments, and so connects to both DS1 and DS2. Client C administers only Deployment 1, and Client B administers only Deployment 2. Because each deployment server corresponds to a project in the Client, we know that Clients B and C each have one project. Client A has configured two projects.
Before you can create a new TIBCO EMS project in the Client, you must have already installed a Central Administration Server and deployed a Central Administration deployment server.
| Chapter 1
Overview
Central Administration Server and any deployment server are controlled through your external LDAP server. Any user with a valid LDAP username and password can connect to the Central Administration Server. You can also control access to the Central Administration Server by restricting non-administrative access to the host, using standard UNIX permissions. See TIBCO Enterprise Message Service Central Administration Installation for more information about configuring the Central Administration Server to connect to your LDAP directory.
Access to the Subversion Repository Permissions save configuration changes
to the Subversion repository are stored in the Subversion access control list (ACL). The Subversion ACL is initially configured during installation of the Central Administration Server. This controls who can modify and add files to the repository, but does not control view access. Following installation of the Central Administration Server, the system administrator can change the Subversion ACL by editing the p r e - c o m m i t . p e r m s permissions file located here:
svn-install-dir/ r e p o s / c o n f / p r e - c o m m i t . p e r m s
See TIBCO Enterprise Message Service Central Administration Installation for more information about the Subversion access control list.
Access to the Configuration Files Permissions to edit the TIBCO Enterprise Message Service configuration files are determined by the user permissions configured for each Enterprise Message Service server in its a c l . c o n f file. Subversion validates the user's permissions before permitting a save to the repository.
Users can view configurations without receiving edit permissions. When that is the case, the user is not permitted to save configuration changes to the Subversion repository.
|7
Chapter 2
This chapter provides a detailed explanation of the Central Administration Client and the tools the Client provides for administering an Enterprise Message Service server.
Topics
Exploring the Central Administration Client, page 8 Understanding Rules and Rule Sets, page 12
| Chapter 2
Editor tabs
administers, and all the servers, templates, and rule sets associated with each project.
Editors and Editor Tabs Editors are the interface to the Enterprise Message Service server configuration files. Each editor corresponds to a .c o n f configuration file. You can switch between editors by clicking the editor tabs. Views Views display status information about the selected TIBCO Enterprise Message Service server or project. TIBCO Enterprise Message Service Central Administration has two custom views: the EMS Status View, and the Problems view.
Project Navigator
The project navigator lists all the projects configured for the Client, and all TIBCO Enterprise Message Service servers, EMS RuleSets, and EMS Server Templates created for each project.
10
| Chapter 2
File Types
The file names and types in the project navigator identify the items configuration file in the Subversion repository. You can identify an item in a project list as a server, template, or rule set according to its file type.
.emsserver
.emsservertemplate .emsrules
The editors use the file type when determining how to display the item. If a file type is incorrect or missing, it does not display correctly in the editor. The project navigator is also the access point for Subclipse commands. Subclipse is an Eclipse plug-in that provides advanced tools for managing the Subversion repository. Subclipse includes many useful commands. You can access Subclipse commands by right-clicking an item in the project navigator.
Editors
The editor tabs available in the main panel of the Client provide a visual interface into the configuration of a TIBCO Enterprise Message Service server. There is an editor for each server configuration file, and editor fields correspond to the parameters that can be set in each file. You modify most parameter settings that are configurable during runtime using the TIBCO Enterprise Message Service Administration Tool. Other parameters can only be set when modifying a new server using the EMS Server Template. When viewing deployed EMS server configurations, these parameter values are displayed for informational purposes only. The parameter names are greyed out, and their settings cannot be modified through the Central Administration interface. The Central Administration Client includes these editors:
Server Controls the characteristics of the TIBCO Enterprise Message Service
file.
Stores Defines the locations, either store files or a database, where the
Routes Defines routes between this and other TIBCO Enterprise Message
to import messages from or export messages to an external message service, such as TIBCO Rendezvous or TIBCO SmartSockets. This editor modifies the t r a n s p o r t s . c o n f file.
Users Defines TIBCO Enterprise Message Service users. This editor
TIBCO Enterprise Message Service server. This editor modifies the file. file.
listeners for use by topics that export messages to an RVCM transport. This editor modifies the t i b r v c m . c o n f file.
Views
The Central Administration Client includes two views that provide helpful status information:
EMS Status View Displays the status of the selected project and its deployment server. You can also view details about the Central Administration agents that are connected to the deployment server. Problems Displays any configuration errors in the TIBCO Enterprise Message Service server. The Client reviews the configuration files for errors each time the file is opened or saved.
12
| Chapter 2
Tags
Tags are customized Name-Value pairs that you can assign to a server. All servers that share the same tag Name-Value combination are part of the same group. Because you can assign multiple tags to a server, it can be part of multiple groups. Tags are case sensitive and matches are made on whole words, not partial matches. That is, U S A and u s a are not matching values, and nor are U S A and U S . Table 2 shows an example of set of tags assigned to eight servers: Table 2 Tags Server Name Tag Names country PALO_ALTO_1 PALO_ALTO_2 NEW_YORK_1 NEW_YORK_2 PARIS_1 PARIS_2 NICE_1 NICE_2 Tag Values USA USA USA USA France France France France city Palo Alto Palo Alto New York New York Paris Paris Nice Nice department engineering sales engineering sales engineering sales engineering sales product widgets widgets gadgets gadgets widgets widgets gadgets gadgets
In this example, each server has four tags. Four servers are located in the United States, and four in France. Four servers belong to the Product group gadgets, and four to widgets. Four are in the engineering Department, and four in the sales Department. The servers and tags shown in this table are used in examples in the following sections.
Aliases
Aliases identify the different listen ports configured for a TIBCO Enterprise Message Service server, and are used by rules to create routes between server pairs. You assign an alias to each listen and fault tolerant listen address: port assigned to a server in the Central Administration Client. Aliases are used only by Central Administration, and have no application outside of the Central Administration project. When creating routes between servers with multiple listen ports, you must specify an alias to identify the ports on either end of the route. The given alias name must be defined for both servers. That is, the alias name must be the same, but the alias definition can vary. For example, consider two servers with these settings: Server1 has listen port t c p : / / j m s 0 1 : 7 2 2 2 with alias P R I M A R Y _ L I S T E N Server2 has listen port t c p : / / j m s 0 5 : 7 2 2 4 also with alias P R I M A R Y _ L I S T E N
Because both servers have defined listen ports using the alias P R I M A R Y _ L I S T E N , you can use a rule to create a route between the servers. Aliases are only used by rules to create or delete routes. If you do not have multiple listen ports or if you do not use rules to manage routes, then you do not need to define aliases. If you are using rules to manage routes, then keep these important points in mind: If you have multiple listens, you must define aliases. If an alias is defined, it must be entered in the Create Route rule action panel. The same alias name must be defined for all servers selected by the rule.
14
| Chapter 2
Rules
A rule is a selection of servers and an action. The selection of servers is determined by the application of tags, and the action is applied to all servers in the selection. You can use multiple tags to create the server selection, but the rule is limited to one action. There are two ways to select servers using tags. The first method selects all individual servers that match the specified tags. The second method uses tags to select pairs of servers. Both methods allow you to enter multiple selectors (or tags) to narrow the list of matching servers. When multiple selectors are entered, a server or pair of servers must match all entered selectors. That is, the selectors are applied using an AND operator. Wildcard values are not supported in rules or rule sets. You must enter tag names and values in their entirety, as they are configured in the Server editor. Select by Server Tags The Select by Server Tags method of defining a group of servers allows you to enter multiple tag Name-Value pairs in order to narrow down a list of servers. A server must match all listed tags to be a member of the final selection. For example, consider the servers in Table 2. You could select a group of servers with the tag Name-Value pairs: country is USA department is sales
The resulting selection would include two servers: P A L O _ A L T O _ 2 and NEW_YORK_2. Select Two Servers by Tags The Select Two Servers by Tags method of choosing a selection defines pairs of servers, and is primarily useful for creating routes between servers. This method selects the first server in the pair, then selects the second server in the pair. There are three ways to select server pairs:
Add Server One selects the first server in the pair using tag Name-Value pairs.
This is the same method used to select a server using the Select by Server Tags rule type. However, this selection applies only to the first server in the pair. The second server in the pair is unaffected.
Add Server Two selects the second server in the pair using tag Name-Value pairs. This selection applies only to the second server, and does not affect the selection of the first server.
Add Match selects both servers by requiring matching tag values. This selection method requires that you enter tag names but not values. The rule then compares the value set for the tag in Server One, and the value set for the tag in Server Two. If the values match, the servers are a match. The tag names that you specify can be different. Only the tag values are compared.
You can use any combination of these methods to create a list of server pairs. For example, consider the selections show in this screenshot (based on the configuration shown above in Table 2): Example 1 Select Two Servers by Tags
In this example, the Select Server One and Select Server Two methods are each used twice, and the Add Match method is used once: Server One must have the tag country with the value USA, and the tag department with the value sales. Server Two must have the tag country with the value France, and the tag department with the value sales.
TIBCO Central Administration Concepts
16
| Chapter 2
Server One and Server Two must both have the same value for the product tag.
These selections result in two server pairs: PALO_ALTO_2 and PARIS_2, which are both sales servers managing widgets, and NEW_YORK_2 and NICE_2, which are also both sales servers, but which manage gadgets.
Rule Sets
A rule set is a list of one or more rules that are executed together. All rules are created within a rule set, and you can use a rule set to apply multiple actions to the same selection of servers.
Selection
Rule sets also offer the Selection tab, which you can use to narrow down the pool of servers that rules in the rule set can operate on. The selection criteria entered in the Selection tab is applied first, before individual rules in the rule set. Only servers that are included in the pre-selected group of servers are available to the rules in the rule set. A rule cannot modify a server that is not in this group. Pre-selecting servers with the Selection tab is optional. If you do not enter any selectors, the rule set considers all servers in the project.
| 17
Chapter 3
This chapter describes the Central Administration Server and its components.
Topics
The Central Administration Server, page 18 The Deployment Server, page 20 The Administration Agent, page 21
18
| Chapter 3
the Central Administration Client and the Central Administration Server, as well as managing the project in the Central Administration Server.
Central Administration Agent provides the connection between the Central
Administration server, the Subversion repository, and the Central Administration Client.
Apache Tomcat services the Central Administration deployment server and
agents.
The Subversion Repository
The Administration Server holds copies of the current configuration of all synchronized TIBCO Enterprise Message Service servers in a Subversion repository. When a new project is created, the Administration Server also creates directory in the Subversion repository to hold configuration files for the servers in the project. Central Administration Clients can make configuration changes to the files in the repository without immediately deploying these changes. When a Client does send a Deploy command, the Central Administration Server updates the deployed Enterprise Message Service server with configuration settings from the repository. Additionally, the Central Administration Server is responsible for enforcing access control restrictions to the server configuration files stored in Subversion. For more information about how access to the TIBCO Enterprise Message Service server configuration files is controlled, see Access Control and Central Administration on page 6.
The Apache HTTPD Server and Tomcat server are generally transparent components of the Central Administration Server. However, certain tasks require you to edit a process configuration file. For example, configuring the Central Administration Server to connect to an LDAP server after installation requires a change to the Apache HTTPD Server configuration files. See TIBCO Enterprise Message Service Central Administration Installation for more information about these tasks.
20
| Chapter 3
1. Keeps track of the Enterprise Message Service servers that are part of its project. 2. Creates a Subversion repository for each project file, and manage the connection between the repository and the Client. 3. Sends deploy and synchronize commands from the client to the agent. 4. Provides the Client with updated configuration files from agents. 5. Validates Client requests, including requests to view configuration files and to save changes to configuration files. In other words, the deployment server validates Central Administration Client requests and conveys commands between the Client, Subversion repository, and Central Administration agent.
1. During a synchronization, it retrieves the Enterprise Message Service servers current configuration. This includes both the initial synchronization with the server and the retrieval of any configuration changes that have been made directly to the Enterprise Message Service server. 2. During a deployment, it updates the Enterprise Message Service server with configuration changes made in the Client. In other words, the agent updates an EMS server with configurations from the Client, and updates the deployment server with any changes from the EMS server. The agent establishes a connection to the Enterprise Message Service server when it receives either a synchronize or a deploy command from the Central Administration Client.
Deployment
Upon a deploy command, the agent retrieves the specified configuration files from the Subversion repository and deploys the changes to the running Enterprise Message Service server. It updates the configuration using a merge action, which compares the configuration files from the repository to the deployed server files and updates the deployed server files. During the first deployment, the agent compares the t i b e m s d servers configuration with the Central Administration configuration that is being deployed. The agent uses the Java Admin API to change the t i b e m s d server to match the new Central Administration configuration. On subsequent deployments, the agent compares the new configuration with the last Central Administration deployment (stored in the Subversion repository), and again updates the t i b e m s d server using the Java Admin API. Note that the agent does not review the deployed t i b e m s d server configuration. It looks only at the latest Central Administration deployment. Because Central Administration does not prevent you from saving or deploying configuration changes containing errors, it is possible to issue a deploy command using files that contain errors, such as illegal parameter values or mutually exclusive parameter settings. If the agent encounters an error during deployment, its default behavior is to quit the deployment and shut down the TIBCO Enterprise Message Service server. You can alter this behavior by setting options in the agent. For more information, see Administration Agent Options in TIBCO Enterprise Message Service Central Administration Configuration and Deployment.
TIBCO Central Administration Concepts
22
| Chapter 3
Synchronization
A synchronize command directs the agent to retrieve the currently deployed server files and deliver them to the Client, overwriting the current configuration in the Client. Note that a synchronize command does not save any changes to the Subversion repository. It only affects the local Client configuration files.
24
| Chapter 3
Conflicts During a Deploy Command Because the Central Administration Server deploys configuration files from the Subversion repository, conflicts in this command are not between the Clients configuration files and the Subversion repository. Conflicts during a deployment occur between the repository files and the deployed TIBCO Enterprise Message Service server files. Most of the time conflicts during a deployment do not generate errors. However, there are two important things to consider: 1. Changes that are made directly to the deployed Enterprise Message Service server are not automatically saved to the Subversion repository. Therefore, they are not included in the merge action during a save to the repository. To save changes from the deployed server in the Subversion repository, you must first synchronize a client with the Enterprise Message Service server and then save the configuration to the repository. 2. The configuration files stored in Subversion take precedence over the deployed server files. During a deployment, the Central Configuration agent overwrites a deployed configuration file with the modified file from Subversion. Any . c o n f file that has been modified is included in the deployment. This means that any changes manually made to the deployed file are overwritten. Deploying Configuration Files with Conflicting Settings The Central Administration does not require that all settings be complete or consistent when a configuration file is saved to Subversion. This allows you to save without resolving any problems, but also means that you could potentially deploy a configuration that contains internal errors. For example, creating an RVCM listener without assigning a name and saving the file prints an error in the Problems view. However, the error does not prevent you from completing the save, and the Central Administration Server does not then prevent you from deploying the illegal configuration. If the Central Administration agent encounters illegal or invalid parameter values or combination, it exits the deployment and shuts down the TIBCO Enterprise Message Service server.
| 25
Chapter 4
Advanced Features
This chapter describes advanced TIBCO Enterprise Message Service Central Administration features.
Topics
The Application Programming Interface, page 26
26
| Chapter 4
Advanced Features
The Java API can be accessed through the HTML documentation set.
| 27
Index
A
access control 6 administration agent 21 aliases 13 API 26, 26 architecture 3
J
JavaDoc 26
P
permissions 6 problems view 11 projects project navigator 9
B
benefits 2
C
central administration server 18 conflicts resolving synchronization 23 customer support xiv
R
rules 16
S E
eclipse editors 10 views 11 editors 10 EMS status view 11 EMSCA_HOME xii ENV_HOME xii security 6 Subversion security 6 support, contacting xiv
T
tags 12 technical support xiv TIBCO_HOME xii
28
| Index
V
views 11 EMS status view 11 problems 11