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
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
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.
Here is the list of the features of WLDF:
- Introduces a unified diagnostic framework that provides the blueprint for continued BEA enhancement
- Improves the overall visibility of WLS and stack products to alleviate blind spots in monitoring and diagnosis
- Improves control and real-time tunability of the character and quantity of diagnostic data available to the diagnostician
- Introduces additional diagnostic tools to aid in the apprehension and resolution of system faults
- Provides more clearly defined interfaces and tools for instrumentation of customer applications for diagnostics
- Used across WL Platform
- Helps prevent need for Support to issue custom instrumentation patches
- Instrumentation of application and WLS classes
- Watches and Notifications to trigger alerts
- Request dyeing (spans JVMs!): Diagnostic Context for Reconstruction and Correlation of Events
- Fine-grained control - turn the volume up or down
- Data visualization via Console extension:
https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=s96 - Programmatic access via JMX
WebLogic 9.0 Administration Console offers a totally redesigned user interface that features standardized and improved look and feel and navigation across all of the subsystems. It is built on the WebLogic Portal Framework. Although using portal slows down the startup process of the admin console, it makes it more open and readily extensible - applications can plug in extensions to the Console if they need to.
Among the new features are:
- Improved navigation and user interface design.
- New "change center" to control Domain Configuration Changes. Using the Console, administrators can "batch" changes to their WebLogic Server configuration, thereby making changes predictable and reliable. Upon the administrator's command, all of the configuration changes in a batch are distributed across the domain and applied to all the servers; if they are unacceptable to any of the servers, they are rolled back across the entire domain! They are then kept in a pending state awaiting further action from the administrator.
- New application deployment and configuration tools, including assistants for installing applications, more configuration screens, and new deployment and redeployment controls for production applications. Additional Console updates enable you to assign values more easily to deployment plan variables when deploying an exported application.
- The WebLogic Diagnostic Service, with many new features for configuring, collecting, and viewing diagnostic information in a run-time environment. You access the service through the Console. See Centralized Diagnostic Service with More Visibility and Run-Time Control (Figure 4).
- The Administration Console can now be extended in the same ways in which portal applications generally can be extended. In addition to adding and replacing content, a Console extension can add a node to the navigation tree and change aspects of the Console's appearance, such as colors or branding images (Figure 5).
- Configure, start, and stop WebLogic Server instances
- Configure WebLogic Server clusters
- Configure WebLogic Server services, such as database connectivity (JDBC) and messaging (JMS)
- Configure security parameters, including managing users, groups, and roles
- Configure and deploy your applications
- Monitor server and application performance
- View server and domain log files
- View application deployment descriptors
- Edit selected run-time application deployment descriptor elements
WebLogic 9.0 has extended the zero downtime concepts to the next level by introducing the MAN/WAN clustering. It offers enhanced HTTP session replication capabilities that enable "Disaster Recovery" across WebLogic Server clusters connected via wide-area (WAN) or metropolitan-area networks (MAN).
HTTP Session Replication over MAN
Applications can configure the backup for the HTTP session replication to be in another WebLogic Server cluster. In the event that the primary WebLogic Server cluster becomes unavailable, HTTP clients can be routed to the secondary WebLogic Server cluster (Figure 6).
This feature assumes the availability of a high-speed interconnect between the two WebLogic Server clusters and relies heavily on correct configuration of the global and local load balancers.
HTTP Session Replication over WAN
This is ideal for disaster recovery centers (DR sites). Applications can configure a second backup for HTTP session replication in another WebLogic Server cluster. WebLogic Server will asynchronously forward HTTP session data to this second backup where it would get persisted in a database. In the event the primary WebLogic Server cluster becomes unavailable, HTTP clients can be routed to the secondary WebLogic Server cluster (Figure 7).
Given that the replication to the second backup is asynchronous, failed-over HTTP clients may encounter stale data. Also, this feature relies heavily on correct configuration of the global and local load balancers.
Reason 4: Whole Server Migration: Ensure Clustered Server Failover
In the Cluster environment, how you use singleton service and also ensure the failover is always a dilemma in the J2EE world. Now the dilemma is over.
BEA WebLogic 9 provides a whole server migration feature. It supports automatic and manual migration of a clustered server instance from one machine to another. A managed server that can be migrated is referred to as a migratable server. This feature is designed for environments with requirements for high availability. Singleton services can be hosted on one server and they can be migrated in the presence of failure. Migratable servers provide for both automatic and manual migration at the server level, rather than at the service level. The server migration capability is useful for:
- Ensuring uninterrupted availability of singleton services that must run on only a single server instance at any given time, such as JMS and the JTA transaction recovery system, when the hosting server instance fails. A managed server configured for automatic migration will be automatically migrated to another machine in the even of failure (Figure 8).
- Easing the process of relocating a managed server, and all of the services it hosts, as part of a planned system administration process. An administrator can initiate the migration of a managed server from the Administration Console or command line.
- The server migration process relocates a managed server in its entirety, including IP addresses and hosted applications, to a predefined set of available host machines.
Reason 3: WebLogic Scripting Tool (WLST): Good News for Admin Guys!
WebLogic 9 features an impressive command-line administration tool that is standards based (Jython) and offers powerful capabilities, such as:
- Navigation and editing of the domain configuration, including user-created and non-WebLogic Server MBeans
- Obtaining run-time information about the domain
- Performing various administrative tasks such as deploying applications, starting/stopping servers via the Node Manager, etc
Reason 2: Work Manager and Thread Self-Tuning: Where Is the Execute Queue Concept?
All of the senior J2EE developers have done performance tuning to some extent. In previous versions of WebLogic Server, processing was performed in multiple execute queues. Different classes of work were executed in different queues, based on priority and ordering requirements, and to avoid deadlocks. Users have to control thread usage by altering the number of threads in the execute queues. Now the execute queue concept has been replaced by Work Manger. WebLogic 9.0 implements the Work Manager 1.1 Specification. There is a single thread pool in which all types of work are executed. WebLogic Server prioritizes work based on rules you define and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool, which will provide greater throughput and increased response time. The Work Manager API enables an application to break a single request task into multiple work items, and assign those work items to execute concurrently using multiple Work Managers configured in WebLogic Server. Applications can configure scheduling guidelines (for example, module A should get 70% of CPU time, module B can be "shutdown" if the thread stacks) that WebLogic Server will use in conjunction with data collected on actual run-time performance to schedule CPU resources for the application. Applications no longer have to configure individual thread pools for specific components; instead, they can rely on WebLogic Server to monitor, tune, and allocate these resources.
Among the key self-tuning features in WebLogic Server are:
- Workload management - Administrators can define scheduling policies and constraints at the domain level, application level, and module level.
- Automatic thread count tuning - A thread pool can maximize throughput by automatically changing its size, based on throughput history and queue size
- Thread scheduling functionality - WebLogic Server 9.0 implements the common work manager API, exposing thread scheduling functionality to developers. Applications can also use the Work Manager API to execute work asynchronously and receive notifications on the execution status.
Type 1: Graceful degradation - overload protection
- Work rejection based on low-memory and queue-capacity thresholds (Table 1)
- Critical systems maintained at the expense of noncritical
- Deny rather than degrade when overloaded
- Option to shutdown/suspend server on critical failures such as deadlocks, OOME
- Well-defined exit codes for scripting
- Ability to specify stuck thread actions
Of course performance is the always the number one driver to the purchasing decision, migration, and upgrade.
SPECjAppServer2004 is the standard benchmark for evaluating the J2EE application server. BEA WebLogic 9.0 achieves the best SpecjAppServer2004 performance results in the J2EE world. The result of 3,328.80 JOPS, which is reported by Sun instead of BEA, holds new highest record. For the latest SPECjAppServer2004 results, visit the SPEC results page: www.spec.org/jAppServer2004/results/res2005q4/ jAppServer2004-20051122-00024.html. You can clearly tell who the top market player is. So what about WebLogic 8.1 - is WebLogic 9.0 faster than WebLogic 8.1 and earlier releases?
BEA creates the Server Performance Index (SPI) to compare the relative WLS from release to release. Similar to the "Dow Jones," the SPI of WLS performance is calculated by looking at a basket of representative performance benchmarks composed of micro and application benchmarks, and then calculating the geometric mean of these benchmarks relative to a baseline. The internal data shows that WLS 9.0 is 17 percent faster than WLS 8.1 SP4 by this measure. Also by leveraging the new WebLogic 9 capability to support new hardware, O/S, and database system, it is possible to gain much higher performance. While the effort for boosting a higher performance is never ending, obviously WebLogic 9 will give you a solid gain at the current stage.
Conclusion
With so many new features in WebLogic 9.0, the reasons to migrate to this new WebLogic Server are so overwhelming, what are you waiting for? Let's do it. Besides, you can always get BEA's professional services and technical support when you need it, so there is no more excuse not to, right?
Resources
- SPEC and SPECjAppServer are trademarks of the Standard Performance Evaluation Corp. For the latest SPECjAppServer2004 results, visit
- Side-by-side deployment: http://e-docs.bea.com/wls/docs90/deployment_api/deploy.html
- Diagnostic framework: http://e-docs.bea.com/wls/docs90/ConsoleHelp/ taskhelp/diagnostics/CreateDiagnosticModules.html
- Administrator Console: http://e-docs.bea.com/wls/docs90/ConsoleHelp/core/index.html
- Server clustering: http://e-docs.bea.com/wls/docs90/cluster/Introduction.html
- Server migration: http://e-docs.bea.com/wls/docs90/cluster/failover.html#server_migration
- JMS: http://e-docs.bea.com/wls/docs90/messaging.html
- WLST reference for WebLogic 9.0: http://e-docs.bea.com/wls/docs90/config_scripting/reference.html
- Java Standard support by WebLogic 9: