InfoCenter Home > Transitioning to Version 4.0This article is written for users of IBM WebSphere Application Server Version 3.x who are upgrading to Version 4.0. Version 4.0 is fully compliant with Java 2 Platform, Enterprise Edition (J2EE) specifications, which has caused many changes in the organization of the product relative to that of Version 3.x. J2EE creates a clear separation between development (creating the application) and administration (installing and managing the application). This separation enables the development of applications that are independent from the environments in which they are deployed. In addition, J2EE task separation simplifies the process of promoting an application from initial development up through production, or of moving an application from one server to another. In each of these cases, changes to application code are not necessary; only deployment parameters might change. Version 4.0 supports J2EE task separation through reorganized interfaces. In Version 3.x, developers used the administrative console to create, edit, and view applications. In Version 4.0, developers use the Application Assembly Tool (AAT) to create, edit, and view J2EE applications. In Version 4.0, each application is installed into the server domain and bound to an environment when the application is installed. This enables administration at the application and module level. Administrators no longer need to manage individual servlets, JSPs, or beans. The relationship between applications and application servers has changed in J2EE. An enterprise application can contain many Web modules and EJB modules. Each module can be installed onto a different application server or server group, even if the servers or server groups are on multiple nodes. As a result, a single application can contain many modules, spread over many application servers or server groups. Likewise, a single application server or server group can have modules from many different applications installed on it. After a J2EE application is created, you install it onto application servers through the administrative console. Through the administrative console, you can view installed modules either by the application to which they belong or by the application server on which they are installed. Modules can be started and stopped individually as well as collectively. Modules can be started collectively by either starting the application to which they belong or starting the application server on which they are installed. Modules can be stopped in a similar way. Deploying new J2EE applicationsThere are two steps involved in creating J2EE applications: copying the appropriate files into the archive (classes, JSPs, HTML, image files, and so on) and creating deployment descriptor files for the modules and applications. In Version 4.0, the AAT supports both steps by enabling users to copy files with appropriate relative paths into the archive, as well as by providing a GUI method for defining deployment descriptors. Developers can also set environment-specific binding information through the AAT. These bindings are used as defaults when the application is installed through the administrative console. In addition, users can define IBM extensions to the J2EE specification, such as allowing servlets to be served by class name. To ensure portability to other application servers, these extensions are saved in a separate XML file from the standard J2EE deployment descriptor. Role-based securityVersion 4.0 security is consistent with J2EE role-based security specifications. Roles are specified in the deployment descriptors for an application; these roles are then bound to users or to groups when the application is installed. In the aministrative console, a Security Center enables you to perform all security tasks from a single location. This encompasses everything from changing the binding information for roles in an application to setting SSL properties to enabling security. Application-specific security tasks can also be done through the property sheets for each application. Redeployment of previously installed applicationsIn Version 3.x, all tasks were performed through the administrative console. In Version 4.0, application settings are defined in J2EE deployment descriptors through the AAT. Unless you must change information that affects the bindings of an installed application, you can edit and save the deployment descriptors in place. To redeploy such an application, open the AAT directly on the installedApps folder that holds the application. You can also create or edit applications manually. For example, if you need to add a JSP or change a servlet class, you can simply place the new or changed file in the appropriate location in the installedApps folder. To redeploy an installed application that requires changes to binding, you export the application through the administrative console, edit the application in the AAT, and reinstall the application through the administrative console. Because existing binding information is saved during the export step, the only additional binding information needed is for the components or modules added during editing. Important: For security and consistency, Web application URLs are now case-sensitive on all operating systems. For details, see the related information. Support for J2EE resource typesIn addition to JDBC drivers and datasources, several resource types were added in Version 4.0: URLs, JMS, and JavaMail. In each case, you can create a resource provider (JDBC drivers, URL providers, and JMS providers) and then create resource factories for each provider (datasources, URLs, JavaMail sessions, JMS destinations, and JMS connections). In the case of JavaMail, the default JavaMail provider is not shown in the administrative console, because it is not configurable and additional JavaMail providers cannot be created. J2EE impact to models and cloningIn Version 3.x, many different types of objects can be modeled and cloned. With the switch to J2EE compliance in Version 4.0, only application servers can be cloned. These models are now called server groups, and each server group can contain multiple application servers, or clones. Where to go next for more informationFor more information about J2EE, visit the following Web site: http://java.sun.com For more information about changes in configuration support, see the related information. For information about how to upgrade to Version 4.0, see Migration. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|