The servicemix-wsn2005 JBI Component
servicemix-wsn2005 is a standard JBI Service Engine which implements the WS-Notification specification from Oasis.
While this article does not intend to be a review of the WS-Notification specification, here is a few terms you need to fully understand:
- Publishing request
The current implementation has several limitations:
- subscriptions are not persistent: message will be lost if the subscriber can not be reached
- subscriptions can not be clustered: if you register the same subscriber in a cluster, each node will receive all notifications
- publishing can not be restricted to registered publishers: everyone can publish through an anonymous publisher
The WS-Notification SE can be used to provide publish/subscribe routing in the JBI bus. There are several usage:
- configuration using JBI packaging
- dynamic configuration inside the JBI bus
- outside the JBI bus
- embedding WS-Notification SE
Configuration using JBI packaging
servicemix-wsn2005 accepts deployment of Service Units.
The SU must contain one or more files with an xml extension, each one containing a single WS-Notification request. The currently supported set of requests include:
The requests will be started in this very order, so that you can create a PullPoint and create a Subscription for it inside the same service unit.
Dynamic configuration inside the JBI bus
In addition to the deployment of service units, you can also create pull points or subscriptions dynamically from inside the JBI bus by using a simple API.
To create a subscription for a given JBI endpoint, you can use the following code:
To publish a message on a given topic:
message is a DOM element.
You can also create pull points and subscriptions for them:
Later, you can pull notifications from this pull point:
Outside the JBI bus
If you want to use WS-Notification ouside the JBI world, you will need to be able to receive incoming requests or send notifications to the external services. This must be done through by using Binding Components, either using HTTP or JMS.
To expose the NotificationBroker and CreatePullPoint services using HTTP/SOAP, you can deploy the following configuration file to
If you use a single static configuration file for ServiceMix, you can easily leverage this component to create subscription, pull-points and publish messages.
The above code snippet creates a publisher proxy, a subscription and a subscriber.
The publisher proxy is a simple component that wraps incoming JBI exchanges into WS-Notification
notify requests and send them to a notification broker on the given topic. This could also be written in plain spring style:
When the component is started, it registers itself as a publisher to the WS-Notification broker. To do so, it activates a JBI endpoint named
subscription so it can handle demand based publishing. When this component receives an InOnly exchange, let's say
<hello>world</hello>, it will wrap it in a request as shown here and send the request as an InOnly exchange to the NotifiationBroker. Note that, as this component activates two JBI endpoints, you need to explicitely target the endpoint specified in the activationSpec when sending a message.
The subscription is created inside a
servicemix-wsn2005 component. You must fill the
topic properties, where the
consumer is the URI-encoded target JBI endpoint, which will be resolved to the first component activated. You could also use the plain spring syntax:
The following xml snippets are just examples of WS-Notification requests. You should refer to the specification for more informations.
This request will create a subscription on the myTopic topic and will send messages to the JBI endpoint identified by its URI. In this case, the endpoint: protocol is used to identify an endpoint on the JBI bus.
Note that the
<sm:address/> element is a ServiceMix extension that creates a PullPoint on a specific JBI endpoint ([namespace][sep][service][sep][endpoint], see URIs). This is very useful when you want to create a subscription for this endpoint at deployment time (see the previous paragraph).
<sm:name/> element is a second ServiceMix extension that can be used to specify the name of the PullPoint. Such a name is used as JMS queue name, so it may be useful to specify it if you want to address a specific queue. If none is set, a queue name will be automatically generated (note that some JMS providers may require some administration tasks to be performed to create a JMS destination).
The Notify request is sent by a publisher to the NotificationBroker. This request contains a list of NotificationMessage, each one containing:
- a subscription reference (not used)
- a topic (mandatory)
- a producer reference (which may contain the address of the producer that created the message)
- the message
Below is an example of a such a request.