Platform

WebLogic Server 9.0 is the most significant BEA Java application server release to date. Fully compliant with J2EE 1.4, this release tackles head-on the biggest challenge facing enterprise networks today: reducing overall cost of management and operations while delivering high reliability, continuous uptime, scalability, and mission-critical integration solutions.

Since WebLogic 9.0's released, numerous people have said "Give me three reasons to upgrade to WebLogic 9.0." Because WebLogic 9.0 is so feature-rich and performance-driven, we can easily come up with 10 major reasons.

Reason 10: Enhanced Web Services and SOA Architecture Now SOA Comes to its Prime Time
WebLogic 9.0 delivers a consolidated and fully integrated Web services stack. BEA has pioneered some of the significant technologies in the Web services field, such as annotations-based Web services programming and conversational Web services. Web services conform to all of the requisite J2EE and most of the important WS-* specifications. Support for asynchronous, conversational, reliable, and secure Web services has also been enhanced.

In a world of new Web services, you will enjoy:

• A next-generation Web services programming model
• Improved performance for conversational Web services
• More flexible, secure, and reliable asynchronous Web services
• Support for long-running, asynchronous, and reliable message exchange
• Reduced complexity
• A streamlined and standards-based programming model via JSR-181 JWS-based Web services
• Eases authoring of Web services

Reason 9: JMS - The Proud Enhancement of WebLogic 9
WebLogic Server 9.0 introduces major changes in the configuration, deployment, and dynamic administration of WebLogic JMS. It officially supports the JMS 1.1 specification. What is more, the long waiting advanced message ordering feature is added to the system. The XML API has been enhanced for XML message processing. On WebLogic 9.0 platform, using JMS is fun, reliable, and fast. Below are a few highlights of the exciting new features.

Automatic JMS Failover
Automatic JMS failover is a long waiting feature in the industry. JMS leverages the feature "Automatic WebLogic Server Migration" to provide automatic JMS failover. JMS will automatically get failed over when the whole WebLogic Server instance is failed over. Some other JMS server providers have provided such functions with some tricky setup, but the WebLogic 9.0 implementation is most straightforward and clear.

Unit of Order
Message ordering is one of the fundamental requirements of major messaging applications. WebLogic Server JMS will guarantee the sequential processing of messages even in the cluster environment. It is even possible to define multiple groups to group the messages so that each group has its own sequence for processing (Figure 1).

Store and Forward (SAF)
The WebLogic store and forward (SAF) service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. The power of the SAF makes it easy link multiple message services together (Figure 2).

Reason 8: Side-by-Side Deployment - A Dream Comes True
Every J2EE developer has experienced the pain of releasing a new version of the product. After numerous development cycles and QA cycles, finally it is time to deploy the new version to the application server. A weekend is booked to shut down the servers, swap the new version of product in, and then pray there is no issue on Monday. If you are lucky, only a few issues will show up. However if you are not in luck then you have to roll back the old applications, and it is even more painful than deploying the new version, because sometimes you can not roll back all of the changes (Figure 3).

You wish you could have multiple versions on the application server and could switch between each version without interrupt the system.

Now your dream comes true. Side-by-side application deployment controls the process for deploying new versions of Web-based applications without the need to disrupt service. The new version of an application is deployed alongside existing version - WebLogic will gradually migrate traffic. The older version is un-deployed after all current clients complete their work. The Administrator explicitly un-deploys the older version, or a configured timeout is reached.

Rolling back the new version is simple: just stop the redeployment process if problems are detected in the newer application version.

For new applications, administrators can deploy an application in "administration mode," which makes it inaccessible to non-admin clients, in order to do sanity checks to ensure that the application is working as expected and then open it up to clients.

Here is the list of the features of side-by-side deployment of WebLogic 9:

• Multiple application versions can coexist
• Test versions before opening up to users
• Roll back to previous versions
• Automatic retirement: graceful, timeout, immediate
• Creates version-aware application artifacts/resources
• Reduces hardware, software, maintenance, and support costs

JSR-88 is part of the J2EE 1.4 specification. JSR-88 specifies a standard API for the configuration and deployment of J2EE applications. WebLogic 9 not only implements the JSR-88, but also offers a number of value additions on top of what J2EE specifies.

Reason 7: The WebLogic Diagnostics Framework: Reduced TCO
The mission of WebLogic Diagnostics Framework (WLDF) is to reduce the customer's Total Cost of Ownership through significant diagnostic enhancements. WLDF is laced throughout all of the BEA WebLogic Server 9.0 containers, thus creating a unified framework for the nondisruptive control of data collection that is critical to the health of your enterprise applications. This framework will capture and archive meaningful diagnostic data that may be used to monitor and diagnose problems that arise in a running server. WLDF is a unified framework and a public API so that you can easily plug your applications into the framework to take advantage of the diagnostic capabilities of the server.

WLDF consists of a number of components that work together to collect, archive, and access diagnostic information about the server and the applications it hosts. All of the framework components operate at the server level and are only aware of server scope. All of the components except for the Manager exist entirely within the server process and participate in the standard server life cycle. All artifacts of the framework are configured and stored on a per-server basis. The WLDF Manager provides a configuration and control interface for managing the diagnostic framework. Additionally, the WLDF Image Capture facility provides a model for capturing a diagnostic snapshot of key server state. It provides a minimally invasive means of diagnosing and troubleshooting the server.