What's new in WebSphere Application Server V7

An overview of important new features


IBM WebSphere Application Server delivers an agile, solid foundation for Service Oriented Architecture (SOA) applications to align innovation in both business and IT. WebSphere Application Server enables the reuse and creation of applications and services that promote business agility, both anticipating and adjusting to the mission-critical issues that help businesses win in the marketplace.

WebSphere Application Server V7 builds upon the powerful and stable core of previous releases with several new features and enhancements. In addition to support for the latest standards and programming models, V7 contains key improvements in the areas of systems management, installation, and security. Together, these features further expand on WebSphere Application Server's platform coverage, run time management capabilities, and application deployment options to help you decrease costs and grow your businesses even more.

This overview introduces some of the key features that enable this new release to provide an even more flexible and reliable foundation for your SOA environment.

Get a trial version of WebSphere Application Server V7 now!


WebSphere Application Server V7 now includes new support for:

  • Java EE 5

    The most notable supported standard in WebSphere Application Server V7 is Java™ Platform, Enterprise Edition (Java EE) 5. WebSphere Application Server V7 provides complete support for the Java EE 5 specification, including the Web services and EJB 3.0 functions that were previously available as feature packs in V6.1.

    In case you’re not familiar with Java EE 5, this latest release of the standard represents a significant evolution in the Java enterprise programming model, resulting in considerable improvements in the application developer experience and, in turn, in application developer productivity. A phrase often used to describe the Java EE 5 programming model is progressive disclosure, meaning that much of the "boilerplate" code that has –- until now -- been required for Java EE development is eliminated. Instead, the most generally used application context is provided as the default behavior, then, using annotations, you can override the defaults, if required, to achieve the required implementation. In this manner, the application is progressively constructed, and only to the extent necessary.

    WebSphere Application Server V7 also introduces support for Java Platform, Standard Edition (Java SE) 6.

  • Dependency injection

    Developer productivity is further enhanced when it’s time to override the defaults, since this can be accomplished quickly and simply using annotations rather than writing code. Annotations are used in conjunction with a programming pattern known as dependency injection, or Inversion of Control (IoC), in which the application code simply declares variables and annotates them to indicate whatever is needed, and then the container "injects" the specified object or resource references.

    Figure 1 shows a simple example to help explain dependency injection. The code segment on the left is from an EJB 2.1 application. The one on the right, from an EJB 3.0 application, has an annotation @EJB that is used to tell the container that this is an EJB; the container then "injects" the EJB 3.0 application with the required wrapper (or boilerplate), eliminating the need for you to do so.

    Figure 1. Dependency Injection
    Figure 1. Dependency Injection
    Figure 1. Dependency Injection
  • Java Persistence API

    Another aspect to the simplification of the programming model in Java EE 5 is the ability to develop EJB components as Plain Old Java Objects (POJOs). Simplifying EJB development even further is the Java Persistence API (JPA), which enables entities to be created using annotated POJOs. Aside from making EJB development and usage even easier, this also enables Java SE developers to quickly learn Java EE and develop enterprise applications. Figure 2 compares the code for an EJB 2.1 entity bean and an EJB 3.0 entity bean. As with the comparison shown in Figure 1, annotations play a key role in making it easier to develop with EJB 3.0. In Figure 2, the @Entity @Table (name ="CUSTS") annotations indicate that this is an entity EJB using the table CUSTS, and the key for the table is defined as the field ID via the annotation @ID.

    Figure 2. Annotated POJOs
    Figure 2.  Annotated POJOs
    Figure 2. Annotated POJOs
  • Web services

    The improvements to the Java EE 5 programming model aren’t limited to EJB development. Web services development is also greatly simplified via annotations. In Figure 3, a Java EE 1.4 JAX-RPC application is depicted on the left and the corresponding Java EE 5 JAX-WS application is depicted on the right.

    Figure 3. Web services development
    Figure 3.  Web services development
    Figure 3. Web services development

    The JAX-WS implementation in WebSphere Application Server V7 also provides support for SOAP 1.2, as well as for generic XML or HTTP as a protocol binding, which enables the creation of WS clients and WS providers that do not use SOAP for their wire level message format.

    Another important addition in WebSphere Application Server V7 is its support for Message Transmission Optimization Mechanism (MTOM), an improved method for sending binary attachments. MTOM is the preferred attachment mechanism for non-Java EE-based Web services, so support for MTOM improves the interoperability between Java EE Web services and non-Java EE Web services.

  • Portlet 2.0 API

    WebSphere Application Server V7 also introduces support for the Portlet 2.0 API, also known as the Portlet JSR 286 specification.

