Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Event Processing
11g Release 1 (11.1.1.7)

Part Number E14300-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Introduction to Multi-Server Domains

This chapter introduces Oracle Event Processing multi-server domains, also known as clusters, based on Oracle Coherence or Oracle Event Processing native technology. It also provides overviews of multi-server messaging, high availability, and scalability.

This chapter includes the following sections:

6.1 Overview of Oracle Event Processing Multi-Server Domain Administration

An Oracle Event Processing multi-server domain (or cluster) is a domain to which you can add one or more servers that become logically connected for the purposes of management, and physically connected using a shared User Datagram Protocol (UDP) multicast address and port. All servers in an Oracle Event Processing multi-server domain are aware of all other servers in the domain and any one server can be used as an access point for making changes to the deployments in the domain.

Management of the multi-server infrastructure is done at the domain level. Thus server failure, start, or restart is detected by every member of the multi-server domain. Each member of the multi-server domain has a consistent, agreed notion of domain membership enforced by the multi-server infrastructure.

To properly configure servers in a multi-server domain, you must configure them with the same multicast address and port and the same domain name. It is an error to configure servers using the same multicast address and port and port but different domain names.

Applications deployed to the default group in a multi-server domain are deployed homogeneously to all servers of that domain, therefore all servers must have the appropriate configuration resources required by the application.

Oracle Event Processing supports the following clustering systems:

The rest of this chapter describes:

For more information, see:

6.1.1 Oracle Coherence Clustering

Oracle Coherence: provides replicated and distributed (partitioned) data management services on top of a reliable, highly scalable peer-to-peer clustering protocol. Oracle Coherence has no single points of failure; it automatically and transparently fails over and redistributes its clustered data management services when a server becomes inoperative or is disconnected from the network. When a new server is added, or when a failed server is restarted, it automatically joins the cluster and Oracle Coherence fails back services to it, transparently redistributing the cluster load.

Note:

Before you can use Oracle Event Processing with Oracle Coherence, you must obtain a valid Oracle Coherence license such as a license for Coherence Enterprise Edition, Coherence Grid Edition, or Oracle WebLogic Application Grid. For more information on Oracle Coherence, see http://www.oracle.com/technology/products/coherence/index.html.

Using Oracle Coherence, you can take advantage of Oracle Event Processing high availability quality of service options.

For more information, see:

6.1.2 Oracle Event Processing Native Clustering

Oracle Event Processing native clustering: provides a native clustering implementation based on TOTEM.

Using Oracle Event Processing native clustering, you cannot take advantage of Oracle Event Processing high availability quality of service options.

For more information, see Section 7.1, "Creating an Oracle Event Processing Multi-Server Domain Using Oracle Event Processing Native Clustering".

6.2 Groups

In order to support the deployment to, and management of, the multi-server domain at a finer grained-level than the domain, Oracle Event Processing introduces the concept of groups. A group is a set of one or more servers with a unique name within the domain. In an Oracle Event Processing domain, an arbitrary number of groups may exist with a configurable group membership. A server may be a member of more than one group, although typically this information is transparent to the user.

When you deploy an application to a multi-server domain, you deploy it to a particular group. Applications deployed to any group must have a unique name across the domain.

Applications deployed to a group in a multi-server domain are deployed homogeneously to all servers of that group, therefore all servers must have the appropriate configuration resources required by the application.

An application that is deployed to a server can be uninstalled from another server under the same domain.

The following pre-defined deployment groups always exist:

Alternatively, you can create a custom deployment group (see Section 6.2.3, "Custom Deployment Groups").

Note:

If you are planning to deploy an Oracle Event Processing high availability application, and you require scalability, you may also need to create an Oracle Event Processing high availability notification group. For more information, see "Deployment Group and Notification Group" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.

6.2.1 Singleton Server Deployment Group

This group consists of only the local server. This means that the membership of this group depends on the server from which it is accessed. This group can be used to pin deployments to a single server.

For more information, see Section 5.1.1, "How to Create an Oracle Event Processing Multi-Server Domain With Default Groups Using Oracle Coherence".

6.2.2 Domain Deployment Group

This group contains all live members of the domain. Its membership is automatically managed and cannot be changed by the user.

