While architecting a framework for an application that is being developed, for which we plan to use 'messaging' as the primary data/information exchange mechanism, use we came across this dilemma: To use MSMQ or Event/Delegate model of .NET
To elaborate a little further, the system would consist of User Data Management, Video Capture, Printing, UI, Remote UI and Remote Control interfaces etc. ALL interactions between these modules would be through messages. The State of each module is expected to manage within the module. For e.g., if video capture has been started, then any further request to ‘start capture’ command form a UI would result is ‘capture in progress’ response.
There are few scenarios where the system state (as a whole) needs to be controlled and certain actions can be executed in a specific sequence. An example is resolving contention between remote UI and local UI or between Remote Control interface and UI or between User Data management and Video Capture (where user data along with the user’s image can not be written to the disk unless video capture has been completed).
The system is being implemented as a single application (with multiple components). However, the foundation (architecture) should be such that
- The coupling between the modules is minimum and interactions should be only through a standard interface (e.g. messages/events)
- It shall be possible to extend and add modules dynamically into the framework without affecting the rest of the system
- It shall be possible to move the components into a distributed environment
Given the above scenarios, it would be interesting for us to hear some comments on:
- Suitability of ‘message oriented architecture’ and Pros and Cons of MOA for such an application
- MSMQ typically has been used for multi-process or distributed applications or for integration of disparate systems/applications. Would MSMQ be suitable for the above described scenario Is it an overkill Will there be performance issues
- Would Events/Delegate mechanism be better
Is there any other framework (e.g. WCF) or architecture that is better suited for this
Thanks,
DeepakGH
MSMQ vs Event/Delegate model as foundation for flexible application architechture?
RBIagric
I did not say that the application should be designed to be 100% distributable (i.e. not each and every object has to be distributable)
What I did say is that you have to plan for distribution in advance - decide up front (during the initial iterations where the architecture stabilize) what will be distributable. The best way to ensure that, IMHO, is to actually make it distributable.
Consider the Eight Fallacies of Distributed Computing - moving to a distributed environment has its costs and its implications, if you fail to consider them during the architecure phase (where the significant, hard to change decisions are made) I think you'd end up with a fragile solution when you actually try to change them anyway later in the game
Arnon
Staffan Bruun
I would recommend having a look at FABRIQ, a high performance messaging framework using MSMQ and WSE2 (with application of Indigo/WCF concepts) to combine loosely coupled components into applications. FABRIQ is mostly a brain child of Arvindra Sehmi, an excellent MS architect, and Clemens Vasters played an important role in its design and implementation. Though I am not aware much has happened with the framework since the beginning of 2005, its concepts and architecture are pretty strong.
m0
From everything that you have said (except for "It shall be possible to move the components into a distributed environment") I think that you should be looking at a component-oriented architecture where components are run in-process with each other. I would strongly suggest a service-layer that would manage workflow between components. Make sure to separate component interfaces from their implemenation, and have inter-component dependencies as follows:
Impl(A) -depends-on-> Interface(B)
and NOT
Impl(A) -depends-on-> Impl(B).
In this kind of situation, I don't think that MSMQ, or any other IPC mechanism is suitable, and you should be looking at simple, interface-based communications; methods are just as good as delegates for loose-coupling when they're defined on interfaces.
As for distribution, remember the first law of distribution: DON'T. (unless you absolutely have to)
And even if you're going to distribute, I don't think that component boundaries are a good place to do so.
askario
Applying a single style of anything will probably not get you very far anyway - if you use only Object Orientation (without other styles like layers, distributed systems, pipes/filters etc.) you would get a single tiered monolith system..
In any events - designing an architecture is a balancing act of different concerns - where many of these concerns originate at the quality attributes of the systems (stability, flexibility, security performance etc. )
Arnon
laura-magma
The message/event idiom is one of many ways to achieve this goal. You should take a look at the GoF Design Patterns - one of which is ths Observer Pattern which refers to the message/event idiom. Another pattern which, to me, describes the MSMQ usage in this case is the Command Pattern - it's the kind of delegate that can also serialize itself and be sent over the network to operate elsewhere. In OOP modules are actually objects and messages are method calls, an interface is the object's definition of what messages it understands - so by using objects you are already using MOA. MSMQ is a tool rather than a design - use it when it fits but don't let it find its way too deeply into your code. MSMQ will help you with reliable delivery of messages, it will not help you reduce coupling.
"2. It shall be possible to extend and add modules dynamically into the framework without affecting the rest of the system"
When your system is written in terms of interfaces extending it should be a breeze. Notify the locations where different modules operate differently and create a suitable common interface for them. I usually use actual (C#) interfaces to do this but any kind of readable contract will do.
"3. It shall be possible to move the components into a distributed environment"
This is a technical issue. I disagree with Arnon's notion of designing up front for this future requirement. A well done design will be adjusted to this situation when the time comes. When the need for distribution arrises it usually involves a relatively small part of the application - the part which seperates the distributed components and handles the calls between them. Designing the entire application to be 100% distributable doesn't seem right here. Programming a distributed application which will eventually be deployed on a single machine is a waste of resources.
kevg
The suggestions in the posts above are in lien with what we have been aiming at and it confirms our thought process as well. Thanks...
Further to suggestions from Arnon and Udi, one could go with a flexible component oriented application. For the sake of argument, if one has to build the complete system based ONLY on event driven architecture (or in this case event/delegate model), there would be many isues as detaield below.
An architecture that is based ONLY on events/delegates would mean flexibility (e.g. being able to decouple consumer and producers, being able to dynamically construct a set of interacting components by instantiating the delegates at runtime thereby making the producer of an event unaware of the consumers and extending it to distributed/remote delegates). On the other hand where ALL interactions taking place thr' the event/delegate model (e.g. any mouse click notifying ALL the consumers irrespective of whether they are interested AT THAT POINT OF TIME or not) makes the architecture an overkill as compared to Interface model.
An event driven architecture would not have any ‘architectural foundation/building blocks’ and would depend upon the event/delegate framework. And ALL the events need to be identified while the system is designed (i.e. if we are replacing the Interfaces with events/delegates) - making it much more complex to build. Any disturbances in the event/message pattern/sequence may lead to different behavior of the system as a whole. Many a times, the sequence of events/delegates need to be handled co-ordinated acros the componets with in the system.
In other words, an event driven architecture would mean flexibility at the cost of robustness, increased complexity of building/integrating, increased testing and maintenance effort.
Any commentsDeepakGH
omarslvd
IMHO, Identifying the way of communication can enable you to make your decission more clearly.
Message queues are better for single direction communications, where a client is sending a message to the server without needing a response of any type. if the messages doesn't need an immediate processing (for example there's a lot of messages sent that cannot all be processed at once), then message queues are perfect.
On the other hand, event based model, would be better for dialogs, where both client and servers are exchanging messages, or one sending message and expecting a response. here it is very difficult to use message queues.
Both solutions can be implemented in a loosly coupled way, loose coupling is not a strenth point for one of them over the other, except if you are implementing the delegates through web services, which is a good choice for the loose coupling.
You can use both solutions. For situations where one way communication is taking place, use message queues. In dialog situations, use delegates.
John Reid
1:As for distribution, remember the first law of distribution: DON'T. (unless you absolutely have to)
but if there is the possiblity that it will need to be distributed later on then
2:think about your system as a distributed one and then maybe deploy it on a single machine ( rather than design it as a local application which you will want to make distributed in the future)
basayana
How "serious" are you about your 3rd requirement (i.e. the need to be able to run the modules in a distributed environment)
If this is an important req. you should probably go with MSMQ (or any other messaging oriented middleware for that matter) - otherwise you can use the event/delegate approach.
Note that when you think about making your application distributed you should also carefully consider the boundaries between the distributed components (which won't, most likely, be equal to the components you currently identified) and the messages that are exchanged between the distributed component - i.e. crossing a boundary of a distributed component is a much bigger deal than calling on a method on a local object (it takes longer, there are security considerations, etc, etc)
Thus if you intend to "just" create a flexible component oriented application you can go with events/delegates.
If you want to create a distributed system MSMQ is a good option to consider, but you need to think about your system as a distributed one and then maybe deploy it on a single machine ( rather than design it as a local application which you will want to make distributed in the future)
Arnon