![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
There are two restrictions in a WebSphere installation that affect naming:
- All server control regions must connect to the same RACF Group ID.
- Server names must match the WLM application environment names.
This best practice applies to the following product, version, and platform:
- WebSphere Application Server for z/OS and OS/390, version 4.0.1, OS/390 and zSeries
There is no such thing as a universal and perfect naming convention. Each installation will have unique naming requirements. Nevertheless, there are a few things you should design into your naming convention:
- An indication that the resource is related to WebSphere for zOS. For example, the letter "W" as part of the name.
- An indication of the WebSphere node to which the resource belongs. For example, the letter "T" as part of the name to indicate "test" and the letter "P" for production.
- An indication of the system (or LPAR) on which the resource belongs, if the configuration is a multi-system sysplex. Some WebSphere resources are directly related to a system and others are not. Specifically, server instances (base servers and application servers) are system-specific. The generic server names are not, nor are RACF IDs, WLM applications or JCL procs.
Important: There's an interesting topic that comes into play here. This set of recommendations assumes you'll be establishing different environments for "test" and "production" (and perhaps QA and others). There are several different ways you can configure this, and it does not always imply separate WebSphere "nodes". (See the Resource section of this document for pointer to information on "Test and Production" environments.) It might not imply separate systems or LPARs either, but the best practice is to provide space for those indicators, even if you don't actually need them based on your present configuration. You may grow later, and you will be glad that you planned for it.
Keep in mind that changing the naming scheme of a WebSphere node is almost impossible once it's been configured and initialized. It therefore makes good sense to invest time in planning the naming convention before you commit it to your server.
The following charts can be used to assist in mapping out your naming convention:
Figure 1. Common Definitions
A partial example follows to illustrate the concept.
Figure 2. Example of Common Definitions
Important: The system and LPAR are not indicated, since these "Common Definitions" are not system-specific; they are common across the entire WebSphere node.
Figure 3. Base Server Definitions
Using the SMS Server as an example, you might see:
Figure 4. Example of Base Server Definitions
Figure 5. LDAP Definitions
An example of this would be:
Figure 6. Example of LDAP Definitions
Figure 7. J2EE Application Server Definitions
Note: The CBIND and SERVER values are typically longer than 8 characters thus showing an 8-byte grid was not meaningful. They should, however, still have a meaningful name. You can carry the same naming convention used in the other resource names into those names as well.
And the example:
Figure 8. Example of J2EE Application Server Definitions
The various components of the WebSphere installation have to be named something, there is no alternative to that.
WebSphere for zOS imposes almost no restrictions on the names you provide the various components of the WebSphere installation. The only restrictions were stated earlier: the control region RACF IDs must have a common Group ID and the server name (not instance name, but server name) must be equal to the WLM application environment name. So there is a great deal of flexibility in how the naming convention is structured.
As stated earlier, there is no universally perfect naming convention. Every installation will have a different spin on this. The key message here is to use a meaningful and consistent naming convention because changing the naming convention after the fact is very difficult. Anticipate growth and factor the ability to designate multiple nodes and multiple systems into your naming convention. You may not have a need for that initially, or ever, but it provides you with the capacity for growth.
-
Considerations for establishing test and production environments - Establishing test and production environments and naming conventions are related. An understanding of the test/configuration options available will help you understand how to better construct your naming convention.
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
- Buy: Rational Application Developer
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
