 | Level: Introductory Tom Alcott (alcott@us.ibm.com), Consulting IT Specialist, IBM
26 Sep 2008 IBM® WebSphere® Application Server V7 has powerful new
features and dramatic enhancements to help you achieve heightened productivity,
stronger security, tighter integration, and simplified administration. Find out
about some of the new key features that enable this new release to provide a
flexible and reliable foundation for your service-oriented architecture.
Introduction
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!
Standards
| Join the chat!
On October 16, WebSphere Application Server experts will answer your
questions about the new features and capabilities of Version 7 during a live online chat.
Mark your calendar and visit
the chat page for
details. |
|
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
-
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
-
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
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
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
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
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
-
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
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
This new capability sets the stage for a number of more advanced deployment
and management topologies, shown in Figure 10.
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 feature | Deployment manager | Job manager |
|---|
| Remote administration | yes | yes | | Fine-grained administration via console | yes | no | | Administration when administrative process is down (local
connectivity) | yes | no | | Clustering: Workload management | yes | no | | Clustering: Failover | yes | no | | Plug-in based HTTP request routing | yes | no | | Data replication (Memory-based session replication) | yes | no | | Centralized backup/Restore of configuration | yes | no | | Server performance monitoring | yes | no | | Scheduling of administrative function | no | yes |
-
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
-
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
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
-
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.
Summary
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.
Resources Learn
Get products and technologies
About the author | 
| | Tom Alcott is consulting IT specialist for IBM in the United States. He has been a member of the Worldwide WebSphere Technical Sales Support team since its inception in 1998. In this role, he spends most of his time trying to stay one page ahead of customers in the manual. Before he started working with WebSphere, he was a systems engineer for IBM's Transarc Lab supporting TXSeries. His background includes over 20 years of application design and development on both mainframe-based and distributed systems. He has written and presented extensively on a number of WebSphere run time issues. |
Rate this page
| |
