5 Introduction to Multi-Server Domains

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

5.1 Overview of Oracle CEP Multi-Server Domain Administration

An Oracle CEP 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 CEP 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 CEP supports the following clustering systems:

The rest of this chapter describes:

For more information, see:

5.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 CEP 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 CEP high availability quality of service options.

For more information, see:

5.1.2 Oracle CEP Native Clustering

Oracle CEP native clustering: provides a native clustering implementation based on TOTEM.

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

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

5.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 CEP 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 CEP 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 5.2.3, "Custom Deployment Groups").

Note:

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

5.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 6.1.1, "How to Create an Oracle CEP Multi-Server Domain With Default Groups Using Oracle Coherence".

5.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 CEP 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 6.1.1, "How to Create an Oracle CEP Multi-Server Domain With Default Groups Using Oracle Coherence".

5.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 6.1.2, "How to Create an Oracle CEP Multi-Server Domain With Custom Groups Using Oracle Coherence".

5.3 Multi-Server Notifications and Messaging

In order to provide high availability (HA)-like capabilities to adapter and event bean implementations, Oracle CEP 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 CEP high availability options, the primary Oracle CEP 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 CEP servers in a multi-server domain to communicate securely.

For more information, see:

5.4 Multi-Server Domain Directory Structure

Servers in an Oracle CEP 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 5-1 shows a multi-server domain directory with three servers.

Figure 5-1 Multi-Server Domain Directory Structure

Description of Figure 5-1 follows
Description of "Figure 5-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 CEP domains.

5.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:

  • server-name

  • server-host-name: Specifies the host address/IP used for point-to-point HTTP multi-server communication. Default value is localhost.

    This element is mandatory if one or more Oracle CEP servers in your multi-server domain are on different hosts and you plan to manage the multi-server domain using the Oracle CEP Visualizer. It is also mandatory if a server is deployed on a host machine that has multiple IP addresses configured (whether in a multi-server or standalone-server environment).

  • multicast-address: The multicast communication address. For Coherence well-known addressing (WKA) a unicast address can be used.

  • multicast-port: Optional. Specifies the port used for multicast traffic. Default value is 9001.

  • identity: Mandatory only for Oracle CEP native clustering; not used for Oracle Coherence.

  • enabled

  • security

  • groups

  • operation-timeout: Optional. Specifies, in milliseconds, the timeout for point-to-point HTTP multi-server requests. Default value is 30000.

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

5.6 High Availability and Multi-Server Domains

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

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

5.7 Scalability and Multi-Server Domains

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

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

5.8 Next Steps

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

For example, you can: