WS-Notification implementation

Since the early days, Apache ServiceMix has had an implementation of the Oasis WS-Notification specifications. This implementation was built on top of Apache ActiveMQ and available inside the JBI bus as a service. Now that JBI is being put aside in ServiceMix, some questions arose about the future of this component.

So last week, I took a stab at rewriting the component using pure JAX-WS services. For those that are not familiar with WS-Notification, this specification, unlike most other WS-* specifications defines a service described by a WSDL, so there's no low level protocol implementation to write. I took most of the code from ServiceMix implementation and just rewrote the JBI specific bits to leverage JAX-WS instead.

The results have been committed into Apache CXF and should be part of the upcoming 2.5 release. Note that the implementation itself does not require CXF, though it can very well use it as the JAXWS provider.

If you want to give it a try, you need to build CXF trunk locally and then run the following commands in Karaf:
karaf> features:addurl mvn:org.apache.cxf.karaf/apache-cxf/2.5.0-SNAPSHOT/xml/features
karaf> features:install wsn


To check that the WS-Notification broker is correctly started, you can try the following command:
karaf> cat http://0.0.0.0:8182/wsn/NotificationBroker?wsdl
...


The services are also exposed as OSGi services, so that they can be directly accessed if needed. If you use the awesome Fabric DOSGi implementation, it can be very interesting.

Some areas could still be enhanced, as the codebase is mostly the same as the old ServiceMix component. I'm thinking to complex topic expressions or persistence of subscriptions. If you have any real need for something, send an email to the CXF mailing lists ...

Comments

jlmonteiro said…
I was just looking for that.
Glad to see you already committed it ;-)

Thanks Guillaume.

BTW, it was great seeing you again at last Fuse CD

Jean-Louis
2:33 PM
Paul said…
Hi Guillaume,
Thanks for the post. I was waiting for a wsn implementation for a while now, after muse retired. Happy to see cxf took over.
This is my question.
How can I create a wsn notification consumer endpoint with CXFservlet in, say, a tomcat container with spring configuration file.
Thanks,
Paul
11:59 AM
Andre' Simmons said…
Thanks for all of the great posts Guillaume. On my client we are trying to implement federated brokers (brokers notify/subscribe to each other) and users only interact with their local brokers. It seems no one has done this before. Any thoughts?
6:48 AM
Guillaume Nodet said…
Unless I'm wrong, it should already work by using a underlying ActiveMQ network of brokers. The publishers and consumers can then talk to different WSN / AMQ brokers and still be interconnected.
10:16 AM
Andre' Simmons said…
The other brokers are strictly WS-N implementations. Will using ActiveMQ support a WS-N facade?
10:57 PM
Andre' Simmons said…
tachiHello Again Guillaume, We are looking to extend the JAX-WS implementation you did for CXF to support WS-Reliable Messaging and Broker Federation. Any suggestions/tips on how to go about starting this task?
11:34 PM
Andre' Simmons said…
Hello Again Guillaume, We are looking to extend the JAX-WS implementation you did for CXF to support WS-Reliable Messaging and Broker Federation. Any suggestions/tips on how to go about starting this task?
11:35 PM
Guillaume Nodet said…
The best location to discuss enhancements or any technical issues would the CXF mailing lists.
7:38 AM
Post a Comment

Popular posts from this blog

Apache Karaf

ApacheCon was really interesting this year! Recently, a lot of people have expressed a real interest in ServiceMix Kernel , our generic OSGi distribution for server side applications. We've been discussing moving this subproject into Apache Felix for several reasons: raise the visibility and awareness on ServiceMix Kernel attract a broader community Several Apache projects are planning to use ServiceMix Kernel as their container: this includes Apache James , Apache Directory and Apache ActiveMQ . The Apache Sling community is also willing to contribute to this effort along with some other groups like the OPS4J project. During this discussion, a name as been proposed by Jamie Goodyear: Apache Karaf . A carafe is a small container used for serving wine and other drinks (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the Kernel allows applications to be more easily handled, and improves their characteristics (much like a bottle of wine left to breath in a dec...
Read more

Camel Endpoint DSL

Image
Camel Endpoint DSL One of the new features of Camel 3.0  is an Endpoint DSL.  This new API aims to provide a type safe replacement for the URLs that are used in Camel to designate the consumer or producer endpoints.  These URLs provide 3 things: the scheme of the URL identifies the component to use, a unique name or id for the endpoint, and a set of parameters to customize the endpoint behavior. Here is an example of an FTP consumer endpoint definition: from( "ftp://foo@myserver?password=secret& recursive=true& ftpClient.dataTimeout=30000& ftpClientConfig.serverLanguageCode=fr" ) .to( "bean:doSomething" ); There are several drawbacks with such constructs : no type safety, bad readability and no simple completion. So we now use the meta model, which is currently extracted from the source using an annotation processor and written in various JSON files, to generate a fluent DSL for each endpoint.  The same...
Read more

ActiveMQ Pooling

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ . I discovered two things: * ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side). * ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX). The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are no...
Read more