WS-Notification Clustered example
This example demoonstrates the use of WS-Notification configured statically, whereas WS-Notification can also be used in a more dynamic way by sending requests the the WS-Notification Broker to create publishers and subscribers.
This example uses 3 clustered ServiceMix containers:
- instance1 is part of the cluster but does not have any WS-N subscribers or publishers
- instance2 hosts a WS-Notification component and a subscriber
- instance3 hosts another WS-Notification component and a publisher triggered by a Quartz component
This examples relies on the WS-Notification component.
Launching the example
To run this example, open three terminals - one for each instance directory. In each terminal, start ServiceMix and feed the configuration like so:
In terminal one:
In terminal two:
In terminal three:
ServiceMix instance3 will publish messages to the topic named MyTopic and ServiceMix instance2 will receive these messages because it is subscribed to the topic named MyTopic.
The output of instance2 will look like:
Publisher side
Quartz component
Refer to Quartz for more informations.
<sm:activationSpec destinationService="test:publisher" destinationEndpoint="endpoint">
<sm:component>
<bean class="org.apache.servicemix.components.quartz.QuartzComponent">
<property name="triggers">
<map>
<entry>
<key>
<bean class="org.quartz.SimpleTrigger">
<property name="repeatInterval" value="2000"/>
<property name="repeatCount" value="20"/>
</bean>
</key>
<bean class="org.quartz.JobDetail">
<property name="name" value="My Example Job"/>
<property name="group" value="ServiceMix"/>
</bean>
</entry>
</map>
</property>
</bean>
</sm:component>
</sm:activationSpec>
WS-Notification publisher
The PublisherComponent is just a proxy to the WS-Notification component. It receives InOnly JBI exchanges from the components (in this case, the Quartz component) and send them as publish request to the WS-Notification broker. Hence, you need to specific the WS-Notification topic which will be used to publish the messages in the WS-Notification world.
<sm:activationSpec service="test:publisher" endpoint="endpoint">
<sm:component>
<bean class="org.apache.servicemix.wsn.spring.PublisherComponent">
<property name="topic" value="myTopic" />
</bean>
</sm:component>
</sm:activationSpec>
WS-Notification component
The WS-Notication broker is created by the snippet below:
<sm:activationSpec>
<sm:component>
<bean class="org.apache.servicemix.wsn.spring.WSNSpringComponent">
<property name="connectionFactory" ref="connectionFactory" />
</bean>
</sm:component>
</sm:activationSpec>
Note that the WS-Notification broker does not mandate that publishers are registered on a given topic, so in this example, the PublisherComponent just sends a publish request to the broker which will forward it to all subscribers.
Subscriber side
The WS-Notication subscription
The subscriber is registered statically on the WS-Notification broker using the following snippet:
<sm:activationSpec>
<sm:component>
<bean class="org.apache.servicemix.wsn.spring.WSNSpringComponent">
<property name="requests">
<list>
<bean class="org.apache.servicemix.wsn.spring.SubscribeFactoryBean">
<property name="consumer" value="http://servicemix.apache.org/demo/trace/endpoint" />
<property name="topic" value="myTopic" />
</bean>
</list>
</property>
<property name="connectionFactory" ref="connectionFactory" />
</bean>
</sm:component>
</sm:activationSpec>
The topic property is the name of the topic from which the subscriber receive messages. It has to be the same than the topic where messages are published.
The consumer property indicates the JBI endpoint where exchanges must be sent to. The syntax used is:
where sep is the separator used in the namespace uri: / or :.
In our case, the value
tells the WS-Notification broker to send messages to the my:trace service (endpoint endpoint), which is a simple TraceComponent that print messages on the console.
top