Oracle BPEL system is not a single server but instead an ecosystem of various servers. The BPEL ecosystem is considered to be down if any of its constituent elements are down. Hence monitoring the Oracle BPEL environment means monitoring each of the below entities:

BPEL Processes and Partner Links

Monitoring the health of BPEL processes is critical to meeting service-level agreements for your processes. You can probably ensure availability and meet service-level requirements by ensuring performance and functioning of the partner links your BPEL processes depend on and identifying problems in a proactive manner. The best approach is to automate tests to be performed at regular intervals and warn the admins when a particular partner link has an unscheduled service shutdown or a longer-than-expected response time.

BPEL Engine

The health of the BPEL engine is critical for your applications. Besides the status of the BPEL engine, you should also focus on statistics such as memory; CPU consumed; and business metrics such as open and closed instances, synchronous and asynchronous process latency, and load factors.

Dehydration Store

The BPEL engine stores process data in the dehydration store (typically a relational database). If you want high availability for your dehydration store, you will probably use a clustered database. Your database administrators should make sure that the database is available and performing properly.

Authentication Server

This is the server against which all your service access is authenticated. If the authentication server is down, none of your services will be usable. Hence, it is important that the authentication server is setup in a high-availability mode as well.

The Application Server on which the BPEL server is running

A typical BPEL engine runs in an application server environment. For example, Oracle BPEL Process Manager can be deployed on a J2EE-compliant application server such as Oracle Application Server, Oracle WebLogic, IBM WebSphere, or JBoss Application Server. The BPEL engine may depend on several resources and services provided by the application server, such as JDBC DataSource, JMS providers, JCA connectors, and shared libraries. The health of the application server, along with the performance of these resources, may directly influence the performance of your BPEL engine. Each application server provides several health indicator metrics. You should automate a mechanism that would proactively issue an alert before anything goes wrong with your application server.

All the activities described above can be summarized as a set of best practices followed to ensure the availability of your BPEL infrastructure:

• Establish service-level objectives for your BPEL processes and partner links.
• Keep a library of BPEL suitcases in your software library. It will help in rebuilding a system in case of server failure.
• Automate routine operations such as purging old process instances.
• Monitor the performance of partner links.
• Monitor the whole BPEL ecosystem, not just the BPEL engine.
• Keep track of BPEL ecosystem membership/topology changes.
• Keep a gold image of your configuration when everything is stable and keep updating it after every configuration change. This will help you find the cause of any possible problem due to configuration changes.
• Monitor BPEL server-specific J2EE artifacts such as the JMS queues and data sources used by the BPEL server in addition to J2EE constructs used by BPEL processes.
• Make sure that you select a management solution that can maximize your productivity and help you deliver maximum service through automation.

The Oracle Application Development Framework (ADF) combines the rich features of Oracle Forms such as sophisticated graphical components with easy database binding, drag and drop, WYSIWYG editing, transaction control, record locking, validation, query by example, and master-detail coordination along with the benefits of an online Java EE application such as distributed, platform-independent, Web-based, and with MVC support. It simplifies Java EE development by minimizing the need to write code that implements the application’s infrastructure allowing the users to focus on the features of the actual application and business logic. Oracle ADF provides these infrastructure implementations as part of the underlying framework.

Oracle ADF is based on the Model-View-Controller (MVC) design pattern. It further separates the model layer from the business services to enable service-oriented development of applications. The Oracle ADF architecture is based on four layers:

• The Business Services layer – provides access to data from various sources and handles business logic.

• The Model layer – provides an abstraction layer on top of the Business Services layer, enabling the View and Controller layers to work with different implementations of Business Services in a consistent way.

• The Controller layer – provides a mechanism to control the flow of the Web application.

• The View layer – provides the user interface of the application.

The key layer in the ADF architecture is the Business Services layer where all the business logic is embedded .This layer can be implemented in a wide variety of technologies including EJB, Web Services, POJO, Toplink, or ADF Business Components. The view layer provides a large range of AJAX based rich UI components that enhance the user experience of ADF applications. The model layer provides bulk of the automated code that ADF builds on. It facilitates the auto-binding between the rich UI components of the view layer and business logic components of the business services layer. Additional detail on Oracle ADF is available on their website.

