Platform

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

Reason 6: Portal-Based Extensible Administration Console: Extensible Console!
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).

Through the Administration Console, you are able to perform the following functions:

• 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

Reason 5: New Zero Downtime Architecture: How about MAN/WAN Clustering?
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.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...