|Oracle® Fusion Middleware Administrator's Guide for Oracle Event Processing
11g Release 1 (184.108.40.206)
Part Number E14300-09
|PDF · Mobi · ePub|
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:
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:
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.
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
Using Oracle Coherence, you can take advantage of Oracle Event Processing high availability quality of service options.
For more information, see:
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.
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").
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.
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.
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
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
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.
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:
"Understanding High Availability" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
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
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
/user_projects/domains directory, which is the default location for Oracle Event Processing domains.
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-host-name: Specifies the host address/IP used for point-to-point HTTP multi-server communication. Default value is
This element is mandatory if one or more Oracle Event Processing servers in your multi-server domain are on different hosts and you plan to manage the multi-server domain using the Oracle Event Processing 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
identity: Mandatory only for Oracle Event Processing native clustering; not used for Oracle Coherence.
operation-timeout: Optional. Specifies, in milliseconds, the timeout for point-to-point HTTP multi-server requests. Default value is
For a complete description of the Oracle Event Processing server
cluster element, see "cluster" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.
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.
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.
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:
Optionally configure the server.
Create an Oracle Event Processing application.
See Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse for a description of the programming model, details about the various components that make up an application, how they all fit together, and typical steps to create a new application.
Deploy your new, or existing, Oracle Event Processing application to the domain.
For more information, see:
"Assembling and Deploying Oracle Event Processing Applications" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
Manage your applications, servers, and domains:
Using the Oracle Event Processing Visualizer.
wlevs.Admin command line tool.
Using JMX and MBeans.