Top 10 reasons for upgrading to WebLogic 9

Document directory

• Conclusion

Since WebLogic 9.0 was released, many people have said this: "Give me three reasons to upgrade to WebLogic 9.0 first ." WebLogic 9.0 has rich features and is performance-driven, so we can easily give 10 main reasons.

Reason 10: enhanced web services and a golden-age SOA Architecture

WebLogic 9.0 delivers a complete and fully integrated Web Service Stack. Bea takes a leading position in some important technical aspects of the web service field, such as annotation-based Web Service programming and session Web Services. Web services comply with all basic J2EE specifications and most important WS-* specifications. Enhanced support for asynchronous, conversational, reliable, and secure Web Services.

In short, in terms of new Web Services, users can obtain:

• Next-generation Web Service Programming Model
• Performance Improvement of conversational Web Services
• More flexible, secure, and reliable asynchronous Web Services
• Support for long-term asynchronous and reliable message exchange
• Reduced Complexity
• The latest standard-based programming model based on JSR-181 Based on JWS Web Service
• Simplified Web Service writing

Reason 9: The proud enhancement in JMS-WebLogic 9

WebLogic Server 9.0 introduces important improvements in the configuration, deployment, and dynamic management of Weblogic JMS. It provides official support for the JMS 1.1 specification. In addition, we have added the long-awaited Advanced Message sorting feature to the system. The XML message processing function of the xml api is enhanced. Using JMS on the Weblogic 9.0 platform is very easy, interesting, reliable, and fast. The following are some highlights of the new features.

Automated JMS fault recovery

Automatic JMS fault recovery is a long-awaited feature in the industry. JMS uses the "Automatic WebLogic Server migration" feature to provide automated JMS fault recovery. When the entire Weblogic server instance is restored, JMS will be automatically restored from the fault. While some other JMS server providers have used some complex devices to provide such functionality, the implementation of Weblogic 9.0 is the most intuitive and clear.

Sorting Unit

Message sorting is a basic requirement of most message processing applications. WebLogic Server JMS ensures the ordered processing of messages even in the cluster environment. It can even define multiple groups to group messages, so that each group has its own processing order (1 ).

Storage Forwarding (SAF)

The WebLogic storage Forwarding (store and forward, SAF) service enables WebLogic Server to reliably deliver information between applications deployed through the Weblogic server instance. The powerful features of SAF allow us to easily link Multiple message services together (2 ).

Reason 8: parallel deployment-dream come true

Every J2EE developer has experienced the pain of releasing a new product version. After countless development and QA cycles, we finally found that the new version has been deployed on the application server. We plan to shut down the server one weekend, change to a new version of the product, and pray that there will be no problem on Monday. If you are lucky enough, there will be only some minor problems. However, if you are not lucky enough, you have to re-use the previous application, which is even more painful than deploying the new version, because sometimes you cannot recover all the changes (as shown in 3 ).

We hope that we can use multiple versions on the application server and switch between versions without interrupting the system.

Now our dream has come true. Concurrent application deployment can control the deployment process of new Web-based applications without interrupting services. The new version of the application is deployed with the existing version. WebLogic will gradually port the interaction. The old version is deploy after all clients have completed their work. The administrator can explicitly deploy the old version, or the configured timeout may be reached.

Rolling back a new version is easy: if a problem is detected in the new application version, you only need to stop the redeployment process.

For new applications, administrators can deploy applications in "management mode". This mode is not accessible to non-management clients, and its purpose is to perform health checks, to ensure that the application runs properly as expected before opening it to the client.

The following is a list of features of Weblogic 9 parallel deployment:

• Multiple application versions can coexist.
• A pre-release version is available to users.
• Roll back previous versions
• Automatic withdrawal: Smooth, time-out, and instant
• Create recognizable application artifacts/Resources
• Reduces hardware, software, maintenance, and support costs

JSR-88 is part of the J2EE 1.4 specification and the JSR-88 specifies a standard API for the configuration and deployment of J2EE applications. WebLogic 9 not only implements JSR-88, but also provides a lot of additional value in addition to J2EE regulations.

Reason 7: Weblogic diagnostic framework: reducing total cost of ownership

WebLogic diagnostics framework (wldf) is designed to reduce the total cost of ownership (TCO) of customers through significant diagnostic enhancements ). Wldf concatenates all BEA WebLogic Server 9.0 containers to create a unified framework for orderly control of data sets, which is very important for the good operation of enterprise applications. This framework tracks and archives meaningful diagnostic data that can be used to monitor and diagnose problems occurring on running servers. Wldf is a unified framework and public API. Therefore, you can easily embed applications into the framework to use the server's diagnostic functions.

