Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

In this post I'd like to talk about an architecture scenario we had recently and how we were able to utilise NServiceBus to help us address this problem.


Cognos is a reporting system used by one of my clients. A while back we developed a web service façade to allow line of business applications to be able to access reports from Cognos to support their various functions.

The service was intended to provide access to reports which were quick running reports or pre-generated reports which could be accessed real-time on demand. One of the key aims of the web service was to provide a simple generic interface to allow applications to get any report without needing to worry about the complex .net SDK for Cognos.

The web service also supported multi-hop kerberos delegation so that report data could be accesses under the context of the end user.

This service was working well for a period of time.

The Problem

The problem we encountered was that reports were now also required to be available to batch processes. The original design was optimised for low latency so users would enjoy a positive experience, however when the batch processes started to request 250+ concurrent reports over an extended period of time you can begin to imagine the sorts of problems that come into play. The key problems this new scenario caused are:

  1. Users may be affected and the latency of on demand reports was significantly slower
  2. The Cognos infrastructure was not scaled sufficiently to be able to cope with these long peaks of load

From a cost perspective it just isn't feasible to scale the Cognos infrastructure to be able to handle the load when it is only for a couple of hour window each night. We really needed to introduce a second pattern for accessing this service which would support high through-put scenarios.

We also had little control over the batch process in terms of being able to throttle its load. We could however make some changes to the way it accessed the reports.

The Approach

My idea was to introduce a throttling mechanism between the Web Service Façade and Cognos. This would allow the batch processes to push reports requests hard at the web service which we were confident the web service can handle. The web service would then queue these requests and process them behind the scenes and make a call back to the batch application to provide the report once it had been accessed.

In terms of technology we had some limitations because we were not able to use WCF or IIS7 where the MSMQ-Activated WCF services could have helped, but we did have MSMQ as an option and I thought NServiceBus could do just the job to help us here.

The flow of how this would work was as follows:

  1. The batch applications would send a request for a report to the web service
  2. The web service uses NServiceBus to send the message to a Queue
  3. The NServiceBus Generic Host is running as a windows service with a message handler which subscribes to these messages
  4. The message handler gets the message, accesses the report from Cognos
  5. The message handler calls back to the original batch application, this is decoupled because the calling application provides a call back url
  6. The report gets into the batch application and is processed as normal

This approach looks something like the below diagram:


The key points are an application wanting to take advantage of the batch driven reports needs to do the following:

  • Implement our call back contract
  • Make a call to the service providing a call back url
  • Provide a correlation ID so it knows how to tie each response back to its request

What does NServiceBus offer in this solution

So this scenario is not the typical messaging service bus type of solution people implement with NServiceBus, but it did offer the following:

  • Simplified interaction with MSMQ
  • Offered the ability to configure the number of processes working through the queue so we could find a balance between load on Cognos versus the applications end to end processing time
  • NServiceBus offers retries and a way to manage failed messages
  • NServiceBus offers a high availability setup

The simple thing is that NServiceBus gave us the platform to build the solution on. We just implemented a message handler which functionally processed a message and we could rely on NServiceBus to do all of the hard work around managing the queues and all of the lower level things that would have took ages to write to any kind of robust level.


With this approach we were able to deal with a fairly significant performance issue with out too much rework. Hopefully this write up gives people some insight into ideas on how to leverage the excellent NServiceBus framework to help solve integration and high through-put scenarios.

Posted on Thursday, May 20, 2010 6:09 PM NServiceBus | Back to top

Comments on this post: Using NServiceBus behind a custom web service

# re: Using NServiceBus behind a custom web service
Requesting Gravatar...
I also feel NServiceBus is a great piece of software and try to find it ways to integrate it into my architectures.

The benefits of the setup you presented will come later as you add more and more actors to speak in the bus, thus leveraging all it's power.

Were you able to distribute the load on multiple Cognos servers using NServiceBus ?
Left by Bogdan Nedelcu on May 23, 2010 6:24 AM

# re: Using NServiceBus behind a custom web service
Requesting Gravatar...
We had some limitations in this scenario over what we could do, but basically we already had one instance of the web service facade on each of the Cognos Web Servers. We then held the queue and windows service also on this Cognos web server.

We are planning to run the windows service with only one or 2 threads for now and with our expected load profile we do not think this will be an issue.

Ideally we would probably have the web service and windows service seperate to the Cognos web server, and a central remote queue but at this point we cant do this for a number of reasons outside of our control.

One of the interesting extensions that I didnt mention above is that with the queued message we can still flow a credential through the nservice bus component and access the report as if we were the original calling user (another post maybe)
Left by Mike Stephenson on May 23, 2010 3:49 PM

# re: Using NServiceBus behind a custom web service
Requesting Gravatar...
This is exactly what I want to do. I looked at the PubSub example and essentially want the Pub bit to be managed via a web service so that anything can publish messages to be handled by my Subs. But I can't see any simple way to publish via the WS directly.

At the moment (only just started looking at NServiceBus), I am using the sample WS project which relies on there being a Server/Host to handle the Process method (otherwise the webservice times out). I then butchered the sample so that the Server project actually publishes the message and then used one of the subscriber projects to pick this up. Great, it works.. but. it's messy. I would like to know how I can have a webservice publish the message using NServiceBus without the need for a separate host running to do the publishing bit.
Left by Ant Hearn on Oct 22, 2010 4:27 AM

# re: Using NServiceBus behind a custom web service
Requesting Gravatar...
Hi Anthony,

Yes i think what you are trying to do is achievable. In our scenario we are not really using the pub/sub features we are really offloading the processing to a background process.

You however should be able to make the web service publish to multiple queues using the pub/sub pattern rather than just use the send operation. The publish in nservicebus is a transactional write to many queues where there is a subscription which meets this message. Normally you would use a queue specifically for the subscriptions and then each endpoint is another queue which would have a backgroud process hanging off it to process the messages.

I think if you look at the diagram in the post you would have the web service sending a message to multiple queues and you would have a background process (the yellow circle) for each destination queue. Remember the more subscriptions you have the more it will affect your latency in this scenario for the web service.

I think there is something in the samples for this

Hope this helps
Left by mike on Oct 22, 2010 4:41 AM

Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: