Migrating to Domino and WebSphere from Earlier Versions

     

In this section, we discuss the issues around migrating from earlier versions of Domino and WebSphere products. Since both products are in their fifth or greater major release, many customers will be moving to the latest versions from earlier installations.

Migrating to Domino 6

Before you integrate Domino with your WebSphere server, it would first be a good idea to update your Domino server to the latest version (that would be Domino 6.5 when this section was written). This section gives some useful information on how to go about upgrading your version of Domino.

Version 6 of Lotus Notes and Domino from IBM was a significant upgrade and should be the basis for your Domino platform. If you have been using an earlier version of Domino, this section describes the steps for migrating Domino R5 servers to Domino 6. Here are the benefits and interoperability issues of upgrading to Domino 6.

Interoperability Issues

When planning the type of migration to undertake, you must decide whether to go for the "big-bang" approach in which you migrate all servers in parallel (typically over a weekend or holiday) or whether to stick to a more practical (and more often chosen ) alternative of phasing in the migration. The latter approach involves running and maintaining a mixed environment (R5 and Domino 6 servers) for a period of time.

The best practice is to first migrate the servers to Domino 6 and then migrate the clients over time. Using this approach lets the servers stabilize before you migrate the clients (this method is low risk, proven, and recommended in most scenarios for practical reasons).