Wldf consists of multiple components that collaborate to collect, archive, and access diagnostic information about their host servers and applications. All framework components run on the server level and only recognize the server scope. All components except manager are included in the server process and participate in the Standard Server lifecycle. All the artifacts of the framework are configured and saved on the basis of each server. Wldf manager provides a configuration and control interface for managing the diagnostic framework. In addition, the wldf Image Capture Utility provides a model for capturing diagnostic snapshots of critical server states. It provides the Least invasive server diagnosis and troubleshooting methods.

The following is a list of wldf features:

• A unified diagnostic framework is introduced, which provides a blueprint for subsequent Bea enhancements.
• Improved overall visualization of WLS and stack products to reduce blind spots in Monitoring and Diagnosis
• Improves the quantity and quality control of diagnostic data (available by diagnostic experts) and provides real-time tonality.
• Added diagnostic tools to help you understand and solve system faults.
• Provides clearer interfaces and tools to help diagnose customer applications.
• Available across WL platforms
• Helps release customer tool patches without relying on Support Teams
• Application and WLS tools
• Monitoring and notification functions, used to trigger alarms
• Request coloring (Cross JVM): The diagnostic context used for event reconstruction and association
• Fine-grained control-increase or decrease the capacity
• Data Visualization with console Extension: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab? Id = s96
• Programmatic access with JMX

Reason 6: Portal-based scalable Management Console: scalable console!

The WebLogic 9.0 console provides a completely redesigned user interface, which is standardized and all its subsystems improve the appearance and navigation experience. It is built on the WebLogic Portal framework. Although the portal slows down the Startup Process of the Management Console, it also makes it more open and easy to expand-applications can embed extensions into the console if needed.

New features include:

• Improved navigation and user interface design.
• The "Modify Center" added to control domain configuration modification ". On the console, the administrator can modify "batch processing" to the WebLogic Server Configuration for predictable and reliable modification. Under the Administrator's command, all configuration modifications in a batch are distributed across domains and applied to all servers. If any server cannot accept these configurations, it will be rolled back throughout the domain! Then they remain suspended and wait for further operations from the Administrator.
• New Application Deployment and configuration tools, including support for application installation, more configuration interfaces, and new deployment and redeployment controls for production applications. The additional console updates enable you to assign values to subordinate plan variables when deploying and exporting applications.
• WebLogic diagnostic service, which has many new features for configuring, collecting, and viewing diagnostic information in the runtime environment. You can access this service on the console. See centralized diagnostic services that contain more visibility and runtime controls (4 ).
• The management console can now be extended in a way similar to a common extended portal application. In addition to adding and replacing content, the console extension can also add nodes to the navigation tree and modify the appearance elements of the console, such as colors or trademark images (5 ).

You can perform the following operations on the console:

• Configure, start, and close WebLogic Server instances
• Configure WebLogic Server Cluster
• Configure WebLogic Server services, such as database connectivity (JDBC) and Message Processing (JMS)
• Configure security parameters, including managing users, groups, and roles
• Configure and deploy applications
• Monitor server and Application Performance
• View server and domain log files
• View application deployment descriptor
• Edit the selected runtime application deployment descriptor Element

Reason 5: New Zero-downtime architecture: Man/WAN cluster?

WebLogic 9.0 introducesMan/WAN)Cluster to further expand the concept of zero downtime. It provides enhanced http session replication, which makes disaster recovery possible in WebLogic Server clusters connected through the WAN or man.

HTTP session replication in man

The application can configure the backup of an HTTP session copy to another Weblogic server cluster. Once the master WebLogic Server Cluster is unavailable, the HTTP client can be transferred to the secondary WebLogic Server Cluster (6 ).

This feature assumes that two WebLogic Server clusters can be connected at high speed and relies heavily on the correct configuration of global and local load balancers.

HTTP session replication in man

