2013 has ended and it's the opportunity to look back at all the photos I made during the year.
They are mostly landscapes from our trips (Tuscany, Brittany, Barcelona), food and a plethora of portraits of Marion :)
I expect more of the same in 2014 and continue to improve my craft and skills.
There is nothing better for a rainy sunday than cooking some cookies with my girlfriend and make pictures of them to play with my flash and reflectors.
Let's eat them now!
stomp.js is a simple JavaScript library to send and receive STOMP messages from a Web browser using Web Sockets.
Today, I have released its version 2.3.0 that adds support for node.js. This makes it possible to send and receive STOMP message from any node.js app by connecting to a STOMP broker on its TCP port (usually 61613) or on its Web Socket.
I have registered a npm package stompjs that can be installed by typing:
npm install stompjs
and in the code, requiring the module:
var Stomp = require('stompjs');
To connect to a STOMP broker over a TCP socket, use the Stomp.overTCP(host, port) method:
var client = Stomp.overTCP('localhost', 61613);
To connect to a STOMP broker over a Web Socket, use instead the Stomp.overWS(url) method:
var client = Stomp.overWS('ws://localhost:61614/stomp');
Apart from this initialization, the STOMP API remains the same whether it is running in a Web browser or in node.js application.
A simple node.js app that sends and receives a STOMP message can be coded in a few lines:
var Stomp = require('stompjs');
// Use raw TCP sockets
var client = Stomp.overTCP('localhost', 61613);
// uncomment to print out the STOMP frames
// client.debug = console.log;
client.connect('user', 'password', function(frame) {
console.log('connected to Stomp');
client.subscribe('/queue/myqueue', function(message) {
console.log("received message " + message.body);
// once we get a message, the client disconnects
client.disconnect();
});
console.log ('sending a message');
client.send('/queue/myqueue', {}, 'Hello, node.js!');
});
In this example, the client connect to the STOMP broker on its TCP socket by calling Stomp.overTCP(host, port):
var client = Stomp.overTCP('localhost', 61613);
To connect on its Web Socket, you only need to change the creation of the client by calling instead Stomp.overWS(url):
var client = Stomp.overWS('ws://localhost:61614');
This means that if your code uses stomp.js, you can run the same code in the Web browser or in node.js That may prove handy for testing...
Why another STOMP client for node.js when there are already a dozen?
I believe the code of stomp.js is already the best of them.
It is distributed by the major STOMP brokers (ActiveMQ, Apollo, HornetQ, and RabbitMQ), widely used, thoroughly tested and documented.
The STOMP protocol implementation is the same whether the client is running in a Web browser or in node.js. The only differences are the timers and the socket implementations (native Web Socket for Web browser, net.Socket for node.js). The socket implementation can still be customized and many users run it over SockJS
There are likely some corner cases to iron out but the main features (including heart-beating) should work as expected.
Note that the node.js support is done outside the stomp.js file. If you only need to use STOMP from the Web browser, this changes nothing: you only need that file (or its minified version).
Enjoy!
Breathtaking documentary about Teahupo'o surf spot:
The title says it all: I've agreed with O'Reilly Media to write a book about Mobile and Web Messaging.
Almost all my career has been spent developing messaging platforms or clients using messaging. The last few years, I have focused on messaging for Mobile and Web platforms.
This book is the result of all this work and will help mobile and Web developers leverage messaging protocols in their applications.
I plan to introduce messaging protocols and write about STOMP (and most likely MQTT too) in details. The book will come with examples for mobile platforms and Web browsers.
I have setup a web site at mobile-web-messaging.net to promote the book and will tweet about it at @mobilewebmsg.
The target release for the book is June 2014.
For a long time, I wanted to write a technical book and it is a chance to do it about an interesting subject and be published by the best editor for programming books. O'Reilly agreed to publish the book under an Open Source license and the source and examples will be hosted on GitHub (when I have some material to show).
This opportunity is only possible because my employer, Red Hat, allows me to spend some of my work time on this book. Red Hat is an awesome company to work for and we are hiring!
I am incredibly excited about this book and look forward to sharing some sample chapters. I just need to start writing them now! :)
I have released a new version of Stomp over WebSockets.
During my summer holidays, I have simplified its API to make it more object-oriented instead of a simple translation of the protocol frames. The new API is backwards compatible except for the susbcription change.
The documentation has been updated to reflect the new API.
I also created a 2.1.0 release on GitHub to provide a well-known location to download stomp.js (and its minified version).
The connect() method accepts different number of arguments to provide a simple API to use in most cases:
client.connect(login, passcode, connectCallback);
client.connect(login, passcode, connectCallback, errorCallback);
client.connect(login, passcode, connectCallback, errorCallback, host);
where login, passcode are strings and connectCallback and errorCallback are functions (some brokers also require to pass a host String).
The connect() method also accepts two other variants if you need to pass additional headers:
client.connect(headers, connectCallback);
client.connect(headers, connectCallback, errorCallback);
where header is a map and connectCallback and errorCallback are functions.
Please note that if you use these forms, you must add the login, passcode (and eventually host) headers yourself:
var headers = {
login: 'mylogin',
passcode: 'mypasscode',
// additional header
'client-id': 'my-client-id'
};
client.connect(headers, connectCallback);
The message objects passed to the subscribe callback now have ack() and nack() methods to directly acknowledge (or not) the message.
var sub = client.subscribe("/queue/test",
function(message) {
// do something with the message
...
// and acknowledge it
message.ack();
},
{ack: 'client'}
);
Instead of returning an id from client.subscribe(), subscribe() returns an object with an id property corresponding to the subscription ID and an unsubscribe() method.
var subscription = client.subscribe(...);
...
subscription.unsubscribe();
The begin() method returns a JavaScript object with commit() and abort() methods to complete the transaction.
var tx = client.begin();
message.ack({ transaction: tx.id, receipt: 'my-receipt' });
...
tx.commit(); // or tx.abort();
A transaction ID is automatically generated when calling 'begin() and is available in the returned object's id property.
default onreceive method
When a subscription is automatically created on the broker-side, the received messages are discarded by the Stomp.client that find no matching callback for the subscription headers. To workaround that, the client can set a default onreceive callback that will be called if no matching subscription is found.
This is required to support RabbitMQ temporary queue destinations.
By default, debug messages are now written in window.console.
STOMP can now be used from a WebWorker (an example shows how to use it).
STOMP frame fragmentation
If the STOMP frames are big to send on a single WebSocket frame, some web server may have trouble process them. It is now possible to split a STOMP frame on multiple Web Socket frames by configuring the client.maxWebSocketFrameSize (in bytes). If the STOMP frame is bigger than this size, it will be send over multiple Web Socket frames (default is 16KiB).
use the 1st value for repeated headers
Stomp.js was keeping the last value of repeated headers. This has been fixed according to the specification to take the 1st value of repeated headers.
fix generation of timestamp on IE8
We bought a siphon for cooking some time ago and are having fun with it to prepare desserts and starters (we made a mousse de foie gras that was awesome). Yesterday, we prepared a velours de mangue (velvet of mango).
JMS 2.0 has been released a few weeks ago. We are working hard to support it in HornetQ and WildFly and I plan to write a few articles about it.
The main features are described on Oracle Web site in What's New in JMS 2.0, Part One: Ease of Use and Part Two: New Messaging Features.
One of the most important new features is Shared Subscription.
Let's assume you are using a topic to send messages. There are several components subscribed to this topic that are processing the messages in different fashion (for example to process jobs A and B).
When a message M is sent to the topic, all consumers subscribed to the topic receive it:
M +--------------+
---> | consumer CA1 | < a consumer for the job A >
+----------+ M +-------+ / +--------------+
| producer | ---> | topic |
+----------+ +-------+ \ M +--------------+
---> | consumer CB1 | < a consumer for the job B >
+--------------+
The consumer CB1 is subscribed to the topic. Every time, it receives a message, it processes the job B.
Unfortunately, this job is time-consuming and we would like to scale it out by having several consumers for the job B running on different machines.
We can not have several consumers on the topic for this job, otherwise they would all receive copies of the same message and process it several times. What we need is a set of consumers that receives a single message from the topic amongst them.
If the component is running inside a Java EE application server, you can use a Message-Drive Bean for that. If the component is a Java SE application, you are out of luck.
Before JMS 2.0, each messaging brokers has different ways to provide this feature.
With HornetQ, the workaround is to use a divert:
Diverts allow you to transparently divert messages routed to one address to some other address, without making any changes to any client application logic.
We use a divert to route the messages sent to the topic to another queue (let's called it Queue_B since it's for the processing job B). Everytime a message is sent to the topic, a copy is also routed to the queue. Our divert is non-exclusive since we want it to still be received by the topic consumers.
We can then create as many consumers we want for Queue_B. Since this destination is a queue, only one of them will receive a message that was initially sent to the topic:
M +--------------+
---> | consumer CA1 |
+----------+ M +-------+ / +--------------+
| producer | ---> | topic |
+----------+ +-------+
\ +--------------+
\ M ---> | consumer CB1 |
divert \ / +--------------+
\ +---------+ / +--------------+
| Queue_B | -- ---> | consumer CB2 |
+---------+ \ +--------------+
\ M +--------------+
---> | consumer CB3 |
+--------------+
Among CB1, CB2 and CB3, only CB3 received the message sent to the topic.
There are still many shortcomings of using diverts (or similar features) to share consumers of a topic.
Enter JMS 2.0 and its "shared subscription".
A non-durable shared subscription is used by a client which needs to be able to share the work of receiving messages from a topic subscription amongst multiple consumers. A non-durable shared subscription may therefore have more than one consumer. Each message from the subscription will be delivered to only one of the consumers on that subscription.
The basic idea behing sharing a subscription is to have a set of consumers (identified by a shared subscription name) receiving exclusively a message from a topic.
That solves all the issues we originally had in a standard fashion. We can now create many shared consumers with the shared subscription name << sub B >> to have them process messages for the job B and scale out nicely:
M +--------------+
----------------> | consumer CA1 |
/ +--------------+
/ +--------------+
+----------+ M +-------+ / ---> | consumer CB1 |
| producer | ---> | topic | / +--------------+
+----------+ +-------+ \ / M +--------------+
<< sub B >> -- ---> | consumer CB2 |
\ +--------------+
\ +--------------+
---> | consumer CB3 |
+--------------+
Among the shared consumers CB1, CB2 and CB3, only CB2 received the message sent to the topic.
The JMS 2.0 API adds new methods to create shared consumer:
JMSContext.createSharedConsumer(Topic topic, String sharedSubscriptionName)
JMSContext.createSharedConsumer(Topic topic, String sharedSubscriptionName, String messageSelector)
It is also possible to create shared durable consumers:
JMSContext.createSharedDurableConsumer(Topic topic, String name)
JMSContext.createSharedDurableConsumer(Topic topic, String name, String messageSelector)
Sharability and durability of subscriptions are two orthogonal notions and all the combination are possible:
JMS 2.0 is an incremental update to JMS that should simplify any Java application using messages. Shared subscription is one of this interesting new features.