Defining Required Hardware and Software

The specific hardware and software required for your development effort will depend on many details of your application and the chosen platform. The primary goals of the development environment are to do the following:

• Enable the isolated development, execution, unit testing, and debugging of the application on each developer s workstation

• Provide a centralized location for running, unit testing, and debugging a coordinated daily or weekly development build of the application

• Provide a centralized source-code management (SCM) repository and database for use by developers and the common build of the application

• Simulate the production hardware and software platform at a level sufficient to support development and debugging

Most J2EE applications will require at least two servers in the development environment to host the source-code management (SCM) server software, the development database, and the development build of the J2EE application. It is common to combine the SCM software and development build on the same server, yielding the following set of hardware and software requirements in the development environment:

• Developer workstations with WebLogic Server, development tools, database-client software, source-code management client, and build scripts and tools

• Development server with WebLogic Server, Web server software, database-client software, source-code management server and repository, and build scripts and tools

• Database server with RDBMS software and any required legacy-system integration software

Each server and workstation in this environment has a specific role in the development process.

Developers use the workstations to construct the individual components of the application and create local (workstation-based) builds for unit testing and debugging. In addition to all development tools and SCM client applications, the workstations also require a copy of WebLogic Server configured with the appropriate connection pools, JDBC DataSource resources, JMS destinations, and other supporting infrastructure required to run the application. Unless the development team is very small and can share a single development server for builds, you must provide local execution capability for developers on their own workstations.

Best Practice  

Provide local execution capability on developer workstations to avoid resource conflicts on the shared development server.

If it becomes impossible to provide local execution capability for some reason, you may be able to segregate the shared development server and provide an isolated environment to support each developer s execution and testing needs. The easiest way to segregate the server is to create separate domains for each developer with the servers defined in each domain configured to listen at a different port. The developers will still compete for server resources (CPU, memory) but will be able to run multiple copies of the application simultaneously . Again, this is not ideal. It is better to provide local execution capability on each workstation, if at all possible.

The development team uses the development server to host the shared source-code management (SCM) repository and as a central location for making and testing periodic builds of the application. We ll discuss the importance of periodic builds and regression testing in a later section. This server also provides an environment more similar to the production environment. A Web server is installed on the machine and is configured to proxy appropriate JSP and servlet requests back to WebLogic Server, for example, and the development server usually matches the vendor and operating system present in production. Often developer workstations are Windows-based machines while the development, test, and production servers are Unix-based systems.

Best Practice  

The development server should match the vendor and operating system of the test and production machines. Developer workstations may use a different platform, if desired.

The database server is used to host the common development database supporting both developer workstation builds and the central development build of the application. Gateway products and other legacy-system integration products also belong on this server, in our opinion. There is no strong reason to separate the database server and development server apart from the desire to mimic production as early in the process as possible. Production will undoubtedly include separate servers for the WebLogic Server cluster and the database, so it makes sense to provide this separation in development as well if the budget allows.

Sharing a common development database between multiple developers and the common development build sounds good on paper, but there is at least one significant problem with this simplistic approach that we need to solve: Changes to the database schema can break builds. For example, one developer may need to modify a database table to support the components he or she is changing and testing on his or her workstation. The database modification is very likely to break the build for all other developers and for the common development build, especially in a CMP entity bean application. Remember that the server checks the database schema for every bean during deployment, and nothing will deploy if there is a schema problem with any of the beans in the EJB archive!

The classic approach is to serialize the development process during database changes. Essentially, you make the database change, and the entire team waits for the developer to finish the changes, test them, and make the new versions of the components available in the current branch of the application. Everyone retrieves the new copy of the component from the SCM system and is able to build and run the application again. Although this approach might be appropriate for small teams or in some circumstances where it can be done very quickly, it simply becomes an untenable solution on a large project.

Fortunately, there is at least one reasonable solution that provides support for existing builds and for developers requiring database changes: create multiple copies of the development database on the development server, either as separate instances or separate schemas in a single instance. In its simplest form, this technique requires two complete copies of the database, called for our purposes DEVDB1 and DEVDB2. As shown in Figure 13.1, the common development build and the builds used by different developers connect to whichever copy of the database matches the components in that build.

Figure 13.1:  Multiple databases support different builds.

In a two-database approach such as this, often a primary database is used for the periodic builds and an alternate database used for development of components requiring database changes. The database administrator usually toggles back and forth as each new set of changes is made, meaning that DEVDB1 is primary until the changes in DEVDB2 are made part of the common build, at which point DEVDB2 becomes primary and DEVDB1 is used for subsequent database changes. Clearly this technique can be extended to three or more databases, but two are usually sufficient.

You enable this database-switching behavior in the WebLogic Server application by creating multiple JDBC connection pools in the domains on the developer workstations and the development server. Ensure that all application components acquire database connections through a JDBC DataSource resource, then simply switch the connection pool associated with that DataSource as needed to reference the correct database.

Best Practice  

Use multiple copies of the development database to support builds requiring different database definitions. Switch databases using domain configuration parameters.

You can refine this technique quite a bit if it makes sense in your environment. For example, tables that rarely change can be stored in only one database with synonyms or database links in the other database to provide visibility to the data from both versions. Developers might also have their own accounts in the database with synonyms to a shared set of all tables except the tables they need for development. Because these alternatives add complexity and represent additional work for the database administrator, it is usually best to keep things simple and have two completely separate databases with no synonyms or links between them.