Cattaskv2009 Communication

Communication in Cattask v2009

What kind of communication do we need?

In the real production environment, because of the use of network balancing, one CatGlobe site is deployed in three separate servers. Besides, we decided that there will be one "Cattask" for one deployed instance of a site. The running production environment should look like:

The problem is that the three cattasks won't run independently. Instead, they must contact with each others to share information about scheduled tasks, tasks execution...

So what communication technology should we use?

We have investigated 3 communication techniques so far: remoting, WCF and MSMQ. You can find the whole story here Remoting,WCF and MSMQ for CatTask . At the moment, we are designing the module using MSMQ with the help of Rhino Service Bus.

Rhino Service Bus

Rhino Service Bus (RSB) is an ESB which is built on the top of MSMQ. Since the bus behaviours are mainly specified by its configuration file, we'd better look at the configuration to learn how the bus works:

<facility id="rhino.esb" >
    <bus threadCount="1" numberOfRetries="5" endpoint="msmq://localhost/ownqueue" />
    <messages>
        <add name="CatGlobe.Messages.WebShop" endpoint="msmq://web/WebShop"/>
        <add name="CatGlobe.Messages.CatTask" endpoint="msmq://catmaxb/CatTask"/>
    </messages>
</facility>

In short, a Rhino service bus:

• In the <bus> element we can see an end point. It is the queue which the bus monitors for incoming messages. When messages come, the bus will receive the messages from the queue and invoke the appropriate consumers to process them. For example: in the image below, we have a consumer called CatGlobeMessageController which implements the IConsumerOf<HelloCatGlobe> interface. When messages of the type come, the bus will invoke CatGlobeMessageController to process them.

• Can send messages to other queues (of course!!!). The point here is that it has two Send APIs:

       - Send with an explicitly specified end point (queue).

       - Send without a specified endpoint. We need to specify the queues (message owners) of the message type. Notice the <messages> section in the configuration block above: it says that all the messages of types which are defined in the CatGlobe.Messages.WebShop namespace will be sent to the "msmq://web/WebShop" end point. So is the second setting for CatTask.

• Publish/Notify: another feature of RSB is the ability to publish/notify messages to all the buses who are interested in. In order to receive published messages, a consumer must subscribe itself to the producer bus. For example, a bus can subscribe to the CatTask bus that it is interested in messages of the type CatGlobe.Messages.CatTask.TaskCompleted. After the subcription is done, whenever the CatTask bus publishes a TaskCompleted message, one will be sent to the subscriber bus.

Should we use RSB?

At the moment, my answer is YES. Let's consider pros and cons of it:

- Pros:

• It was made and is being contributed by many good developers, well unittested.
• It solves many issues which I ran into when I tried to write my own MSMQ code. Well, I'm not a giant, but I can stand on the shoulder of the giant.
• The built-in logger is very good. It can help us figure out any problem easily.

- Cons:

• RSB is used in the distributed contexts where there may be a delay time between when a message is sent and when it is received. The problem will be raised in the next section.

Buses design for CatTask

- As you can see in the first image, in the new system one site has one instance of CatTask. The user uses CatGlobeWeb to do a CatTask business. CatGlobeWeb passes the business to its own CatTask module. The module, in turn, communicates with other CatTask modules to process the request. Due to the fact that CatTask v2009 is nolonger a service, but is integrated to CatGlobeWeb, doing communication between CatGlobeWeb and its own CatTask is trivial. Thus, the CatGlobeWeb module will almost be ignored in this design.

-