If you consider EAServer's management GUI, Jaguar Manager (and Security Manager), to be the product's face, then in 5.0 EAServer received a facelift. After a couple of releases with only minor changes, 5.0 includes a number of dramatic additions and changes to its management GUI, both internally and externally significant. This article will address the most notable of these, although there remains a lot more for the eager user to explore.

What You'll Notice Right Away
The first change you'll see is the way in which Jaguar Manager and Security Manager are delivered. For starters, it's not called Jaguar Manager anymore; it's now referred to as the more aptly named EAServer Manager. Second, it's no longer a single stand-alone plugin into Sybase Central 3.2; both EAServer Manager and Security Manager are now plugged into Sybase Central 4.1 and can be used simultaneously with other Sybase Central plugins, such as that delivered with ASE 12.5.1. The upgrade from Sybase Central 3.2 to Sybase Central 4.1 maintains the same usage patterns, but upgrades the usability, the performance, the memory usage, and the help system. It also includes Section 508 compatibility, which along with subtler changes means that dialog controls and menu items now have keyboard accelerators, making it much easier to navigate using the keyboard. This Sybase Central change does mean the relocation of some files, for those of you who poke your nose under the covers. No longer are the Sybase Central files located in the easmgr folder in the EAServer directory structure; they're now located in the sybcent41 folder in the Sybase directory structure. This allows EAServer to share Sybase Central with other plugins, like ASE, and even between multiple installations of EAServer on the same machine.

Another obvious change is the way Security Manager is presented. In previous releases, when you launched Jaguar Manager the certificate management portion of the management GUI was moved into a separate hierarchy, as shown in Figure 1. This led to some confusion, as it wasn't immediately apparent to the user that the certificates being managed were in fact in EAServer. In EAServer 5.0, certificate management has been folded into the EAServer Manager hierarchy under the Certificates node, as shown in Figure 2. The Standalone Security Manager remains the same.

One obvious but fairly minor change is the alphabetizing of the main-entity categorization nodes (Agents, Clusters, Servers, etc.). You can see this difference by again comparing Figure 1 to Figure 2. This admittedly will cause confusion, even irritation, initially as you retrain your eyes to look in the right place, but once this period is over you'll find it a real improvement. In a similar manner, the context menus have been slightly reorganized, putting the Properties menu item at the more standard position at the bottom of the menu, and renaming commands to be more industry standard.

Wizards, Wizards, and More Wizards
EAServer has always had the ability to configure most server properties quickly through the GUI; while this is friendly to expert users, new users have struggled with configuration and setup. In EAServer 5.0, no less than 14 new wizards have been introduced, with more coming in subsequent releases. These include Creation/Configuration wizards, Debug Settings wizards, a Container-Managed Persistence Configuration wizard, Stub/Skeleton Generation wizard, Configuration Repair wizards, and Performance Tuning wizards. The wizards all share the same look and feel, presenting the user with an explanatory introduction page (that can be turned off to avoid it becoming annoying), a one property per page with explanation approach, and a summary page on each wizard to allow users to verify their selections before proceeding. A sample of each of these pages can be seen in Figures 3-5. No changes are applied in these wizards until the Finish button is chosen, and the Finish button is enabled as soon as possible to allow knowledgeable users to proceed as soon as they see fit. Every effort has been made to make these wizards both informative and efficient. (see Figure 3) - (see Figure 4) - (see Figure 5)

The Creation/Configuration wizards are designed to guide the user through the most important and most commonly set properties for complex entities, such as Clusters and Servers. The Cluster Creation/Configuration wizard presents the user with detailed information on how to set the following properties: name, description, primary server, participating servers, name servers, heartbeat detection, load balancing, startup mode, and synchronization. For new clusters, properties are defaulted to their most likely values, such as iiop://hostname:port for primary server, where hostname and port are picked up from the connection information that you used to log in to the server.

The Server Creation/Configuration wizard presents the user with detailed information on how to set the following properties: name, description, listeners (via a Listener Setup subwizard), and security (via a Security subwizard). Like the Cluster wizard, new servers have their properties defaulted to logical values, such as setting up default listeners for your new server.

The Debug Settings wizards are designed to guide the user through the numerous settings useful in debugging the operation of your server for a variety of entities, including components and servers. The Component Debug Settings wizard explains and allows the users to set the component debug, component tracing, instance pool debug, and cache timeout properties. The Server Debug Settings wizard walks the user through the Java VM debug style, JPDA Port, JVM verbose, JVM verbose garbage, and message service debug mode properties. On a personal note, I highly recommend setting the JPDA Port as this will save you from having to read the server console each time you want to debug your Java code. By hard coding it to a specific port, you always know which port to use.

The Container-Managed Persistence (CMP) Configuration wizard is a recognition of the fact that CMP beans can be difficult and sometimes frustrating to set up. This wizard aids you in setting up the connection cache, table name, field mapping, automatic key generation, query mapping, concurrency control, and optimistic concurrency control properties. This wizard is also very adaptable, as it presents users with specific information based on their choices from the preceding pages. Table names are automatically queried based on the connection cache; column names are then automatically queried for use in setting up field mapping; and specific automatic key generation information is provided based on the generation type.

The Stub/Skeleton Generation wizard was overdue in many ways. Designed initially as a simple dialog with a few options, it was added to over time until it evolved into an overly large and complicated dialog. Those options have now been split into three main pages, plus a summary page as always. First is the Stub Generation Options page, where you specify options relating to stub generation, such as whether to generate Java and/or C++ stubs, and whether to generate the stub .java files into a .jar file or a directory.

There is also a new option, Generate Dependent Classes, that applies only to EJB stubs. The second page is the skeleton generation page, which for the first time allows you to specify whether to generate the skeletons on the client or on the server, in addition to allowing you to decide whether to compile the Java skeleton files. The third page is for advanced options such as whether to use full, incremental, or optimistic generation. In most cases you'll want to leave the options on the third page the way they are, so you can just hit the Finish button on the second page most of the time.

The idea behind the Configuration Repair wizards was to make sure users have properly bound J2EE resources to their appropriate EAServer resources. Some J2EE resources, such as roles, EJB references, resource references, and environment entries, need to be mapped to their application server-specific properties. For example, an EJB may have been configured to be accessible only by members of the PowerUsers J2EE-defined role. That PowerUsers role was defined by the EJB developer and may not necessarily even exist yet in the application server. It may not have the same name in the application server, but without establishing a mapping between the PowerUsers role and an EAServer role the application server is unable to verify that the user is a member of the PowerUsers role and allow the user access.

Another common example would be resource references. An EJB developer may have set up a java.sql.DataSource resource reference, but this reference is useless without linking it to an application server connection cache. This has been done for J2EE entities such as applications, components, connectors, packages, and Web applications. Configuration Repair wizards allow users to choose whether they want to view all related properties or only those properties that need to be configured.

The Performance Tuning wizards are designed to be both informative and diagnostic. For components, servers, and Web applications the wizards present the properties that most affect performance and make recommendations as to which setting changes should be made to improve performance. Like the Configuration Repair wizards, users can choose to view all performance-related properties or view only those that the wizard recommends changing.