Updating an Oracle CEP Multi-Server Domain Using Oracle CEP Native Clustering

7-10 Oracle Complex Event Processing Administrators Guide identity1identity enabledcoherenceenabled securityencryptsecurity cluster ... config The config.xml file is located in the DOMAIN_DIRservernameconfig directory of each server, where DOMAIN_DIR refers to the domain directory and servername refers to the name of your server, such as d:\oracle_cep_ home\user_projects\domains\mydomain\myserver1\config. You must specify one of the following values for the security child element: ■ none—Default value. Specifies that no security is configured for the multi-server domain. ■ encrypt—Specifies that multi-server messages should be encrypted. Observe the correct order of child elements in the cluster element. See Section 5.5, Order of cluster Element Child Elements . 3. Edit the DOMAIN_DIRservernameconfigsecurity-config.xml file of each server in the multi-server domain by adding the encryption-service child element of the config root element, as Example 7–7 shows. Example 7–7 The security-config.xml File encryption-service Element config encryption-service signature-enabledtruesignature-enabled encryption-service css-realm ... config 4. Ensure that the DOMAIN_DIRservername.msainternal.dat file for each server in the multi-server domain is exactly the same by copying the file from one server to the other servers. This file is automatically created by the Configuration Wizard when you first created the server; Oracle CEP uses this file for encrypting messages. For example, assume all the servers in your domain are located in the d:\oracle_cep\user_projects\domains\mydomain directory, and that the domain has three servers: server1, server2, and server3. To ensure they all have the same .msainternal.dat file, copy the one from server1 to the other servers: prompt cd d:\oracle_cep\user_projects\domains\mydomain\server1 prompt cp .msainternal.dat ..\server2 prompt cp .msainternal.dat ..\server3 5. Start one of the servers in your domain. See Section 7.5, Starting and Stopping an Oracle CEP Server in a Multi-Server Domain . Because of the encryption-service element that you added to the security-config.xml file in step 3, Oracle CEP automatically creates the .msasig.dat file in the main server directory. Oracle CEP uses this file for digitally signing messages. Administrating Multi-Server Domains With Oracle CEP Native Clustering 7-11 6. Stop the server you just started. See Section 7.5, Starting and Stopping an Oracle CEP Server in a Multi-Server Domain . 7. Copy the .msasig.dat file you created in step 5 to the other servers. For example: prompt cd d:\oracle_cep\user_projects\domains\mydomain\server1 prompt cp .msasig.dat ..\server2 prompt cp .msasig.dat ..\server3 8. If you plan to use Oracle CEP Visualizer with the servers in this domain, see Section 10.5.3, How to Configure SSL in a Multi-Server Domain for Oracle CEP Visualizer . 9. Start all servers in your multi-server domain. See Section 7.5, Starting and Stopping an Oracle CEP Server in a Multi-Server Domain .

7.4 Using the Multi-Server Domain APIs to Manage Group Membership Changes

In an active-active system, applications are deployed homogeneously across several servers and are actively executing. There are cases, however, when these homogeneously-deployed applications need to elect a primary one as the coordinator or leader. In this case, events that result from the coordinator application are kept and passed on to the next component in the EPN; the results of secondary servers are dropped. However, if the coordinator fails, then one of the secondary servers must be elected as the new coordinator. To enable this in an application, the adapter or event bean, generally in the role of an event sink, must implement the com.bea.wlevs.ede.api.cluster.GroupMembershipListener interface which allows the event sinks to listen for multi-server domain group membership changes. At runtime, Oracle CEP automatically invokes the onMembershipChange callback method whenever membership changes occur. The signature of the callback method is as follows: onMembershipChangeServer localIdentity, Configuration groupConfiguration; In the implementation of the onMembershipChange callback method, the event sink uses the Server object localIdentity to verify if it is the leader. This can be done be comparing localIdentity with the result of Configuration.getCoordinator run on the second parameter, groupConfiguration. This parameter also allows a server to know what the current members of the group are by executing Configuration.getMembers. In order to only keep events if it is a coordinator, the event sink must get a new Server identity every time membership in the group changes. Group membership changes occur if, for example, another server within the group fails and is no longer the coordinator. A similar interface com.bea.wlevs.ede.api.cluster.DomainMembershipListener exists for listening to membership changes to the domain as a whole, rather than just changes to the group.