The Domino 6 Administration client can administer a mixed release of servers; however, some limitations exist. The Domino 6 release notes and Administration Help database (http://doc.notes.net/domino_notes/Rnext/help6_admin.nsf) define these restrictions in detail.

Migration Preparation Steps

The following steps are essential in the preparation process. Skipping them will result in a failed migration or will significantly increase the risk of a migration that appears successful but has hidden issues that users will eventually discover.

  1. Understand Domino 6 and its enhancements. You'll probably need to undergo this exercise to define the business case for migration, but it's important that everyone in the administration and migration teams are aware of the benefits migration provides.

    It's recommended that you install the Domino 6 Administration and Notes clients on your administrator machines long before you undertake an actual upgrade. Be careful not to conduct any design changes in the R4 or R5 databases, using the Domino 6 Designer client until a complete migration has been successful ( otherwise , you may encounter potential problems and even corruption of the design components ).

  2. Carefully plan the schedule of the upgrade. The migration of servers will almost certainly occur during evening hours or over a weekend. Make sure you have sufficient time to complete all tasks and that you can put precautions in place should issues arise. Thoroughly understanding the upgrade process and remembering to not attempt too much at once are essential for a successful plan.

  3. Conduct a full system and application audit. This audit should cover both the servers and the applications that run on the servers. Typically, you should document the results in a table or Notes database that can be shared by or published to all stakeholders (e.g., administrators, designers, and application owners ) for sign-off.

    For each server, you should capture the following information: server name , IP address, network ports enabled, Domino version, OS level and service packs , purpose (e.g., mail, app), user types (e.g., browser, Notes client), physical location, type (e.g., hub, spoke), and the servers that act as the administration server and directory server.

    It's also important to work with key people in the administration team and user community and document any existing issues with the servers (that way, problems cannot be blamed on or attributed to the upgrade.

    For each application, you should capture the following information: application name, owner, purpose, user community, method of access (e.g., browser, Notes client), template used, level of changes (if any) to the standard templates, code duplicated from templates, use of undocumented or unsupported coding features (these could change with Domino 6), whether the app is a mail-in database, all creative workarounds, all accessible Notes databases and external databases or files, all Notes API or OLE functionality, and a list of servers this database replicates to (and the use of any selective replications).

  4. Conduct a test server migration. Not only is setting up a test environment a good way to learn about and play with the Domino 6 functionality, but it also ensures that you conduct a trial upgrade of the server and that you test applications thoroughly before migration. After all, you want to know the product is stable in your environment and with your applications, data, policies, and procedures.

    By setting up a test environment that closely reflects that of your production environment, you'll know your upgrade procedures work, the results are as expected, and above all, you've practiced the migration before touching production systems. If test hardware is an issue, consider using the virtual server product VMWare (http://www.vmware.com) to create multiple virtual machines on a single server. This product is ideal for testing a multi-server migration.

  5. Test application migration. Once you're happy with the upgrade process, you should thoroughly test key business applications (including mail) to ensure that functionality hasn't changed. It's essential that you copy the application and production data so you can test this data in isolation. By doing so, you'll know this data works in the test environment before you upgrade. Ad hoc testing by the migration team is often insufficient, so you should work with the application's business owners to draw up a structured test plan and sit with a knowledgeable user of that system as he conducts the test (with you capturing any unexpected results or variations)

    Next , you need to consider the results of the application audit conducted in Step 3. You'll have to make changes if the standard templates have been modified or if undocumented features or creative workarounds have been made in the coding. Working with the application's developers before testing will help you prepare the application for migration.

Migration Steps

The following steps define the best practices and considerations for conducting the actual migration. Note that Lotus will support a mixed-client environment with a Domino 6 server infrastructure because organizations will often upgrade the servers first (as according to best practices) and then upgrade clients over time.

  1. Upgrade the Domino Administrator client. Be sure you upgrade the Domino Administrator clients used to administer the Domino network to the latest Domino 6 release long before you conduct the subsequent migration steps. Doing so will give you time to familiarize yourself with the Domino 6 Administration client variations. It's important you consider any interoperability issues that may exist in your environment; you can establish such issues by carefully reading the Domino 6 Administration Help database.

  2. Upgrade the Administration server and Domino directory. Before shutting down the Administration server, purge the Administrations Request (AdminP) database by issuing the tell AdminP process all command. Once all processes have been completed and you've emptied the AdminP database, you can shut down the server and install the Domino 6 server software.

    To properly administer a Domino 6 server, you should also upgrade the Domino directory (but be sure you always migrate the Administration server first). To upgrade the Domino directory, start the server; it will immediately recognize that the Domino directory isn't running on the Domino 6 design and will prompt you to upgrade the design. Answering "Y" (yes) to this prompt lets the server upgrade the design and start as normal.

    Once the server is running, the final task in upgrading the design is to upgrade the database format (known as On Disk Structure or ODS) to the Domino 6 format and rebuild all views in the Domino directory ( Names .NSF). To do this, type the following two commands in the Domino 6 server console:

     

      load compact  

    and once compact has been completed, type:

     

      load updall -r  

    Keep in mind that this can be a time-consuming process, as its duration depends on the number of databases and the size and complexity of the views. Because it's hard to estimate the duration of an upgrade, you should leave plenty of time to ensure the conversion of all databases and the rebuilding of all views. During this process you should test client access to the server to make sure no errors occurred on the logs.

    Once you've compacted all the databases and rebuilt all the views, two more steps remain : upgrading the Administration Requests database and the Web Administration client. To upgrade the Administration Requests database, open Admin4.NSF, and replace its design with the template titled "Administration Requests (Release 6)." If Admin4.NSF is replicated to other servers in the domain, then force a replication to update their design, too.

    The Web Administration database (WebAdmin.NSF) upgrades automatically when you install Domino 6 because the upgrade process deletes the existing database and creates a new one based on the Domino 6 template (WebAdmin.NTF). It's important that you check the Access Control List (ACL) to ensure it has your specific entries.

  3. Replicate the Domino directory. Once you've upgraded the Administration server, replicate the newly updated Domino directory to all servers. Next, rebuild the views of that database on each server (using load updall -r ).

  4. Upgrade hub servers. The next set of servers to upgrade are the hub servers. Because the Domino directory is already upgraded to Domino 6 on these servers, you won't be prompted to upgrade the Directory when these servers are started for the first time. To upgrade your hub servers, perform the following steps:

    Shut down the servers in order by entering the following commands on the console:

     

     tell router quit tell SMTP quit tell HTTP quit quit 

    Complete a full backup and a test restore of each server. Be sure to take soft backups of key files ”Desktop.DSK, all ID files, Log.NSF, Names.NSF, Mail.BOX, all secondary address books, .DIR files, Notes.INI, and all templates ”by copying them to a temporary directory. Now install the Domino 6 software. Before restarting the server, complete the following tasks, where appropriate:

    If the server runs Network News Transport Protocol (NNTP), remove this task from the Notes.INI (NNTP is no longer supported on the server but is on the client). If you didn't use the certification log in R5, then you must create one manually, as this is compulsory in Domino 6. Create a new database called Certlog.NSF from the certification log template.

Restart the Server and Check for Errors

Upgrade databases to the new ODS format by typing load compact on the server console. Once the compact has completed, rebuild all the database views and full-text indexes by typing load updall -r on the server console.

  1. Upgrade spoke servers. The final servers to upgrade are the spoke servers (e.g., mail, applications, and Web). The process to upgrade these servers is identical to that of upgrading the hub servers.

  2. Upgrade clients. Before users can take advantage of Domino 6 mail and application functionality, you must upgrade the client software to Domino 6. Before you install Domino 6 on the client, it's important to ensure that no antivirus software is running, that users have both read/write access to the Notes program and Data directory, and that users are logged in to the computer with administrative rights. Once you've checked all these items, you must choose how you want to upgrade the client, as Domino 6 presents several new options:

    • Upgrade by mail . This feature sends an e-mail to nominated users to upgrade their Notes client. Users conduct an upgrade by clicking the Install Notes button, which launches the Domino 6 client setup from a shared installation directory.

    • IBM Lotus Notes Smart Upgrade . This process notifies users to update their clients to the latest release and uses Policy and Settings documents to help manage the updates. When users log in to their home server (running Domino 6), Lotus Notes Smart Upgrade compares the release number of the users' client against the release number specified in the source version field in the Smart Upgrade database. Users are then prompted to upgrade their client, or they can delay the upgrade for a specified grace period. Please note that Smart Upgrade is a Domino 6 feature. You must first be using Notes and Domino 6, so only subsequent upgrades can take advantage of it.

    • Administrative upgrade . This process uses the Microsoft Windows Installer and copies the installation code to a shared file server that users access through the network. Users launch the installation program and then install Domino 6 locally to their machines.

    Once you've upgraded the client, you can use the new Policies feature in Domino 6 (which replaces setup profiles) to configure Notes client settings for users. These settings include customized welcome pages, bookmarks, and Execution Control List (ECL) settings. To successfully implement policies, be sure you disable any previous setup profiles from R5.

  3. Upgrade mail templates. You're now ready to upgrade the clients' mail templates to Domino 6 so they can leverage the full functionality of the Domino 6 mail client. At this stage, you can also upgrade the mail templates to support iNotes, if required.

    The easiest way to upgrade mail templates is to use the mail conversion utility. To run this process, you must first shut down the router on the mail server by issuing tell router quit on the console, and then establish which Domino 6 mail template you require (or you can select a customized one). The default is Mail6.NTF for Domino 6 mail and iNotes60.NTF for Domino 6 mail with iNotes.

    Next, Domino 6 must find all mail templates of a specific type (the source) and convert them to the destination. To do this, type load convert mail\*.nsf stdr46mail mail6.ntf at the server console, where stdr46mail is the source template and mail6.ntf is the Domino 6 template you've chosen. You'll find variations on the use of this command in the Domino 6 Admin Help database. Once Domino 6 has converted the mail templates, you can rebuild the databases' indexes using the updall -r console command.

    Finally, to re-enable the router, type load router at the console to ensure that mail can be routed. Now, users can start using their new mail templates. It's a good idea to test the full features of mail and calendar/scheduling before signing-off the server as working.

    The actual migration of your R5 server environment to Domino 6 isn't a complicated process ”it just takes time and careful planning. The only big areas of risk are the amount of testing you need to complete and the level of customization you've made to the standard Lotus templates. You should consider these issues when preparing a schedule and be sure to allow enough time and resources for contingency and a worst-case scenario that would require a complete rollback. Once you've migrated the servers and upgraded your clients, developers can start leveraging the full functionality of the Domino 6 environment.

Migrating to WebSphere V5

Before you integrate Domino 6 with your WebSphere server, it would first be a good idea to update your WebSphere server to the latest version (that would be WAS V5.1 when this section was written). This section gives some useful information on how to go about upgrading your version of WAS.

Significant changes have occurred between WebSphere Application Server (WAS) versions 3.5 or 4.0 and 5.0. Even if we go back to WAS 3.5, it does contain a number of elements from the J2EE specification. However, it's not a J2EE-compliant application server. WAS V5, on the other hand, implements the J2EE 1.3 specification. In this section, we'll focus on the migration of V3.5 to V5 since the migration of V4 to V5 is much simpler.

The changes brought in with J2EE introduce a number of direct and indirect issues. Many applications require some changes to code, and the application development tools have changed dramatically. With the introduction of J2EE, the way that applications are packaged is also different. Changes to packaging have an impact on the way that builds are done as well as the process and skills involved with deployment. Code and packaging, however, are only a small part of the overall migration process.

Migration Overview

Application developers tend to think of migration only in terms of the application code; administrators think only of the production runtime. It is important to think of migration in comprehensive terms. This means considering (at least):

  • The development environment

  • Developer skills

  • Administrator skills

  • Runtime environments

  • Required and recommended changes to the application code

A comprehensive assessment is a key element of a successful migration. With careful assessment, you can very accurately plan your migration and put the necessary resources into place. Assessment typically takes between five and 10 days and should involve somebody familiar with WAS 5.0 and WebSphere Studio Application Developer (WSAD).

Bring concerned parties together. Communication between different groups often breaks down over time. The migration assessment is a good opportunity to bring these groups together. For example, developers can often gain a greater appreciation for the issues faced by the administration staff, and vice versa.

High-Level Architecture Review

With the gathering of concerned parties comes an excellent opportunity to describe the existing applications. The architecture review sets the stage for other parts of the assessment by bringing the "big picture" into clearer view. A high-level architecture review should not take more than a couple of hours.

Application Code Review

An obvious part of the assessment process is a review of the application code. This doesn't need to be a full-blown code review; in the context of a migration assessment, you're generally concerned only with discovering the use of non-J2EE-compliant code.

In general, code quality has no direct impact on migration complexity. Complexity is a factor only when significant redesign of an application is required or when the complexity makes it difficult to understand the code.

An application code review typically takes one to two days for each application.

Review the Development Environment

With the change to WAS V5 comes a completely new development environment in the form of WSAD. (VisualAge for Java (VAJ) is not recommended for V5 development.) As part of the assessment, you should review the current development environment to determine how you can adapt the existing practices, tools, and skills to build a new development environment around WSAD.

Assess Development Skills

Software developers familiar with WAS V3.5 may need some skills upgrades to familiarize themselves with J2EE 1.3 and WSAD.

Review the Runtime Environments

Most organizations support a number of runtime environments, each with a different purpose. The configuration of these environments ( potentially including one or more development test, system test, preproduction, and production environments) should be reviewed to ensure that the existing topology, configurations, and hardware are adequate for WAS V5. A review of security requirements and implementation is also an important part of this stage of the assessment. Review of the runtime environments typically takes at least half of a day.

Review the Build and Deployment Processes

Review the existing processes to identify nuances that you may need to consider when the current approach is adapted to use J2EE 1.3 packaging and associated WAS V5 deployment. With the changes introduced with J2EE, it is very likely that many deployment-time tasks (e.g., servlet configuration) will be moved into the build process.

Review and Understand Schedule Issues

Scheduling is always an issue with migration. Most organizations have applications that are constantly changing in response to external business drivers. Working a migration plan around other deliverables can be a daunting task that requires special attention.

Development Environment

If you currently use VAJ, the development environment will likely be one of the biggest changes you make as part of your migration. VAJ 3.5 (or 4.0) is generally not recommended for development of applications targeting WAS V5; for this purpose, IBM recommends one of the WebSphere Studio family of products, such as WSAD. IBM no longer provides technical support for the VAJ products.

The WebSphere Studio family includes several products:

  • WebSphere Studio Site Developer (WSSD)

  • WebSphere Studio Application Developer (WSAD)

  • WebSphere Studio Application Developer Integration Edition (WSAD-IE)

  • WebSphere Studio Enterprise Developer (WSED)

WebSphere Studio development tools are very different from VAJ. VAJ is a relatively closed environment intended primarily for Java development. But WebSphere Studio development tools are intended for all kinds of development, including components to build and edit Java, J2EE, and Web site content (HTML, images, and other resources).

WebSphere Studio development tools gain their flexibility through a large collection of "plug-ins" that provide all functionality. The base product contains a very comprehensive set of plug-ins that provide everything from Java editing and debugging to J2EE component construction and testing (via a WebSphere Test Environment plug-in) to XML editing and manipulation (via XSLT).

WebSphere Studio is built using open-source Eclipse technology, so it can be extended with Eclipse-compatible plug-ins (WebSphere Studio 5.0 is based on Eclipse 2.0). A large open-source community has already constructed hundreds of plug-ins that provide a variety of different kinds of functionality. Chances are, if you need WebSphere Studio to do something that it doesn't do already, somebody in the open-source community is already working on a plug-in.

All the WebSphere Studio products except WSAD provide J2EE application development support with increasing levels of extended support. WSAD provides everything you need to build, test, and deploy J2EE applications. WSAD-IE extends the J2EE support with support for integrating J2EE with legacy applications using JCA connectors, business process choreography, and other features. If you're accessing host systems using Enterprise Access Builders, then WSAD-IE may be the best choice for you. WSAD adds support for additional legacy enterprise development and includes additional rapid application development tools.

With the impending retirement of VAJ, its integrated team environment Visual Team Server (also known as "Envy") is also retired . WebSphere Studio doesn't support Team Server as a source code repository, so as part of the migration effort, you must select a new source code management (SCM) tool.

WebSphere Studio development tools support several third-party SCM solutions, including Rational ClearCase, CVS, and others using vendor-supplied plug-ins. With this change, all application artifacts (Java code, JSPs, XML, and property files) can now be stored in the same SCM, which makes it much easier to manage these resources and keep them synchronized. Unfortunately, there is no built-in mechanism for extracting an existing version history from Team Server into an alternate SCM tool, so this process is largely manual. (It is possible to write a VAJ tool that can automate some part of this process.)

If you're already using a third-party SCM with VAJ, you may need to modify your existing project folder and artifact hierarchy as part of the migration. Version 5 of the WebSphere Studio development tools requires that application code be structured along J2EE packaging lines. For example, Web components must be in a Web Project, and Enterprise JavaBean (EJB) components must be in an EJB Project. Each of these projects has its own folder hierarchy. Modifying existing project hierarchies in an SCM (while maintaining the history of the various components) can be difficult and time-consuming.

Your development team may use other tools as well. You'll need to evaluate these tools to determine their appropriateness for WAS V5 development. Replacements may be required. For example, WebSphere Studio products provide tools for XML authoring, which may be appropriate replacements for third-party XML tools.

Developer and Administrator Skills

Because WebSphere Studio development tools are very different from VAJ, expect your developers to require some time to fully develop the skills required to use the product effectively. Typically, five days of classroom training are sufficient for developers who are familiar with enterprise application development using VAJ. Every migration plan should include mentoring for the development team to guide them through their first few weeks with J2EE and WebSphere Studio tools.

Due to fundamental changes to the administration model, scripting, and tools, administrators will also require training. With the adoption of J2EE packaging, administrators have less to do when deploying an application, but configuration and maintenance of the application server instances are still their responsibility. Much of the terminology has changed with 5.0, and XML-based configuration files have replaced the administration database. Managing a collection of WebSphere nodes is still a task that requires dedicated administrators with specialized skills.

Even skilled administrators will benefit from formal training. Five days of classroom training are typically enough to arm seasoned WAS administrators with the information they need to install, configure, and maintain WAS V5.

Runtime Environments

When you think of runtime, the production runtime environment springs immediately to mind. Most organizations, however, have more than one runtime environment. It's common to have development test, system test, performance, and preproduction environments as well. Other environments with other purposes may also exist.

Rarely is the migration of a runtime environment a simple matter of shutting everything down, installing new hardware, and starting everything back up. This may be possible for development test and system test environments, but other runtime environments have restrictions that make such practices impossible . In almost every case, the production runtime environment must stay in service while it is migrated. Very often, very limited downtime is acceptable for even the preproduction environment.

Migration of a production runtime is even more complex if you have multiple applications with different development teams and different delivery schedules. In this sort of environment, it may be necessary to run both versions of WAS concurrently for a time. Unfortunately, WAS V5 cannot run applications packaged for V3.5 without modification. (Version 5, however, can run applications packaged for V4 without modification.)

Depending on your runtime configuration, it may be possible to do a "rolling migration." In this scenario, application servers are upgraded individually or in small groups using the following steps:

  1. Select one or more (possibly an entire domain of) application server nodes.

  2. Remove the selected nodes from the load balancer's routing tables.

  3. Remove the nodes from service (shut down).

  4. Remove WAS V3.5 or make it dormant on the selected nodes.

  5. Install, configure, and test WAS V5 on the selected nodes.

  6. Install, configure, and test the migrated application code.

  7. Activate WAS.

The process is repeated for the remaining nodes.

This is a very simple overview of a rolling migration and may not necessarily be appropriate for your configuration. (This scenario assumes that you have at least three application servers providing at least 50 percent more capacity than you require.) The first node to be migrated would become the first server in a new WAS V5 cell. As additional nodes are migrated, they are added to the cell. Each WAS V3.5 domain you have in your current configuration will likely become a cell in your new configuration.

Any migration plan should include a back-out strategy. In the above steps, we suggest that you make V3.5 "dormant." Rather than completely removing the installation of 3.5, you can instead simply shut it down (and configure your system not to start it) and remove its plug-in from the HTTP server. If later testing reveals that the migration didn't work, it is then a relatively easy matter to reinstate the 3.5 instance.

If you have multiple applications, the rolling migration may take weeks or even months (with the unmigrated applications remaining on the V3.5 nodes). If you have a single application, or if all your applications are migrated before the runtime migration, the rolling migration may be accomplished in a matter of hours or days. In either case, you must consider that you will need to support (at least for some period of time) a runtime environment that contains a mix of nodes running WAS V3.5 and V5.

The mix of versions has some interesting implications. To start, if two different versions of an application are running on different versions of WAS, you must make sure that the application appears consistent to the user. That is, the application should look and act the same on both application server versions.

For example, if your applications make use of HttpSession state, you may consider introducing (if you have not already done so) server "stickiness" to ensure that all requests from a particular user are directed to the same server instance. Unfortunately, HttpSession state cannot be shared by different versions of WAS. This also has a potential impact on failover.

If your application is split physically across tiers, you may need to consider interoperability options. It is possible to connect from servlets running in WAS V3.5 to EJBs running in V5, but several fix packs are required to make this work.

As part of the migration, you may need to update your hardware, operating systems, and other components (such as the HTTP server). WAS V5 prerequisites are well documented.

Try your runtime migration plans in a test environment before starting the migration of your production runtime.

From a system administration perspective, migration is more than just installing new products. Some of your existing practices and process may need to be considered as well. The scripting languages of WAS V3.5 (WSCP or XMLConfig) are no longer supported with V5. They're replaced by the evolving JMX standards. Any scripts you currently use to administer your servers will need to be revisited and likely rewritten (there are currently no tools available to automate this).

Planning Is Key

Because every organization and application is different, every migration experience will be different. We've outlined many of the issues you must consider. More specific information about migration is detailed in the IBM Redbook, ''Migrating to WebSphere V5.0: An End-to-End Migration Guide," at http://www.redbooks.ibm.com.

Migration involves more than just the code or any single environment. Even if no change is required to your application code, migration will still take time when you consider all the other aspects.

Application Code

Application code is the first thing that most people think of when considering migration. Organizationally, the structure of the code often requires significant change; J2EE requires that the various application artifacts be structured in a particular way. However, the amount of actual change required to the code itself may be very small. Most of your Java code should migrate without change. Even some of the J2EE artifacts such as servlets, Java ServerPages (JSPs), and Enterprise JavaBeans (EJBs) may work without modification on the new version.

As part of the migration of application code, you must consider the following:

  • Code organization

  • Changes to the specifications

  • Use of proprietary technologies

  • Third-party libraries

J2EE defines a very specific packaging structure that separates the various artifacts into different archives. Web artifacts (including servlets, JSPs, and Web content such as GIF and JPG files) are packaged in a Web archive (WAR) file. EJB artifacts, typically consisting of the EJB types, are packaged in an EJB file (also known as a Java archive (or JAR) file. An enterprise archive (EAR) file is used to collect all the application components (WAR and JAR files) into a single file.

Other libraries (JAR files) used by the application can be located in the EAR file, as well. The archive can also contain application client archives, which are another J2EE module type. Note that an XML deployment descriptor is packaged with each module. The deployment descriptor describes the organization of the components in the module and how they're configured at runtime.

Specifications

The various specifications that make up J2EE have evolved somewhat since WebSphere Application Server V3.5. Some of the specifications (e.g., JDBC) have changed very little. Others (e.g., EJBs) have changed dramatically. The extent to which the changes will affect you depends, of course, on which parts of the specifications your code makes use of.

Some minor changes have been made to the servlet specification. Methods such as HttpSession.getValue(String) have been deprecated in favor of renamed equivalents such as HttpSession.getAttribute(String) . Perhaps the most significant change to the servlet specification has to do with session scope. The more recent versions of the servlet specification limit the HttpSession scope to the Web module. That is, it's not possible (according to the specification) for multiple Web modules to share HttpSession data.

In previous versions of the servlet specification (including those supported by WebSphere Application Server V3.5), a single HttpSession scope is shared by all applications. If your application code depends on this semantic, it must be changed. To make migration easier, WAS V5 provides an option that permits HttpSession state to be shared by multiple Web modules packaged within a single .ear file. This deviation from the specification is provided as a convenience, and its use should be limited.

Version 1.2 of the JSP specification, as supported by WebSphere Application Server V5, is largely compatible with version 1.1 (supported by WAS V3.5), and JSPs coded to that level of the specification should migrate with little difficultly. However, WAS V3.5 supports three versions of the JSP specification. Any JSPs written to the 0.91 specification may require significant modification if bean tags are used (scriptlet and expression tags should migrate relatively easily).

As part of the migration of servlets and JSPs, you must build a web.xml deployment descriptor. At very least, all the servlets in your Web module should be named and have initialization parameters provided (WebSphere Studio tools provide support for doing this). We strongly recommend that you name your servlets in the deployment descriptor; IBM discourages continued use of the WAS class name server, and it is disabled in WAS V5 by default.

EJBs have changed considerably between WAS V3.5 and V5; the most significant changes involve entity beans. With EJB 1.1, XML-based deployment descriptors replaced the serialized deployment descriptors supported by previous versions. WebSphere Application Server V3.5 actually supports "EJB 1.0+" by including some parts of the EJB 1.1 specification, which may mitigate some of the impact of the migration.

There are two ways of getting existing EJBs into a WebSphere Studio project. The existing EJBs can be packaged into an EJB 1.0 .jar file (with source code), and that .jar file can then be imported into an existing WebSphere Studio EJB Project. When importing the .jar file, WebSphere Studio tools recognize the serialized deployment descriptor and will create appropriate entries in the deployment descriptor for the contained beans.

This process does a reasonably good job of importing basic EJB information, such as the types involved, JNDI names, and transaction attributes. It does not consider Container-Managed Persistence (CMP) entity bean-persistent field mapping information, however. If your application makes use of CMP entity beans, you should consider using the EJB 1.1 Export Wizard included with VisualAge for Java 4.0. This Wizard generates an EJB 1.1-compliant .jar file (with source) that can be imported into WebSphere Studio projects. The exported .jar file contains all the deployment information required to make CMP entity beans work, preserving the existing persistent field mappings and finder queries. Of course, the Wizard generates EJB 1.1-compliant beans that must be upgraded to 2.0. The J2EE Migration Wizard available in WebSphere Studio products (except WSSD) can help in this regard.

Once the code is imported into a WebSphere Studio project, additional changes may be required. Neither of these migration processes actually modifies any code, so you may need to address other changes to the specification ( java.rmi.RemoteException should not be thrown by business methods in EJB 2.0, for example). Many of these changes are only deprecations that you can address at some later time. Others, however, must be addressed before the beans can be deployed and tested .

Servlets, JSPs, and EJBs will likely take up most of your migration effort, but they probably won't be the only things you must consider.

Proprietary Technologies

In this context, "proprietary technology" refers to features not governed by standards. The Connection Manager provided with WebSphere Application Server V3.0 is an example of an IBM solution that was provided to fill a gap in the J2EE standards at the time. The Connection Manager was deprecated in WebSphere Application Server V3.5.x in favor of standards-based data sources, but it's still supported in WAS V5. If your application makes use of this technology, it will eventually need to be changed.

Perhaps the most commonly used example of proprietary technology is the various code builder technologies included with VisualAge for Java. For most of these builders, the generated code works with little or no modification on WAS V5, but there is no support (other than directly editing the generated Java code) in WebSphere Studio development tools.

Third-Party Libraries

All versions of WAS treat third-party libraries the same as your application code. Libraries composed of "just Java" code should continue to work without modification on WebSphere Application Server V5. However, libraries that have dependencies on particular versions of WAS may need updating. To complicate matters, most library vendors don't provide source code or permission to change their code, which can potentially leave you at their mercy to provide support.

As part of the migration effort, you should contact third-party vendors and ask them to provide compatibility statements for WAS V5. Then, you should test their compatibility with V5 extensively. This should be done relatively early in the migration cycle so you can find alternatives, if necessary.

Reference Cycles

One of the most common general issues encountered when migrating code from VisualAge for Java to WebSphere Studio development tools is reference cycles. A reference cycle occurs when a class in one project refers to a class in a different project that refers back to a class (possibly the same class) in the first project.

Reference cycles between classes in different packages or projects are generally considered to be bad programming because they introduce tighter coupling between components. WebSphere Studio tools' build process stops when a reference cycle between projects is detected . VisualAge for Java has no problem with reference cycles and does nothing to discourage their use.

Unfortunately, though, this is one area where WebSphere Studio tools don't provide much help. Third-party tools such as SmallWorlds (http://www.thesmallworlds.com) can help to identify reference cycles and help you find potential solutions for them.

Other WebSphere Migration Aids

Because every organization and application is different, every migration experience will be different. This section has outlined many of the issues you must consider. More specific information about migration is detailed in the IBM Redbook, "Migrating to WebSphere V5.0: An End-to-End Migration Guide," at http://www.redbooks.ibm.com (see the Bibliography for more details on this Redbook).



IBM WebSphere and Lotus Implementing Collaborative Solutions
IBM(R) WebSphere(R) and Lotus: Implementing Collaborative Solutions
ISBN: 0131443305
EAN: 2147483647
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net