This is ideal for disaster recovery centers (Dr sites. The application can configure another backup of an HTTP session copy to another Weblogic server cluster. WebLogic Server asynchronously sends http session data to another backup (which may be stored in the database ). Once the master WebLogic Server Cluster is unavailable, the HTTP client can be transferred to the secondary WebLogic Server Cluster (7 ).

If the replication to another backup is asynchronous, the recovered HTTP client may encounter outdated data. This feature also relies heavily on the correct configuration of global and local load balancers.

Reason 4: Migration of the entire server: Ensure fault recovery of cluster servers

In the cluster environment, how to use a single service and ensure fault recovery is always a challenge in the J2EE field. Now this problem has been solved.

BEA WebLogic 9 provides the ability to migrate the entire server. It supports automatic and manual migration of Cluster Server instances from one machine to another. A hosted server that can be migrated is called a migratable server. This feature is designed for environments requiring high availability. A single service can be installed on one server and may be migrated due to a fault. The migration server provides automatic and manual migration at the server level rather than the service level. The server migration function can be used:

• When the host server instance fails, ensure the continuous availability of a single service. At any given time, a single service must only run on a single server, such as JMS and JTA transaction recovery systems. In the event of a fault, the managed server configured for automatic migration will be automatically migrated to another machine (as shown in Figure 8 ).
• It simplifies the process of relocating managed servers and all services that reside as part of the planned system management process. The administrator can initialize the managed server migration from the management console or command line.
• Server migration will completely relocate hosted servers, including relocating IP addresses and resident applications to a set of pre-defined available hosts.

Reason 3: Weblogic scripting tool (wlst): the gospel of the Administrator!

WebLogic 9 provides an impressive standard-based command line management tool (Jython) and powerful functions, such:

• Navigation and editing of domain configuration (including user-created and non-WebLogic Server mbean)
• Obtain runtime information about the domain
• Execute various management tasks, such as deploying applications and starting/stopping servers through the Node Manager.

Wlst disapproves weblogic. Admin in WebLogic 9, although it fully supports the latter.

Reason 2: Job Manager and thread self-tuning: Where is the execution queue?

All senior J2EE developers have made performance adjustments to some extent. In the previous version of Weblogic server, the processing is executed in multiple execution queues. Different types of jobs are executed in different queues based on their priorities, sorting, and deadlock avoidance requirements. You have to change the number of threads in the execution queue to control the thread usage. The concept of execution queue has been replaced by work manger. WebLogic 9.0 implements the work Manager 1.1 specification and executes all types of work in a thread pool. WebLogic Server assigns priority to work based on user-defined rules and runtime indicators (including the actual time when the request is executed and the rate at which the request enters and leaves the thread pool, this will provide higher throughput and faster response speed. The work manager API allows an application to divide a single request task into multiple work items and assign these work items to be executed simultaneously using multiple work managers configured in the WebLogic Server. The application can configure the scheduling guiding principles (for example, Model A should get 70% of the CPU time. If the thread is congested, Model B can be disabled ), in this way, the WebLogic Server can use these guiding principles and the actual runtime performance data collected to schedule the CPU resources of the application. The application does not need to configure a separate thread pool for the specified component, because WebLogic serve can be used to monitor, adjust, and allocate these resources.

Important self-tuning features in WebLogic Server include:

• Workload management-the administrator can define Scheduling Policies and constrain them at the domain, application, and module levels.
• Automatic Thread Count adjustment-the thread pool can automatically modify its size based on the throughput history and queue size to maximize the throughput.
• Thread Scheduling function-WebLogic Server 9.0 implements a general work manager API to publish the thread scheduling function to developers. Applications can also use the work manager API to asynchronously execute jobs and receive notifications during execution.

Here we need to emphasize a very good feature, that is, overload protection. BEA has been trying to think what customers think. overload protection is an outstanding representative of this kind of effort. WebLogic 9.0 provides two types of protection in this regard.

Type 1: Decent downgrade-overload protection

• Denial of work based on low memory and queue capacity thresholds (as shown in Table 1)
• Critical systems maintained with non-critical overhead
• Refuse in case of overload, not downgrade

Type 2: Proper fault-if everything else fails, shut down the server.

• When a fatal fault (such as a deadlock) occurs, choose to disable or suspend the server, Oome
• Well-defined existing code for script writing
• Ability to block thread actions

Reason 1: Performance

Undoubtedly, performance will always be the first driving force for purchase determination, migration and upgrade.

Specjappserver2004 is the benchmark for evaluating J2EE application servers. BEA WebLogic 9.0 achieved the best performance results of specjappserver2004 In the J2EE field. What about WebLogic 8.1? -- Is WebLogic 9.0 faster than WebLogic 8.1 or earlier?

Bea creates a server performance index (SPI) to compare each WLS version. Similar to the Dow Jones index, the SPI performance of WLS is derived from the computation of a large number of representative performance benchmarks, including microbenchmarks and application baselines, and then the geometric mean of these benchmarks. The internal data after the test shows that WLS 9.0 is 8.1 faster than WLS 17% SP4. Likewise, WebLogic 9 supports new hardware, operating systems, and database systems to achieve higher performance. Obviously, WebLogic 9 will greatly benefit users at this stage, and Bea will never stop its efforts to achieve higher performance.

Conclusion

Since WebLogic 9.0 has many new features, the reason for migrating to this WebLogic Server version is obvious. What are you waiting? Come on! Don't forget, whenever you need it, you will receive professional services and technical support from BEA. What are your reasons for not upgrading?