Systems management

Systems management is another major area enhanced in WebSphere Application Server V7, with a number of new management and administration options to help you implement a more flexible, scalable, and asynchronous administrative topology, and to help you reduce cost and increase effectiveness as well:

  • Intelligent provisioning

    First on the list is intelligent provisioning by the WebSphere Application Server runtime, which selects only the run time function needed for an application, reducing both memory footprint and application server startup time. Each application is examined by WebSphere Application Server at application installation time to generate an activation plan; at run time, the server starts only those components that are required by the activation plan.

    WebSphere Application Server V7 contains support for a Web/JDBC application scenario in which only the Web container and core run time components are started. This is in contrast to V6.1, in which the EJB container, SIP container, and Web services runtime would also have been started, as shown in Figure 4. This capability is also used in fixed function servers (for example, WebSphere Application Server proxy server) to help reduce the memory footprint, and is designed for extension by other WebSphere products that run on top of WebSphere Application Server.

    Figure 4. Running an application
    Figure 4. Running an application
    Figure 4. Running an application

    Additional run time footprint reductions are delivered in the form of the Java SE 6 implementation that ships with WebSphere Application Server V7. The shared class cache that was introduced in IBM's Java SE 5 implementation has been improved so that the cache can now be persistent. As a result, the cache can survive a shutdown and restart of all WebSphere processes on a server. In the case of an application developer running a single WebSphere Application Server instance, the contents of the shared class cache can be reloaded on application server startup, and when used independently -- or in combination with intelligent provisioning -- the result is significantly faster application server startup times.

    Another improvement in IBM's Java SE 6 is the use of compressed references (or pointer compression) in 64-bit WebSphere Application Server JVMs. The use of compressed references can provide a very significant reduction in the process footprint of a 64-bit JVM, when previously compared to a 32-bit JVM. Prior to IBM's Java SE 6 implementation, it wasn’t unusual for a 64-bit heap to be 1.7 to 2 times the size of an equivalent 32-bit heap.

  • Administrative agent

    Flexible management is an improvement that can help reduce the cost of administering large deployments in several ways. The easiest way to illustrate this new feature is by comparing the WebSphere Application Server (base) V6.1 run time model to what is provided by flexible management in V7. In V6.1, the adminstrative runtime is hosted in WebSphere Application Server, meaning the administrative console runs in an application server. When wsadmin scripts are run against an application server, each application server process has administrative overhead as a result. There is also no provision for managing multiple "base" application servers profiles; each must be managed independently, as depicted in Figure 5.

    Figure 5. Multiple base profiles
    Figure 5. Multiple base profiles
    Figure 5. Multiple base profiles

    Flexible management changes this picture by separating most of the administrative components from the application server runtime. Now, each application server is no longer a single point of management. This is accomplished with a separate administration process for (base) WebSphere Application Servers know as the administrative agent, shown in Figure 6.

    Figure 6. Admin agent
    Figure 6. Admin agent
    Figure 6. Admin agent

    You might wonder if moving the administration function from the application server to the admin agent provides more capability. The answer lies in the fact that an admin agent can manage multiple WebSphere Application Server (base) instances on a single machine, as shown in Figure 7. When using an admin agent, as the number of application server instances increases the duplication of the administration footprint (for each application server) is eliminated. Further, since the admin agent can manage all the application server instances on a machine, there’s only one set of remote administration ports to remember (those for the admin agent), as opposed to trying to manage all the separate administration ports associated with each application server.

    When working with the admin agent, remember that:

    • The admin agent can only manage the application servers that are on the same machine as the admin agent.
    • Although the admin agent can manage multiple application servers, each application server is managed individually. In other words, you would log into the admin agent to change the configuration of server1, log out, then log on to server2, and so on.
    • The admin agent only provides management of these application servers (and their applications) -- it does not provide for clustering and failover. For clustering and failover and centralized application management, you still need WebSphere Application Server Network Deployment.
    Figure 7. Admin agent managing multiple application servers
    Figure 7. Admin agent managing multiple application servers
    Figure 7. Admin agent managing multiple application servers
  • Job manager

    The job manager is another aspect of flexible management that is available in WebSphere Application Server Network Deployment V7 (hereafter referred to as Network Deployment). As with the admin agent, it might be best to describe how the job manager functions by quickly reviewing the run time model for V6.1, which is shown in Figure 8.

    Figure 8. V6.1 run time model
    Figure 8. V6.1 run time model
    Figure 8. V6.1 run time model

    In Network Deployment, there’s a tight coupling:

    • Between application server(s) and node agent(s).
    • Between node agent(s) and the deployment manager.

    This tight coupling can impact the scalability of the administrative runtime if the run time components are not located together in close proximity. A possible example might be a branch office deployment, where a deployment manager in a central location is being used to manage nodes dispersed in each remote branch office. Even under the best of conditions -- redundant, high capacity, low latency networks between the central location and the branch offices, and so on -- this can be problematic simply because Wide Area Networks (WANs) are rarely as reliable as Local Area Networks (LANs), and both are known to occasionally fail.

    The job manager in Network Deployment addresses the limitations inherent in the current management architecture by adopting a loose management coupling architecture: rather than synchronously controlling a number of remote endpoints (node agents), the job manager coordinates management across a group of endpoints by providing an asynchronous job management capability across a number of nodes. The management model relies on the submission of management jobs to these remote endpoint, which can be either a WebSphere Application Server (base) admin agent or Network Deployment deployment manager. In turn, the admin agent or the deployment manager is what actually executes the jobs that update the configuration, start or stop applications, or perform a variety of other common administrative tasks.

    The management model provided by the job manager is shown in Figure 9. It’s important to know that the job manager is not a replacement for a deployment manager; rather it’s an option for remotely managing a Network Deployment deployment manager or, more likely, multiple deployment managers. Recall the above example, trying to manage multiple remote nodes from a single deployment manager; with the job manager, each branch can be converted into its own Network Deployment cell with a deployment manager running locally in each branch, and the job manager can be used to remotely manage each of these remote cells.

    Figure 9. Job manager management model
    Figure 9.  Job manager management model
    Figure 9. Job manager management model

    This new capability sets the stage for a number of more advanced deployment and management topologies, shown in Figure 10.

    Figure 10. Advanced topologies
    Figure 10.  Advanced topologies
    Figure 10. Advanced topologies

    Again, the job manager isn’t a replacement for a Network Deployment cell or the deployment manager. Table 1 further clarifies the capabilities provided by the job manager versus the deployment manager. As you can see, there is very little overlap in the run time capabilities provided by Network Deployment and the management capabilities provided by flexible management, and vice versa. Stated another way, flexible management isn't a replacement or an alternative for the enterprise capable run time qualities of service provided by Network Deployment; rather, flexible management extends the management capabilities for both WebSphere Application Server V7 and WebSphere Application Server Network Deployment V7.

    Application server management featureDeployment managerJob manager
    Remote administrationyesyes
    Fine-grained administration via consoleyesno
    Administration when administrative process is down (local connectivity)yesno
    Clustering: Workload managementyesno
    Clustering: Failoveryesno
    Plug-in based HTTP request routingyesno
    Data replication (Memory-based session replication)yesno
    Centralized backup/Restore of configurationyesno
    Server performance monitoringyesno
    Scheduling of administrative functionnoyes
  • Web services

    Another important new systems management capability in V7 is in the area of Web services, in addition to the programming model improvements mentioned earlier. Web service policy sets are mechanisms provided by WebSphere Application Server V7 for centrally defining various quality of service polices that you might want to apply to Web services that are already deployed. There are two types of policy sets:

    • Application policy sets are used for business-related assertions, such as business operations that are defined in the WSDL file.
    • System policy sets are used for non-business-related system messages, such as messages that are defined in specifications that apply QoS policies. Examples would include security token (RST) messages that are defined in WS-Trust, or the creation of sequence messages that are defined in WS-Reliable Messaging metadata.

    Rather then defining individual policies and applying them individually to each Web service, policy sets can be applied once to all Web service applications to which they are applicable, thus insuring a uniform quality of service for a given type of Web service. Related to this, WebSphere Service Registry and Repository will discover WebSphere Application Server V7 JAX-WS policy sets, as well discover existing associations, and represent those as policy attachments. A number of default policy sets are provided:

    • LTPA WSSecurity Default
    • Kerberos V5 HTTPS default
    • SSL WSTransaction
    • Username SecureConversation
    • Username WSSecurity default
    • WS-Addressing default
    • WSHTTPS default
    • WS-I RSP ND
    • WS-ReliableMessaging persistent.

    Additionally policy sets can be customized or modified as required.

  • Messaging

    Beyond the Web services improvements in WebSphere Application Server V7, there are also improvements to a related SOA component: messaging. New administrative wizards for System Integration Bus (SIBus) configuration are provided for configuring a cluster bus member and a foreign bus connection, as well as new panels for SIBus authorizations, WebSphere MQ JCA Resource Adapter configuration, and for inspecting an application's use of SIBus resources.

    V7 also includes a WebSphere MQ JMS JCA 1.5 resource adapter, as well as associated new panels and administrative commands. Having the JCA 1.5 resource adapter also means that message-driven beans that consume messages from WebSphere MQ can now use activation specifications instead of listener ports.

    Improved management of activation specifications -- stop, start, message retry limits (or "poison" message filtering) -- is also included in WebSphere Application Server V7.

  • Centralized installation

    Network Deployment also adds the capability to perform centralized installation from the deployment manager to remote nodes. This enables a single installation to the deployment manager to be pushed out as an installation package from the deployment manager to a series of endpoints. The endpoint can be either a node that is not part of a Network Deployment cell (in which case Network Deployment can be installed) or an existing Network Deployment node that might need a fix pack.

  • Business level applications

    Another new function in WebSphere Application Server V7 is a the notion of an "application" beyond J2EE™, or a business level application (BLA). This is a new administration concept that expands upon what was previously provided by J2EE. Cases where this can be of value include those where an application:

    • Is composed of multiple packages.
    • Contains additional libraries, or non-Java EE artifacts.
    • Includes artifacts that run on heterogeneous (WebSphere and non-WebSphere) runtimes.
    • Is defined in a recursive manner; for example, if an application includes other applications.

    Essentially, a BLA is a grouping notion for managing Java EE and other artifacts under a single application definition, as shown in Figure 11. A BLA can span more than WebSphere Application Server deployment target runtimes, such as a proxy server, Web server, WebSphere Application Server Community Edition, and so on. Further, a BLA provides full lifecycle management of applications: install, distribute, activate, monitor, update, and remove.

    Figure 11. Business level applications
    Figure 11. Business level applications
    Figure 11. Business level applications
  • Security

    Security management and auditing improvements are also a significant portion of what’s new in WebSphere Application Server V7. Perhaps the most prominent change is the capability to create multiple security domains within a single WebSphere Application Server cell. Each security domain can have its own user population (and underlying repository), and, additionally, the application domain can be separated from the administrative domain. Not only can each domain have its own separate user population, but each domain can also be customized with a separate security configuration -- for example, JAAS login configuration, TAI, authorization provider, JCA authentication data, and auditing -- in addition to the current application server level security configuration options. The scope of the domain is variable and can range from a cell, cluster, or node to a node group or application server. As a result, applications have a distinct user population and distinct security configuration, shown in Figure 12.

    Figure 12. New application security
    Figure 12. New application security
    Figure 12. New application security

    Further, the fine grained administrative security function that was introduced in WebSphere Application Server V6.1 but limited to wsadmin is now expanded in V7 to include the administrative console. Within the administrative security domain for a cell, this enables administrative roles to be restricted to specific components, such as a cluster, node, application server, or application.

  • Auditing

    Another security enhancement is the option to generate security auditing records of WebSphere Application Server administrative actions. These actions can be security configuration changes, key and certificate management, access control policy changes, bus and other system resources management, and so on. This feature enables you to hold administrative users accountable for configuration and run time changes.

    Further, the review and control of audit records and audit configurations is entrusted to a new auditor role, which enables the separation of administrative user privileges, in that an administrator cannot change audit policy and cannot view audit records, nor can an auditor change WebSphere configuration and run time state. An example of the output from the new audit system is shown in Figure 13.

    Figure 13. Audit output
    Figure 13. Audit output
    Figure 13. Audit output
  • Kerberos

    WebSphere Application Server V7 provides support for Kerberos Authentication, which can be used in a variety of single sign-on scenarios. The Kerberos support in V7 expands on the SPNEGO TAI support in V6.1 to provide better interoperability and identity propagation with other applications that support Kerberos authentication (such as IBM DB2®, .NET®, and others).

Application development and management

WebSphere Application Server V7 includes two tooling options for application development that let you leverage the standards supported in this new release:

  • IBM Rational® Application Developer Assembly and Deploy V7.5 replaces the Application Server Toolkit (AST) function provided with WebSphere Application Server V6.1. This development tool expands on the functions provided in the AST with Java EE 5 XML-form based DD editors, Java EE 5 application support, and more.
  • IBM Rational Application Developer V7.5 for WebSphere adds functions to Rational Applicatiion Developer Assembly and Deploy, including EJB 3 application development productivity features, visual editing domain modeling and Web development, Web services productivity features, and relational data tools.


IBM WebSphere Application Server V7 is a major release that offers dramatic run time improvements, plus simpler and easier ways to develop and deploy applications. This article presented a high level glimpse of many of the new features and enhancements that make these improvements possible.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=What's new in WebSphere Application Server V7