Database Reference
In-Depth Information
highly available at the same time; establishing the clustered servers in the domain is only
the beginning:
1. Now we have parallel subscribers (or actual processors), and we have to propag-
ate a notification to them simultaneously from our adapter, depending on the pro-
cessing conditions. To do so, we have to change the JMS type from distrib-
utedQueue to distributedTopic (that is, we will replace the JMS queue
with Topics) on both sides, including the one at the provider end. This change
will ensure that all consumers will be notified about all the events. We will also
need to define an event's partition criteria at our JMS adapter configuration file.
In fact, it is a form of scalability dispatcher-broadcaster, also providing HA and
it's implemented by
com.oracle.cep.cluster.hagroups.ActiveActiveGroupBean
for each BroadcastGroup member. Thus, the jms-adapter section of our CEP
application config file must be extended right after the destination-jndi-
name tag. Also, remember that you do not have to be exceedingly elaborate in
defining the dispatching conditions. Our processor will handle the main tasks
about filtering, matching, and aggregation; here, we need to just define something
suitable to split the group workload, similar to Content-Based Routing (SOA
and EAI patterns). In our cargo-handling example, area_code of the Booking
Office would suffice:
<destination-jndi-name>distributedTopic</destination-jndi-name>
<message-selector>${CONDITION}</message-selector>
<bindings>
<group-binding
group-id="ActiveActiveGroupBean_group1">
<param
id="CONDITION"><your_condition_1></param>
</group-binding>
<group-binding
group-id="ActiveActiveGroupBean_group2">
<param
id="CONDITION"><your_condition_2></param>
</group-binding>
</bindings>
Consequently, the server's config.xml file must be updated accordingly with
ActiveActiveGroupBean identifications in the <group> element:
Search WWH ::




Custom Search