NServicebus V4.0 Release

A new version of NServicebus ( V4.0 ) was released on July 11, 2013.  There are many changes in this release of NServiceBus. Too many to describe them all individually. You can find the full release notes on the following link.  Major highlights:

Until V3.3, MSMQ was the main queuing system. With V4.0, a couple of new transports were introduced:

• ActiveMQ
• RabbitMQ
• SQL Server ( for people that want to use database tables as queues )

Also, the RavenDB is embedded in the solution for this version.  Before this version 4, you had to install it seperately.

And now you can also try NServicebus online including some hand-on labs. Everything is pre-installed so can start directly!

With this version, NServicebus is now part of the Particular Software platform. A platform because along with NServiceBus, a couple of other products are made available as well.

 

ServiceMatrix is a modeling tool that allows you to design a solution on a high level of abstraction.

You get an overview of the services you use, the contracts those services expose …

 

ServiceInsight allows you to manage your queues and endpoints, check your audit/error queues and get a full stacktrace to check what’s wrong.

There is also a 3rd product coming - ServicePulse - but this is in pre-beta (or should we say alpha?).
 

 

Author: Sven Van den brande

Getting started with NServiceBus, Request-Response example

In this blog post we explain some request-response example that we mentioned in the previous blogpost.

Below you can see the first steps to do, before we really can start with sending some messages.

  - Go to http://www.nservicebus.com à Downloads
  - Download the msi file under the “Get version 3.3.1 now” button.

 

   - Install the msi file on your system.
   -  Now you can find under “All programs > NServicebus v3.3.1” a Welcome to NServiceBus link.

You can click on the samples link to go to the samples. Or you can choose a sample below. We will talk about the “FullDuplex – RequestResponse” sample. Copy past the location of the sample and open it with visual studio. You will get the following solution.

The client is going to send a message to the server, the server will process the message and return it back to the client.

Let’s run the server and client application. You should see some screens like below.

Now we can exchange some messages between server and client. Let’s hit the “Enter” button in the Client Console. The client sends a message to the server with a Guid, which is received by the server and the server sends a message back to the client.

As you can see, this is not a real life scenario. What if the client is down? What if the server is down.

Let’s now start only the client application.

As you can see we send a message from the client to the server, but we don’t get some reaction back from the server because we didn’t start the server application. You don’t lose the message because NServicebus uses MSMQ and the message stays in the queue.

When we look in the MSMQ queue, you can see that there is a message.

Now we open the message, there you can find the DataID in the message. This ID is the same as on the Client application.

Now we can start the server application.

You can now see that the server picks up the message to process it. And send it back to the client.

I hope you enjoyed reading this blogpost.

Author: Sven Van den brande

What is NServiceBus

NServicebus is designed for collaboration between different services. It’s not just a replacement for WCF, BizTalk, ….. You can easily combine NServiceBus with BizTalk.

For BizTalk, the communication goes through one central box. We can call BizTalk a Broker style. All the information goes through BizTalk itself.

NServiceBus is something different. It’s more a peer-to-peer architecture that works on the message queues from Microsoft ( MSMQ ). So NServiceBus will do all the communication between systems with MSMQ. When you handle your message you still need to do the further communication.

When one of the “servers” go down because some hardware failure,... the communication between the other systems continues. This is some key feature for NServiceBus because you can keep sending messages. When the systems comes back online after the repair. It will get all the messages from the other systems, because they hold their  messages in the queues .

                                       

Now you know the basic difference between some other Integration tools. Like always a demo/example says more than thousands words.  So in the next blog post we will setup, the NServiceBus Environment and let you see some simple example about Request / Response.

Do you want to read more about NServiceBus, stay tuned!

Author: Sven Van den brande