dotNETwork 5th Gathering – Really enjoyed that Silverlight & SOA Anti Patterns Mix (Part II / II)

So, it has been exactly a week since I have been to dotNETwork 5th gathering. This is yet one of my too late events coverage (maybe I should write a long boring post about why that happens lately in as much annoying details as possible!). Let’s  hope we have something worth the wait this time …

Intro (No tech – you can skip)

This time I’m talking about the second session in the last gathering. The 1st session was already covered earlier. This session is special to me for two reasons: It was delivered by my of my dearest friends in the field, Mohamed Samy. I know Mohamed four years ago, since He was moving from VB 6 to C#, until he became one of the super guys in the field of enterprise computing and architecture in the .NET in Egypt, being a technical architect in ITWorx, one of the top posters in MSDN forums, and finally getting his Solution Architecture MVP lately (which he tells us a story about). The second reason is that I had the pleasure to see the latest part of his preparations for the session, and it was very interesting to see “the making” as well as “the show”.

Anyway, getting back to the session… The microphone stopped working at the very beginning. Mohamed moved to the middle of the rows and looked like a student leader talking to his fellows. this warmed things up a lot as well. He started warming them up by going really quick on his start as a developer, and choosing to continue in the technical career path (technical lead, architecture) while most prefer to take the manager path (project management, etc). He told us about his MVP how he was so happy to earn it in “Solution Architecture” then having the “Solution Architecture MVP” canceled, and having to choose a product specific MVP award instead. He went for “VSTS MVP” as relatively a bit close to his work, having “Solution Architecture” as a “competency” to the “VSTS MVP” award.

As we got lost in our way to the CIC (Canadian Collage, where the gathering took over), he mentioned that software is like finding the CIC, you ask people you find in your way about the road to go, each gives you a different answer. You need to get to that road and not ask again.

Going more into the session


Mohamed went through how “XML” suddenly became a buzzword. People tell you you’ll get rid of SQL and Oracle and replace them with XML files. It’ll solve all developer problems, and all this kind of talks. He bought a 1500+ pages book about being “proficient in XML” and he still didn’t understand what XML is really about. This is a buzz, just like the university sign, it tells you go certain way and everybody just follows. Later Mohamed recognized the simple fact that XML is just a text format based on tags that can be consumed within any platform. This is good because it solves communication problems between platforms (say COM from Microsoft and CORBA from Java) that were problematic because of using specific binary formats not text formats that before XML it was meaningful to prepare an entire PhD on communication between such platforms!

From this example, we see that every buzzword is said to solve all our problems. Few years later, the buzzword will just get deleted in favor of newer one. People need to understand the “concepts” behind the buzzwords not just how to use the tools and technologies related to them. He made fun of how people earlier earned so much money by writing about “Java & XML” when “Java” and “XML” were both buzzwords!

Patterns, Anti Patterns and Architecture

