Contents

• Getting Started
•     Overview
•     Video recordings about NServiceBus
•     Architectural Principles
•     Transactions
•     Building NServiceBus from Source files

• Samples
•     Web App Integration
•     Using NServiceBus with ASP MVC3
•     Encryption
•     Full Duplex - Request/Response
•     Generic Host - Logging
•     PubSub
•     Versioning
•     Message Mutators
•     Unobtrusive
•     Data Bus
•     Scale Out

• Day to Day
•     Dependency Injection
•     Support for child containers
•     Logging
•     Messages as Interfaces
•     Introducing IEvent and ICommand
•     Unobtrusive mode messages
•     Unit Testing
•     One way/Send only endpoints
•     Staying updated with NuGet
•     Scheduling with NServiceBus
• Hosting
•     In Your Process
•     NServiceBus Host
•     Profiles
•     More on Profiles
•     32-bit (x86) Host Process

• Management and Monitoring
•     Auditing
•     Monitoring
•     Msmq Information

• Scaling Out
•     Performance Information
•     Multi-Site with the Gateway
•     More about the Gateway
•     Multi-Server with the Distributor
•     Unit of work in NServiceBus V3
•     Unit Of Work implementation for RavenDB

• Publish-Subscribe
•     Overview
•     API and Configuration

• Long-Running Processes
•     Sagas

• Customization
•     Customizing Configuration
•     Pipeline Management Using Message Mutators

• Versioning
•     Migrating to NServiceBus 3.0 – Timeouts

Unobtrusive Sample

In order to see messaging in unobtrusive mode open the unobtrusive sample.

First of all run the solution - you should see two console applications start up. Find the client application by looking for the one with "Client" in its path and press 'C' to send a Command and 'R' to send a Request. Press 'E' at the server application to publish an event.

Configuring Unobtrusive message

Below is a snippet that shows how to pass in your own conventions to determine which types are message definitions instead of using the IMessage interface:

Configure.With()
   .DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith("Commands"))
   .DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"))
   .DefiningMessagesAs(t => t.Namespace != null && t.Namespace.EndsWith("Messages"))
   .DefiningEncryptedPropertiesAs(p => p.Name.StartsWith("Encrypted"));

The code above tells NServiceBus to treat all interfaces/classes with a namespace that ends with “Messages” the same as to messages that explicitly implements IMessage.
As you see you can also specify conventions for the new ICommand and IEvent feature as well.

NServiceBus supports property level encryption by using a special WireEncryptedString property and the last line in the snippet is the unobtrusive way to accomplish that encryption.

Now let's go look at the code:

There are 5 projects in the solution:

1. Client Class library for sending a request and a command to the server and handle a published event
2. Server Class library for handling requests and commands and publish events

3. Commands Class library for defining command and definition for a returned status.
4. Events Class library for defining an event.
5. Messages Class library for defining a request and a response message.

Sample messaging patterns

1. Full Duplex Also known as Send/Reply, In this messaging pattern the client will Send a Request and handle a Response that was Replied by the server.
2. Command In this messaging pattern the client will send a Command to the server that will Return a status.
3. Messages Class library for defining a request and a response message. Please open the references to see that no references are required for NServiceBus libraries.

Send/Reply messaging pattern code

For full sample please visit the Full Duplex sample.

Client side

Message declaration

The following code, at the client project endpointConfig does the messages configuration:

.DefiningMessagesAs(t => t.Namespace != null && t.Namespace =="Messages")

Let's open the client application configuration file (app.config) to see its configuration:

<add Messages="Messages" Endpoint="server"/>

The following is the client code to send the Request:

 Bus.Send<Request>(m =>
{
    m.RequestId = requestId;
});

Server side

At the server side, it is handling the Request in the RequestMessageHandler class and only Replying back to the client as follows:

bus.Reply(new Response
{
    ResponseId = message.RequestId
});

Back to the client code we will find a Response handler code:

public class ResponseHandler : IHandleMessages<Response>

Command/Status messaging pattern code

Client side

Message declaration

The following declaration instructs NServiceBus to use those classes with namespace that ends with Commands the same as to messages that are explicitly implements the ICommand interface

.DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith("Commands"))

Let's open the client application configuration file (app.config) to see its configuration:

<add Messages="Commands" Endpoint="server"/>

The above declaration instruct NServiceBus that the target of ICommand type messages is the Server endpoint.

Bus.Send<MyCommand>(m =>
{
    m.CommandId = commandId;
    m.EncryptedString = "Some sensitive information";
}).Register<CommandStatus>(outcome=> Console.WriteLine("Server returned status: " + outcome));

The client is sending a message and registering a method to handle returned status.

Server side

At the server side, it is handling in the Handle method, and all it is doing is sending back an OK status:

public class MyCommandHandler : IHandleMessages<MyCommand>
{
    readonly IBus bus;

    public MyCommandHandler(IBus bus)
    {
        this.bus = bus;
    }

    public void Handle(MyCommand message)
    {
        Console.WriteLine("Command received, id:" + message.CommandId);
        Console.WriteLine("EncryptedString:" + message.EncryptedString);

        bus.Return(CommandStatus.Ok);
    }
}

The message.EncryptedString is encrypted by the NServiceBus framework since it was declared as follows, in the endpointConfig class (of both client and server):

public void Init()
{
    Configure.With()
        .DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith("Commands"))
        .DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"))
        .DefiningMessagesAs(t => t.Namespace != null && t.Namespace == "Messages")
        .DefiningEncryptedPropertiesAs(p => p.Name.StartsWith("Encrypted"));
}

The above code instructs NServiceBus to encrypt any property that starts with the string Encrypted and resides in any class in the namespaces that ends with Command or Events, or at namespaces that equal to Messages.
The encryption algorithm is declared at App.config of both client and server with the RijndaelEncryptionServiceConfig section name. Please see the Encryption sample for more details.

Publish/Subscribe messaging pattern code

For full sample please visit the PubSub documentation

Client side

Message declaration

The following declaration instructs NServiceBus to use those classes with namespace that ends with Events the same as to messages that are explicitly implements the IEvent interface

.DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"))

Let's open the client application configuration file (app.config) to see its configuration:

<add Messages="Events" Endpoint="server"/>

The above declaration instruct NServiceBus that the target of IEvent type messages is the Server endpoint. In the case of events, it means that the client subscribe to the publishing Server endpoint.

public class MyEventHandler : IHandleMessages<IMyEvent>
{
    public void Handle(IMyEvent message)
    {
        Console.WriteLine("IMyEvent received from server with id:" + message.EventId);
    }
}

Server side

At the server side, it is publishing an event as follows:

Bus.Publish<IMyEvent>(m =>
{
    m.EventId = eventId;
});

When using naming convention to mark your commands events and messages, you can achieve freedom from dependency on NServiceBus message versioning.
As can be seen from this sample, after declaring messages, commands and events, NServiceBus sending and receiving code is identical to a scenarios where the messages interface implementation is done explicitly.

Where to go next?

It might be a good idea now to cover the Message Mutators subject, here.