The Java Management Extension (JMX) technology has been in existence since a long time (since J2SE version 5.0), however only recently did I get my hands dirty with it. It is certainly one of the most intriguing yet little discussed technology that the Java community has produced (JSR 160). This article is a brief abstract of the one available at the Sun Website

Java Management Extensions (JMX) technology offers programmers the ability to add monitoring and management to their Java applications. In effect, these APIs allow you to locally or remotely manage anything Java-enabled, from web servers to network devices to web phones.

With JMX technology, an application, device, or service on one machine (called a resource), can be controlled remotely through the use of one or more custom JavaBean objects known as Managed Beans (MBeans). These MBeans are then registered in a core-managed object server (an MBean server). The MBean server acts as a management agent to any remote managers that want to access the resource.

The JMX Environment

The JMX specification defines architecture in three distinct tiers

Instrumentation Tier. Resources, such as applications, devices, or services, are instrumented using Java objects called Managed Beans (MBeans). MBeans expose their management interfaces, composed of attributes and operations, through a JMX agent for remote management and monitoring.

Agent Tier. The main component of a JMX agent is the MBean server. This is a core managed object server in which MBeans are registered. A JMX agent also includes a set of services for handling MBeans. JMX agents directly control resources and make them available for management.

Remote Management Tier. This tier defines protocol adaptors and connectors that make a JMX agent accessible from remote management applications outside the agent’s Java Virtual Machine (JVM)*. (Note that JSR 160 defines connectors only.) Connectors are used when the remote client is JMX-aware, and sees the same JMX API as a local client would. Adaptors are used when the remote client is using a generic management protocol such as Simple Network Management Protocol (SNMP) or Common Information Model and Web Based Enterprise Management (CIM/WBEM).

There are generally three types of developers who use JMX, although one person might exercise all three roles:

• A developer that writes MBeans to manage resources. Here, JMX technology defines the interfaces exposed for management. The developer is responsible for the “glue” between the MBean and the resource itself.

• A developer that creates and deploys the agent. This person typically performs a number of tasks, including:
  • Creating an MBean server, or using the one supplied by the platform.
  • Registering the MBeans that represent the resources using MBean naming conventions.
  • Configuring the connectors and protocol adaptors supplied by the platform (RMI and SNMP), or adding custom connectors or adaptors if the resources are to be accessed remotely.

• A developer that writes the remote manager. This person chooses the connector or protocol adaptors to interact with the JMX agent, and builds views of the resources managed remotely through the exposed MBeans.

There are four types of MBeans, as defined by the JMX specification:

·         Standard MBeans

·         Dynamic MBeans

·         Model MBeans

·         Open MBeans

The typical process used in creating a JMX-compliant management interface involves at least two steps. The first step is to create an MBean interface, as well as an agent to register that MBean with the MBean server. The next step is to manage the MBean using a remote management application. The JMX specification defines a standard set of connectors that allow you to access JMX agents from remote management applications. This is useful because JMX connectors using different protocols provide the same management interface. This enables a management application to manage resources transparently, regardless of the communication protocol used. JMX agents can also be used by systems or applications that are not compliant with the JMX specification, but which support JMX agents.

For more details refer to the JMX Website

The JavaFX 1.0 platform release includes the following components:

• JavaFX 1.0 SDK which includes the JavaFX compiler and runtime tools, graphics, media, web services, and rich text libraries to create RIAs for the desktop, browser and mobile platforms
• NetBeans IDE 6.5 for JavaFX 1.0 which provides a sophisticated integrated development environment for building, previewing, and debugging JavaFX applications. The editor features a drag-and-drop palette to quickly add JavaFX objects with transformations, effects and animation. This IDE also comes with its own set of Building Blocks samples and the Beta version of the JavaFX Mobile Emulator, a mobile phone simulator.
• JavaFX 1.0 Production Suite is a suite of tools and plugins for creative tools that enable designers to export graphical assets to JavaFX applications.