The Context

In the previous post I was introducing some tests I did with Play Framework and Web sockets. To summarize, it was just ‘about’ receiving messages on the Play! application and pushing them to the browser. This time, let’s go one step forward: Let’s add some infrastructure stuff to do something more real…

In the current case, I want to introduce a service bus which allows to create a real integration between service consumers and producers (I need to write another article in response to this nice videocast about integration from Zenexity guys ‘EAI & ESB n’apportent rien si les applications ne sont pas intégrables et interopérables’, but I really need more time to explain my thoughs…).
Using a service bus in the current case (and not for this case in fact…) must bring some added value. Here I choose to show that a service bus, even if it is not so lightweight at all, can provide some real cool features that you can have out of the box. Now, let’s add some event stuff to switch to an event-based world where we can have tons of event producers and let’s say thousands of event consumers. Since I can not setup such hude amount of actors, let’s say that we have one event producer and two event consumers:

• The event producer wants to publish some stuff somewhere. To illustrate, let’s say that we have a weather sensor connected to our platform.
• The platform provides a list of topics which producers can use to publish data. One is the weather topic which will be used by the producer above.
• The event consumers want to be notified on new weather data i.e. as soon as the weather sensor publish new data. To keep it simple, they need to subscribe to the weather topic provided by the platform.

To recap, in the event context, the event producer only knows the service he has to push weather data to, the event consumers just have to subscribe to a topic they are interested in. All the knowledge stuff about producers, consumers, topics and all the mapping is delgated at the service bus level. Yes, true it is exactly like in some topic-based messaging stuff because at the end of the day, it is topic-based messaging stuff…

The Stuff

Now we can speak about the stuff we are going to use in the software point of view for notificaiton actors…

Image may be NSFW.
Clik here to view.

• The event producer will not be a sensor but a Play! application. The application sends Web service notifications message to the service bus on a given topic.
• The service bus is (of course) the Petals Distributed Service Bus with some Web service notification modules inside.
• The event consumers are 1/A Play! application exposing a Web service to receive notification it subscribes to and 2/ A local java application displaying OS X notifications using Growl (let’s use JavaGrowl I published some days ago…). Note that the Play! application which have subscribed to notifications pushes them to their clients (browsers) using the funky Websocket stuff.

Let’s look at what really happens in a short video:

• I use the Play! powered application play-soap-wsnclient to subscribe to notification on behalf of the play-soap-websocket Web application.
• In Eclipse, I start a Web service notification powered Web service which subscribes to the same notification topic. Its listener is configured to use JavaGrowl to display incoming notifications.
• I use play-soap-wsnclient to send notification messages to the notification service hosted on the service bus.
• Once received, the service bus forwards the notification to all the subscribers using internal routing and WSN stuff.
• The play-soap-websocket Web application receives a notification and push it to the client browser using Websocket.
• At the same time, the Java application also receives a notification and display it using Growl.

One (or more) step(s) further…

And what if we have something which is not a Web service which subscribes to notifications? With the help of a service bus like Petals ESB/DSB, we just have to add a component which knows how to speak with the subscriber. For example, let’s say that SOAP is bad and that REST is the best thing ever. Can we have REST services receiving notifications? Yes, we can! Let’s just add the REST connector to the service bus. Another protocol/transport/format? Develop and add the new one. This is where the service bus can also help you. Hopefully, there are also other things which are possible with a service bus, we will see it later in other posts if I have time (as usual): Let’s think about business processes, service orchestration, transformation…
Next time we will have a look on what we can do if we use the distributed feature of the service bus, for example, receiving some notifications on one node and be able to notify subscribers which are bound to other nodes…

Source Code

• The event producer Play! application is on GitHub at play-soap-wsnclient
• The event consumer Play! application is also on GitHub at play-soap-websockets
• The Distributed Service Bus is not on GitHub but is open sourced on PetalsLinkLabs

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.