Getting more into the topic Mohamed asked the audience whether they know what patterns are. Well, few did! So, he explained “patterns” as solutions to common problems. He said that even architecture has much to do with this (more on that coming). Same as in building, there`re patterns in designing a living room or even a kitchen (like American furniture designs and such).

What happens is that someone faces a problem and solves it. Someone comes with better solution etc. and many people like it and repeat the same thing when solving the same problem. Someone draws UML diagrams and writes explanations for what the problem is and how the solution works, and this last work is what we call a pattern.

So, if patterns are the common practices we do to solve a repeated problem, then, following naming analogy, Anti Patterns will simply simply what what we should NOT do when soling our problems!

How about architecture? Lets use analogy with architecting buildings again. If a building buildings “designer” (similar to software designers) worries about the best use of spaces inside the buildings themselves, then the “architect” worries about the space “between” each building and the other, the green areas that should exist, where to have a garage, what ration should be between the building size and the width of the street it is build in, etc…An architect worries more about the interaction between systems and each other. Many applications have to talk to each other. Looking at a sample finance application, you may have an HR application that applies bonuses for example, for that, the HR application will have to talk to say a payroll financial application to apply the bonus payment.

But, not all applications run on the same platform, even more, each of them is likely designed in different way than the other. But we still need applications to talk to each others. That’s why we look at standard protocols, like HTTP, HTTPS and such. Those enable us to perform “integration” between those systems.

SOA, Who ??

SOA (Service Oriented Architecture) is an architectural style. What dos this mean? Well, back to buildings analogy. Mohamed showed pictures of example of Islam and Romanian architecture. All the audience could recognize each. The common parts in Islamic or Romanian architecture are what define an architecture style. The common parts between different architectures are what define the architecture style.

When you recall a 3-Tier architecture, you know what you are talking about, data access, business logic and UI. When talking about “Service” Oriented Architecture, you expect to see services.

What is the goal of SOA? Every architecture style has a goal. In buildings, why are the ceilings of the old houses very high? It was a pattern that solves a common problem. They no good fans or ACs back in that time, so, they made ceiling very high so that warm air goes up and less warm air remains in the normal height – to understand what the goal of SOA is, let’s get more on what SOA is.

SOA is an architectural style that emphasizes standards based integration between systems. This means enabling the components of different systems to talk to each other using standards. That’s one reason why WCF is good BTW, because it enables you to make components of the same system talk to each other in binary way, while still allowing components to talk to other components outside the same system using say XML. Clearly, this is not the easiest way to build applications nor one that guarantees success of the system. Not all applications should be built leveraging SOA, actually, trying to do SOA in all applications is a common mistake, Mohamed says. A Point of Sale (POS) application in a really small shop for example, has nothing t do with SOA.

Mohamed gave an example of Egypt back when there was no interaction between countries, all the goods are either made locally or very hard to get. Now, with all worldwide agreements, borders on getting and sending stuff are removed. SOA features standards: HTTP, SOAP, etc… It’s all about friction free interaction between different systems (again, standards based integration). It’s just a way of designing your application, a way of thinking.

Of course there’s lots of buzz/hype around SOA. You hear all that stuff about “Loose Coupling” and such. Some people might say applications should not not even know each other and have locators to tell them how to find each other. These are points of different opinions. Who said you need this overhead (or you don’t)? You still in all times have the overhead of translating from your internal system types and data to the standards format and the reverse overhead on the other system, so, if you are designing say a real time application with thousands of transactions in seconds, SOA will not work. If someone tells you 2e’ll go for SOA to improve performance, just tell him “you are so wrong”!

So, If I understood SOA is designing the system having services communicating with services of other systems using standard protocols like HTTP, and formats like XML, etc, etc… What is a “service” at all then? A service is an interface to your business process. When you are renewing your car driving license, you fill a form that is agreed upon between you and the responsible department, typically (does not quite happen in Egypt) you should be able to give it to only one terminal, without having to know say how many employees it goes to inside. This makes me personally think of a service as a method that will be called remotely with standards protocol and also parameters in standard format that a method caller should not worry about what the implementation of the method actually looks like.

The 4 tenets of SOA

By this we mean those tenets:

  • “Boundaries are explicit”
  • “Services are autonomous”
  • “Services share contract and policy not class”
  • “Service compatibility is about policy”
Boundaries are explicit

Mohamed showed a picture of a country border. There’s a fence, a STOP sign, a guy holding a microphone. If you are going full speed in the highway from Egypt to Libya, you have to stop at the border between the two countries (slows your total average speed). You also have to show say your passport and maybe visa (Authentication and Authorization). Services also have logical boundaries, could require authentication and authorization.

Also, when you re doing a money transfer from a country to another. you need to convert you local units in your country to the other country’s local units. For services, this is changing from the internal data types and schemas in your system to those of the system that has the service you want to connect to. Crossing the boundaries and doing the transfer takes time, that’s why we said that SOA is not the way to solve application slowness.

So, what are the boundaries of each service? We define that when we are architecting our services. We first agreed that those are logical boundaries. An example is, who should be able (and hence responsible) for changing a customer address? A sales application or a marketing application ? This is one kind of the questions we ask our selves when putting the boundaries.

Services are autonomous

If there’s a problem in having fish in Libya, should Egypt be affected by that? Of course no. Same with services. Each service should specialize in one operation. Services should be as least dependent on each other as possible.If service A depends on service B internally and for whatever reason service B is down, Service A should (ideally) still work with 100% its performance, or (more realistic) should provide downgraded performance. It should not be completely stopped.

Back to driving license renewal analogy. If the renewal requires getting your traffic offences, and those are got from say the ministry of justice that is down, it should tell you to come another day, or better off offers to give the renewed license to your house that other day. Note that “another day” is a degraded service.

The point is to make sure to not crash if the dependency is not found or down. Otherwise, a failure in one service, will fail all dependent services, that will cause failure to other services depending on them and so on, that you can easily find your entire company business down because of this.

Services share contract and policy not class && Service compatibility is about policy

The two are related. Back to countries analogy, to get the visa to travel from Egypt to Canada, you need to get police clearance(showing you are not a criminal). This is both a contract and policy. The contract is the police clearance certificate itself. The policy is that if the one applying is a criminal, s/he will not be allowed to get the visa.

For services, the contracts are the schema of data transferred between those services. The contract could be different from platform to another even when using standards. For example, if your service returns a customer record by sending a DataSet containing that record after applying XML serialization, the Java fellows trying to call your service will have hard time parsing the XML that gets generated from this serialization. Instead of that, you should send a typed Customer object XML document. A document that has the information needed clearly without any platform specific additional tags.

Policy is the protocol of the contract. For example, if the service requires authentication/authorization, works on HTTPS not HTTP or so, has certain timeout for results, etc… al this would be parts of the service policy. There’s an overlap between the policy and contract though (is the schema being XML or binary or what a policy or a contract?). In general, the policy is the definition of what’s allowed and required in the conversation between the service and its client (caller).

Thinking of contracts and policies, Mohamed showed that you should not require more data than you need. If your services just changes the address of the customer, it should require a “Customer Address” document not an entire “Customer” object document. This is called “Just Enough” Validation (MSDN). This is good also because the data is meant to come from a likely remote location, requiring less data will make things go faster.

One reminder on polices as well. This is like whether to use SSL or not, what protocol to go to, what to enforce, etc.. Mohamed mentioned the WS-* specifications that can give you in-the-box encryption, trust, transaction and other services, but there was no room to talk about WS-* here as we needed to move to the title of the session, SOA Anti Patterns ….

The Anti-Patterns

The session was originally called “Patterns and Anti Patterns of SOA”, due to time limitation, and prior permission from the dotNETwork guys, the session was split to two parts. One for the patterns, and one the anti patterns, which Mohamed has chosen to start with Anti Patterns as to clear up the thinking before telling us what we should be doing. He’s more interested in what SOA is NOT than what it IS. Let’s see what he talked us about…

Remember, this is what you should NOT do.

Anti Pattern: “CRUDy Interface”

OK, so we want to start SOA, and want to expose our system components as services. Let’s start by the easiest parts. Our system will always have to deal with Create (Insert), Read (Select), Update, and Delete operations (CRUD). Lets create services that encapsulate those – WRONG.

Changing a record can have so many side effects, let’s take an example of changing a customer address. This sounds very direct (update customer set address = …), and that’s it. Not really! If you change a customer address, many things could change as well. Tax rate for example. In Nasr City district in Cairo there’s some area called “Free Zone” or “El mantea’a El Horra”. If your business is in it, you’re exempted from taxes for certain years. If your business is anywhere else in Nasr City or Egypt in general you do not get that. So, changing an address from or to this area even still within Nasr city can have a big effect. Also, you may want to send an email to the branch that the customer will be transferred to when changing address, so, this is taking an action not just changing the address.

It happens in reality. If you change your address in the ID card, it does not affect your driving license, passport info, or bank account. Some guys came with an argument that it should, as al the systems should have the same database. Mohamed said that in reality we could have very good system for banking running ith IBM stuff, a good system for car licenses running on SQL server, while the ID system might be Oracle based. Because the systems are already packaged into different databases and database schemas, they just cannot share the same DB.

Anti Pattern: “Enumeration”

This means something like CustomerService.MoveNext();. A virtual curser  (meaning a pointer, not SQL curser). This allows the client to treat the data and iterate (loop) on them as if they were already loaded to the client, while they’re truly on the server. For the server to be able to enable this. It’ll have to hold the entire list for each client, and that would be a huge performance headache on the server, and the service should not have to worry about caching this and storing the last position and such. Remember (from the tenets) that services are autonomous. A service should care about one operation.

To explain this, Mohamed mentioned a system he joined in the past after it was created. There was too much work done on the DB server for updating recording dependant on each other and/or updating some complex calculations fields, etc.. This was done via SQL dynamic cursors. The cursors have been running all day locking the data in the DB from being accessed by any application.

The point is, the consumer (AKA client) of your service should not be the one who controls your server resources. You have no guarantee who’ll call the services. Even more, you have no guarantee who wrote the code that will call your service (even if you know which system it is via authentication), and you cannot guarantee whether they’re good developers or not.

Anti Pattern: “Chatty Interface”

This is when you require say 5 different service calls to do the same thing. Something like Customer.MarkForDelete(); Customer.Delete();. Two calls to perform deletion. This way you required the consumer to go all the way long from the client to your server and backwards two times instead of one. Well, not just that, how about if “MarkForDelete();” was called first and “Delete();” was never called??

This is actually something you may want to do in some certain cases, but most of the time you don’t. The problems with this are the additional time things will take to perform just one operation, and that it can easily get your data into an inconsistent state. If some of the steps were called and the next steps were for whatever reason not called, your system now has a weird state!

Anti Pattern: “Loosy Goosy”

Why don’t you just make all your services a single services that looks like XmlDocument PerformOperation(XmlDocument input) {…} ? BAD BAD BAD.

The point here is the difference between implicit and explicit behavior. If you do the example above, how would the clients know the way to call a certain operation than another? How will they know what data you need to be filled in the input XML or what to expect in the returned XML? An explicit behavior DOES matter. When creating your services, give them good names that shows what operation each service does perform. When defining your inputs, remember the “Just Enough” Validation rule. Make XML schema for the fields you need only better than using  a bigger XML schema that already exists. A services that updates a customer address only required a CustomerAddress document (With address and ID inside) not an entire Customer object document. You should also be explicit about what the service returns, whether nothing, a document with certain info, etc..

Why is implicit behavior bad anyway? Mohamed gave a very funny example.He went to work on an old COBOL based government system for salaries (salary laws were defined in 1936 and had endless changes afterwards all handled by this system),. The system was a single long routine with no modularity at all, and when trying to make it more modular, Mohamed got stopped at an entry point to the application that takes 3 flags.ZEFT (Asphalt), MIDO (fun name), SOSO (fun name). He couldn’t know what those 3 flags refer to until he asked the people using the system. They told him the woman who created this system has chosen MIDO as per the name of her son, SOSO as per the name of her daughter, and ZEFT (meaning asphalt) as per the name of  ….. whatever :D.

People kept  a notebook including what exactly the operations that are performed when you set ZEFT, MIDO and SOSO to certain different numbers. You can imagine what maintenance nightmare Mohamed found himself in, and this is exactly the nightmare you give your clients when you go for an implicit behavior. Mohamed says it’s like a house of dominos. It doesn’t survive long.

Last thing Mohamed mentioned was about the “Just Enough” Validation. What would you if your system earlier required a customer document with single field for address and now happened to have different fields (Line1, Line2, City,…). You then need to version your services. He showed how this can be done with XML serialization of objects. The main idea is you use your platform native types as long as you are inside the same system’s boundaries, and serialize/de-serialize that to/from different XML documents when returning/accepting XML data in your service. You can apply “version” and “optional” flags to allow versioning of the documents.

Just after the session, I asked Mohamed to show his Links slid, and guess what? He had my blog (with the old GeeksWithBlogs URL he likes more than this one) in his SOA recommended readings!!! I can’t pretend like I didn’t know it, having asked him for the references myself made it very embarrassing to me. But anyway, thanks a lot, Mohamed for this invaluable trust.


As I mentioned before, these are only the Anti-Patterns. The patterns are to come in the next gathering in July (God Willing).

Now to my comment: Mohamed did well for a guy explaining this to people who did not know what design patterns are. I’ve seen few advanced developers sitting in between and they were looking satisfied too. The microphone problem was a good thing for him. Everybody was happy, but for me, I was still missing some. Maybe that’s why he kept kidding with me about along the session “you feeling OK now, Meligy? :D :D” :D :D :D.

I didn’t like that he assumed SOA is all about SOAP and WS-* while other paradigms exist like REST and such, but I cannot blame him at all, as mentioning such would probably cause a huge disturbance to people and could simply get them completely lost. I also was sometimes losing the software example that maps to the building/countries/real-life examples he gave. That was in few cases though. Maybe I just wanted to hear so much technical stuff though! One more thing is that he had a very interesting flow of the talk that he could highlight and clarify a point either before or after its original place in the presentation. This didn’t cause people confusion, but it was really tiring when  came to transfer my session notes into this blog post, that I feel it does not tell the content of the session in a proper way.

Generally it was a very good session. If you could please people with different knowledge levels to good percentages in such a complex topic, then you have done something. Good job, Mohamed. You DID meet my expectations. I’ll be there for the Patterns session (God Willing).

BTW, Mohamed is now working on getting his VSTS related portal, theVSTSguy. I’ll update this blog as soon as he gets it up and running.

dotNETwork 5th Gathering – Silverlight and what ? SOA Patterns, Yay!!

n587461065_1343848_971The 5th dotNETwork gathering will be: Saturday, June 28, 2008.

The agenda is as follows:

12:00 AM – 01:30: Delivering Rich User Experience Applications using Silverlight 2 by Yasser Makram

01:30 PM – 2:00 PM: Coffee Break

02:00 PM – 3:30 PM: Patterns and antipatterns of SOA by Mohamed Samy

03:30 PM – 4:00 PM: Lunch


It’ll be in: Canadian International College Busses will be available at: Nady El-Sekka (11:00 AM – 11:30 AM).

The gathering being on Sunday not Saturday as usual makes it harder to attend it The gathering facebook event said by mistake it’ll be on Sunday, but it’ll be on Saturday normally like all other dotNETwork events.

Regarding the sessions

I do not know about Yasser, but Silverlight 2.0 is a fairly new topic and it’ll sure be interesting to come and see it. I think Yasser will bring us a lot of amazement!

For the SOA topic, I want you all to set high expectations starting now. Mohamed Samy is a Solution Architecture (VSTS) MVP who has worked in and talked about SOA patterns more than most people I have met in person as both a personal passion and a job responsibility as a Technical Architect in ITWorx. I know Mohamed in person and believe he’ll be delivering a rocking session. Do not miss that.


Related Resources



I’ve already started finished my writings. Here are the published blog posts:

Link List 20080617

· Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask

· Functional Programming in C# 3.0: How Map/Reduce/Filter can Rock your World

· MbUnit 2.4 – Avoiding Crappy Data Resulted From The Test

· Managed Extensibility Framework

· IronRuby at Tech Ed 2008

· Velocity: A Distributed In-Memory Cache from Microsoft

· Must See WF/WCF Influencer MSDN Webcasts

· WCF Webcast Series (Old but good)

· Using CSS to Fix Anything: 20+ Common Bugs and Fixes (Found by Mohamed Tayseer)

· A jQuery Client Status Bar

· jQuery for MVC preview 3

· Hands on Labs for Web Client and Smart Client (Web Client Software Factory, Smart Client Software Factory)

· Code Style Review Using Microsoft Source Analysis

· Did you know… You can use Tracepoints to log “printf” or “console.writeline” info without editing your code? – #237

· SOA: Making The Paradigm Shift Part 9 of N

· Functional C# – Learn from F# and LINQ

Enterprise Service Bus Messaging Using nServiceBus

I have been working lately with a big group of fellow developers here in SilverKey on the architecture and design of a relatively big project that required much services and messaging work. We thought that we should implement our public services the REST way using WCF for .NET 3.5, with so many customizations, and that we’ll use a library called nServiceBus for internal messaging. Mohammed Nour wrote a little about thinking in REST.

nServiceBus is a framework for handling publisher/subscriber (pub/sub) model of messaging. It provides reliable messaging via the Enterprise Service Bus (ESB) pattern, and uses MSMQ as the physical bus.

It’s an interesting piece of work to look at actually; of course free, open source. I have been involved in evaluating it for our project, and wrote a document about it as part of my work, so that it’s easier for the rest of the team to use it later. As the documentation for nServiceBus is very limited at this stage of the project, I and my boss Dody decided to share the document with the community.

Another very important reason for this is enabling the nServiceBus group to correct and enhance the document as much as possible. That’s why the document is published under the Creative Commons Attribution-Share Alike 3.0 Unported License.

Download the document

WARNING: This IS going to change, see the nServiceBus Yahoo group for updates to this document.

If you are lazy to download check this out:

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

Revision History

Author: Mohammad Meligy

Revision Number: 1.1


Status: Public Draft

Last Updated:

Feature ID:

Related Document(s):



Revision History    2

Overview    4

Context    4

Glossary    4

Requirements    5

Goals    5

Non Goals    5

Major Features    5

Dependencies    5

Usage    6

How it works    6

Defining the message contracts    6

Writing the code to handle the messages    6

Setting up messaging communication    7

Logging (Optional)    12

Security Consideration    12

Security Constraints    12

FAQ    13




This document shows the use of nServiceBus library ( for managing enterprise messaging using the service bus pattern. The model explained is an advancement of a publisher / subscriber model.


The document is written to be guidance for developers involved in intercommunication between components in enterprise project, however, it is written with no specific relevance to the project components, and can be used for any project that implements this kind of messaging.


There’re some common terms used in this document:

  • Message

    A message is the object that groups the data you want to pass from a module to another module or system for processing outside your module.

  • Publisher

    This is the code that creates the message and puts it publicly to be available for later processing.

    Note: It’s very common when dealing with nServiceBus to call the publisher as a "Client"

  • Subscriber

    This is the code that checks for published messages and passes is responsible for performing any desired operations on them.

    Note that the subscriber that subscribes to a certain request message for example may want to send a response message in return, hence, it then acts as a publisher, and so. It’s normal that the module that acts as a publisher acts also as a subscriber and vice-versa.

    Note: It’s very common when dealing with nServiceBus to call the subscriber as a "Server"

  • Service Bus

    This is the shared message store where all the messages are be written to by the publishers requesting processing, and then later read by the subscribers for processing. Once the messages are delivered to subscribers, they’re typically removed from the message store.




  1. Enable asynchronous messaging across multiple servers.
  2. Ensure reliability for the asynchronous messaging.
  3. Enable a publisher / subscriber model for the messaging.
  4. Enable multiple subscribers to each published message.
  5. Enable a publisher to receive response messages from subscribers.

Non Goals

  1. Enable canceling of already published messages.
  2. Specify the sequence of message subscribers handling via configuration (still available from inside the subscriber code).

Major Features

  1. Setting a server to act as service bus for multiple publishers/subscribers.
  2. Setting the publishers to send messaging to a service bus asynchronously.
  3. Setting multiple subscribers inside a service bus.
  4. Limiting the handling of messages based on their type.


  1. MSMQ – Acts as store for published messages
  2. Spring.NET Library (On all the publisher and subscriber application – included with nServiceBus assemblies) – For initializing the messaging infrastructure
  3. Log4net Library ( – For logging purposes
  4. Serialization (On all the code classes that are included in published / returned messages)




How it works

You create the message type, create a type that holds the processing of the message (called message handler), configure the publisher and create the message instance itself that it publishes to the bus, and, configure the subscriber to subscribe to the bus and map the message instance to new message handler instance.

You’ll notice that the difference between the client and the server is really small. A client publishes a message to one or more primary buses. The server subscribes to the messages it has handlers for that come on the primary bus. But, for the server to be able to send back "response" messages to the client, the client also has its own bus (queue) that it subscribes to for handling response messages.


Defining the message contracts

You define the message type (class) normally in any VS project with certain considerations:

  1. It should implements an interface "NServiceBus.IMessage".

    This interface does not require you to implement any methods / properties.

  2. It should be attributed as "Serializable".
  3. It’s highly recommended that your message have an identity field of type GUID.


This message acts as data contract between the publisher and subscriber, and it should be available to both. This is the actual data that’s being passed between them.



Writing the code to handle the messages

A handler is the business logic that does the actual processing of a message. When the subscriber receives a message, it checks which handler(s) it should call to process this message. A handler is independent from the subscriber and can be used with multiple subscribers though.

When creating the handler type (class), you should either

  • implement the interface "NServiceBus.IMessageHandler<MESSAGE_TYPE>"
  • Inherit from class "NServiceBus.BaseMessageHandler<MESSAGE_TYPE>"

MESSAGE_TYPE is the type of the message to handle.

The two options are equal in effect. You write a method "public void Handle(MESSAGE_TYPE)" where you write the code that actually processes the message.

Note: You can implement the interface multiple times for MESSAGE_TYPE_1, MESSAGE_TYPE_2, etc, and then you have to implement the methods "public void Handle(MESSAGE_TYPE_1)" and "public void Handle(MESSAGE_TYPE_2)", etc.


In this example, the handler just creates a message of a different type (which it does not have to do or have to define) and sends it to the service buss.

The last line has the method "Reply" which accepts "paramas" of message(s) that act as response to the original message and sends the response message(s) back to the queue of the client (who sent the original request message).

Error Codes

To indicate that there was an error processing the message. NServiceBus promotes error codes and creating custom messages that represent the error against throwing an exception.

Here’s a sample code or creating "enum" for wrapping error codes and returning it:


Setting up messaging communication

Now, you have a message type, and a message handler. What’s remaining is writing the publisher that sends this message to the service bus, and the subscriber that asks the service bus to subscribe to any message of the type(s) you want, and before all that, creating the service bus itself.


Preparing the service bus

The first thing you need to do is to create the MSMQ queue that acts as a service bus. The name of the queue will later be available to publishers and subscribers to write messages to / read messages from.


Creating the publisher

The publisher is the code that sends the messages to the service bus through configurations. Before writing anything, you need to add references to the following assemblies:

  1. NServiceBus
  2. NServiceBus.UniCast
  3. NServiceBus.UniCast.Subscriptions
  4. NServiceBus.UniCast.Subscriptions.Msmq
  5. NServiceBus.UniCast.Transport
  6. NServiceBus.UniCast.Transport.Msmq
  7. utils

The way nServiceBus highly promotes is setting the publisher configuration in the app.config/web.config of the Visual Studio project that contains publishing code using Spring.Net configuration.

A typical configuration looks like this:

  1. A configuration section that registers the Spring.Net configurations

    The "Common" and "log4net" parts are optional and are only used in case you want to use logging.

  2. Create the standard sections for Spring.NET

  3. Replace the part "<!– All the required configuration for nServiceBus comes here –>" with the actual configuration to use. A typical configuration looks like:

    The properties that matter in this context are:

  • "Transport"
    • "InputQueue"

      Sets the path to the queue where the messages will be read from. This is essential as the publisher might also subscribe to messages (typically responses to published requests).

      Note: For MSMQ v3 (Windows XP, 2003), this must be a local queue.

  • "Message Owners"

    This connects the message – based on the message type (class, the one that implements "IMessage" interface) – to the MSMQ address where it will be published.

    As shown above, this is written as a dictionary, where:

    • "key": is either the name of the message type (class) – or – the name of an assembly, so that nServiceBus looks inside this assembly and locate all the classes that implement the "IMessage" interface.
    • "value": is name of the MSMQ queue to publish the "key" messages to
  1. Write the actual code that sends the message to the service bus

    In this sample, "RequestDataMessage" is just the message type (class).

    The code is pretty simple, you:

  • Use Spring.NET to create the service buss
  • Create the message itself normally and fill its members
  • Send the message to be published to the bus (This has some alternatives discussed later)
  1. As the message is published asynchronously, you can optionally create a callback method that handles the message. A code for something like that would look like:

    You send the message and sending returns an "ICallback" object. This object has single method "Register" which you use to register "AsyncCallback" delegate to a method that will be called asynchronously when the sever returns a reply, which is "RequestDataComplete" in our example. A sample implementation of this method would look like:

    Clearly, you can see that result returned is a "NServiceBus.CompletionResult" which has both "state" which has the original sent message, and "messages" which has the response messages.


Creating the subscriber

The subscriber is the code that reads the messages published to the service bus, and pass the messages to the messages handler(s) set for it.

The configuration for the subscriber is very similar to the publisher:

  1. Steps 1 to 3 in the publisher are the same for the subscriber
  2. The final nServiceBus specific configurations would look like:

    Note the following sections as well:

  • "Transport"
    • "InputQueue"

      This is the MSMQ queue that the subscriber will listen to.

  • "SubscriptionStorage"
    • "Queue"

      This is the MSMQ queue where the subscription messages will be stored (The mapping between the subscriber and publishers)

      Note: For MSMQ v3 (Windows XP, 2003), this must be a local queue.

  • "MessageHandlerAssemblies"

    This is a list of assemblies to look in for message handler types (classes, ones that implement "NServiceBus.IMessageHandler<MESSAGE_TYPE>"), so that it maps the handlers to the messages it receives

  1. Writing the actual code that subscribes to the bus. This is very simple piece of code

    You can see it’s very simple. You create the "Bus" object from the information in the config file using the "Spring" library, and just start the bus. It loads all the necessary information like which messages to subscribe to and the mapping between message types and message handlers, etc, from the config.

  2. Now you need to deploy the code that runs the server. Note that the bus should be living forever! You’ll want to treat it as you treat a Windows Workflow Foundation Workflow Runtime for example. Either make it an independent Windows Service, or write it in some Application even of the global.asax of a web application.


Logging (Optional)

For the error logging and such, nServiceBus library has dependency on another library called Log4net. You can use that for any kind of logging. Sample logging code looks like:

For Log4net library specific documentation check


Security Consideration

Seeing how nServiceBus works, you notice you have typically two queues, one for the server and another for the client. You also notice that you have two operations for each, read and write.

Security Constraints

To setup MSMQ, you can use public queues, but those are hard to create and are very insecure. Typically you use the default private queues. This causes few constraints on the queue operations.

  • For reading from the queue (AKA subscribing to the bus), the queue has to be on the same machine as the subscriber. You cannot subscribe to a queue that is on a different machine if you are using MSMQ version 3 (like using Windows 2003).
  • To write to the queue (AKA, publish to the bus), the OS process running client/publisher has to be running with a use account that has sufficient privileges on the machine that has the queue you want to write to. This means you’ll typically be running the client and server on two machines in the same LAN with Active directory and sufficient user access, which is a common scenario anyway.


  1. Where to find a copy of the examples in this document or get a working example for nServiceBus in general?

    The code snippets in this document are mostly coming from the "FullDuplex" example that comes with the library source code.

    The source code can be found at:

    For more examples, check the library Yahoo group at:

  2. When I downloaded the nServiceBus source from the library SVN repository I found the configuration much different than described in this document. Any Idea?

    The next version of nServiceBus will have different configuration. It’s not documented here because it’s NOT a complete release yet so is still subject to change before the next release.

    For differences between the configuration of the current release and the upcoming release, check nServiceBus wiki page at:

    There’s also incomplete documentation of the examples on nServiceBus wiki at

  3. Is there any documentation for nServiceBus?

    There are few resources:

However, most of those are either very limited or incomplete.

  1. How do I write the name of a MSMQ queue that exists on a different computer?

    You write the name of the queue in a format like "QUEUE_NAME @MACHINE_NAME"

    MACHINE_NAME is the computer name of the machine that has the queue.
    QUEUE_NAME is the name of the queue itself


Link List: SOA / Architecture + Bonuses

This is the email I sent to SilverKey Tech. Egypt dev team yesterday, sharing here as usual.

Bonuses (AKA, unrelated links – definition)