The domain name is determined by the Oracle Event Processing server config.xml file domain element. For example, the domain is named mydomain if your config.xml file is like this:

<domain>
    <name>mydomain</name>
</domain>

The default name is WLEventServerDomain.

For more information, see Section 5.1.1, "How to Create an Oracle Event Processing Multi-Server Domain With Default Groups Using Oracle Coherence".

6.2.3 Custom Deployment Groups

There are cases where the application logic cannot simply be replicated across a homogenous set of servers in a multi-server domain. Examples of these types of applications are those that must determine the best price provided by different pricing engines, or applications that send an alert when a position crosses a threshold. In these cases, the application is not idempotent; it must calculate only once or send a single event. In other cases, the application has a singleton nature, such as a monitoring application, the HTTP pub-sub server, and so on.

As a more complex example, consider a domain that has two applications: the strategies application uses several strategies for calculating different prices for some derivative and then feeds its results to a selector application. The selector application then selects the best price amongst the different options provided by the strategies' application results. The strategies application can be replicated to achieve fault-tolerance. However, the selector application must be able to keep state so as to determine the best price; for this reason, the selector application cannot be replicated in a hot/hot fashion.

If a domain must support servers that are not completely homogeneous, you configure this by creating custom groups.

Applications deployed to a custom group in a multi-server domain are deployed homogeneously to all servers of that group, therefore all servers must have the appropriate configuration resources required by the application.

For more information, see Section 5.1.2, "How to Create an Oracle Event Processing Multi-Server Domain With Custom Groups Using Oracle Coherence".

6.3 Multi-Server Notifications and Messaging

In order to provide high availability (HA)-like capabilities to adapter and event bean implementations, Oracle Event Processing provides a number of notification and messaging APIs at both the group- and server-level. Using these APIs, you can configure a server to receive notification when its group or domain membership changes, either because an administrator deliberately changed it or due to a server failure. Similarly you can use these APIs to send messages to both individual groups and to the domain.

When you configure your application to use Oracle Event Processing high availability options, the primary Oracle Event Processing server uses Oracle Coherence to communicate with its secondary servers to keep them up to date with the primary server's event processing progress.

You can configure Oracle Event Processing servers in a multi-server domain to communicate securely.

For more information, see:

6.4 Multi-Server Domain Directory Structure

Servers in an Oracle Event Processing domain store their files in a single directory. By convention, the directories of the servers in a multi-server domain are sub-directories of the domain directory. Additionally, the name of the servers and domain correspond to the name of the server directories and domain directory, respectively. This is by convention only, and not required, although Oracle recommends you set up your domains this way for simplicity and consistency. If the servers of the multi-server domain are located on different computers, you can replicate the directory structure on both computers, also for simplicity and consistency.

Figure 6-1 shows a multi-server domain directory with three servers.

Figure 6-1 Multi-Server Domain Directory Structure

Description of Figure 6-1 follows
Description of "Figure 6-1 Multi-Server Domain Directory Structure"

The myServer1 configuration file snippet shows how the domain directory and domain object are configured with the same name, as well as the server directory and server name. The domain directory is located in the ORACLE_CEP_HOME/user_projects/domains directory, which is the default location for Oracle Event Processing domains.

6.5 Order of cluster Element Child Elements

The order of cluster element child elements in the config.xml file is important; if you include elements in the incorrect order you may encounter an error. The following list describes the order in which you should list the child elements:

For a complete description of the Oracle Event Processing server config.xml file cluster element, see "cluster" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.

6.6 High Availability and Multi-Server Domains

If you use Oracle Coherence clustering for your multi-server domain, you can take advantage of Oracle Event Processing high availability quality of service options. These options are not supported using Oracle Event Processing native clustering.

For more information, see "Understanding High Availability" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.

6.7 Scalability and Multi-Server Domains

Using either Oracle Coherence or Oracle Event Processing native clustering, you can take advantage of Oracle Event Processing scalability quality of service options.

For more information, see "Developing Scalable Applications" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.

6.8 Next Steps

After creating your own Oracle Event Processing multi-server domain, consider the administration tasks that Section 1.5, "Understanding Oracle Event Processing Server Administration Tasks" describes.

For example, you can: