WCF Projects
I'm currently working on two personal projects, MUnit and a fully transactional/durable MSMQ software architecture (DuraTrans) for distributed applications. Rather than just using WCF for pure messaging, these projects demonstrate how to leverage WCF as the next generation development platform.
MUnit
(Mock Unit testing) makes use of WCFs interception based architecture in an attempt to consolidate unit tests and the application code itself, rather than have to develop and maintain separate test projects. This is achieved by using simple declaritive markup removing the need for test code even in the application assembly itself.
I know how much developers prefer writing business logic and being productive than writing unit tests, but since the industry wants software to be testable I think there's a place for this technique.
DuraTrans
This project demonstrates how to build a service-oriented application that is a fully transactional, secure, scalable, durable (in the event of catastrophic failure) application architecture that leverages the power of WCF and MSMQ.
The durable aspect to this project is where it really begins to shine. Applications are usually built with the assumption that they are going to work. Unit tests mean the code does what it’s expected to do, and end-to-end testing proves the application works at run-time. But what happens if the server your application is running on crashes when it’s trying to process 50 concurrent transactions? Is the data lost? Is the system in an inconsistent state? Is there a contingency plan to automatically recover?
With a durable architecture transactions are fundamental to answering all of those questions satisfactorily. Transactions ensure the system remains in a consistent state. Transactions also work symbiotically with the durable MSMQ to guarantee that messages are not lost during transmission or incomplete processing. The MSMQ can be configured to allow a pre-determined number of attempts to deliver the message. Upon failure, a contingency plan takes over and the message is sent to a DLQ (or poison queue). The DLQ is simply a service that logs the failed message so it can be handled appropriately. All this takes place within transactions, and all this takes place automatically, with no complex plumbing in your code.
DuraTrans Architecture Report
http://code.msdn.microsoft.com/duratrans
MUnit
(Mock Unit testing) makes use of WCFs interception based architecture in an attempt to consolidate unit tests and the application code itself, rather than have to develop and maintain separate test projects. This is achieved by using simple declaritive markup removing the need for test code even in the application assembly itself.
I know how much developers prefer writing business logic and being productive than writing unit tests, but since the industry wants software to be testable I think there's a place for this technique.
DuraTrans
This project demonstrates how to build a service-oriented application that is a fully transactional, secure, scalable, durable (in the event of catastrophic failure) application architecture that leverages the power of WCF and MSMQ.
The durable aspect to this project is where it really begins to shine. Applications are usually built with the assumption that they are going to work. Unit tests mean the code does what it’s expected to do, and end-to-end testing proves the application works at run-time. But what happens if the server your application is running on crashes when it’s trying to process 50 concurrent transactions? Is the data lost? Is the system in an inconsistent state? Is there a contingency plan to automatically recover?
With a durable architecture transactions are fundamental to answering all of those questions satisfactorily. Transactions ensure the system remains in a consistent state. Transactions also work symbiotically with the durable MSMQ to guarantee that messages are not lost during transmission or incomplete processing. The MSMQ can be configured to allow a pre-determined number of attempts to deliver the message. Upon failure, a contingency plan takes over and the message is sent to a DLQ (or poison queue). The DLQ is simply a service that logs the failed message so it can be handled appropriately. All this takes place within transactions, and all this takes place automatically, with no complex plumbing in your code.
The resilience of the system is in it's architecture, and the boundaries in which the services are contained. If the services are down (off-line for maintenance, re-starting, power failure, etc), this doesn't mean the system no longer works, it's merely means that those particular aspects of it are unavailable for now. It's a completely distributed system where each service/client application can run independently of everything else. The client applications can still submit message for processing, and when the services come back on-line, processing continues as normal.
The project follows a closed architecture pattern which helps to reduce internal coupling and is achieved by making each internal component (Manager, BLL, DAL) a WCF service. The benefits of WCF can now be pushed down throughout the tiers.
For example:
What this now means is that developers can now spend more time implementing business logic rather than plumbing. This where real productivity gains can be made, as developers are usually domain experts and not infrastructure (transactions, security, threading and synchronization) experts. What's more, is that the developers don't need to learn a myriad of technologies to do this, because if they know .Net then they already have the lions share of the skills required.
There’s no steep learning curve for implementing infrastructure anymore, as these aspects are now out-of-the-box features that the developer gets for free. Well almost for free, as it’s now just a case of the developer changing their mindset about how they build their application. Once you understand that these infrastructure aspects are now taken care of for you, there’s no need to re-invent the wheel by trying to program them yourself anymore. And when it comes to advanced and complex things to implement like distributed transactions and synchronization, you really don’t want to be doing it yourself unless your name is Juval Lowy.
The project follows a closed architecture pattern which helps to reduce internal coupling and is achieved by making each internal component (Manager, BLL, DAL) a WCF service. The benefits of WCF can now be pushed down throughout the tiers.
For example:
- system.diagnostics can now be used to trace calls throughout an application and log errors, with no change to your code.
- WCF automatically propagates the client security context across service boundaries, with no change to your code.
- Services can participate in ambient transactions (where desired), with no change to your code.
- Services can be extended by adding attributes to the method/interface, with no change to your code.
What this now means is that developers can now spend more time implementing business logic rather than plumbing. This where real productivity gains can be made, as developers are usually domain experts and not infrastructure (transactions, security, threading and synchronization) experts. What's more, is that the developers don't need to learn a myriad of technologies to do this, because if they know .Net then they already have the lions share of the skills required.
There’s no steep learning curve for implementing infrastructure anymore, as these aspects are now out-of-the-box features that the developer gets for free. Well almost for free, as it’s now just a case of the developer changing their mindset about how they build their application. Once you understand that these infrastructure aspects are now taken care of for you, there’s no need to re-invent the wheel by trying to program them yourself anymore. And when it comes to advanced and complex things to implement like distributed transactions and synchronization, you really don’t want to be doing it yourself unless your name is Juval Lowy.
DuraTrans Architecture Report
http://code.msdn.microsoft.com/duratrans
Labels: .Net, durable, MSMQ, service, transaction, unit test, WCF
posted by Stuart Snaddon at
3:01 PM
0 Comments
