Here are a couple interesting questions to ask youself.
- Could Windsor be extended to inject a Java dependency into my class? This would involve adding some distributed computing code to Windsor. The code would have to be very standards-compliant for the interop scenario.
- Could a WCF Service host inject class dependencies into my service layer classes?
- Could WCF or Windsor be extended to provide event-based mediation between two decoupled classes?
You see, not many people have noticed, but there is a common thread of thought amoung these very different technologies. One groups works over there and uses one set of terminology. Another group works elsewhere using a different set of terminology.
I would like to fundamentally challenge each and every person who reads this post on their view of WCF, COM+, and Windsor.
Context-Based Class Services
You see, each of the three technologies rely on the same underlying ideas--even if they have different names. They all manage the environment in which a class instance runs.
WCF manipulates the environment (think behaviors and binding) to enable distributed computing. It does this to handle interop scenarios (ie..with Java). It does this to handle various activation scenarios (singleton anyone?). It handles transactions. It also handles a whole host of other things. Some would argue that WCF works quite well even for services on a single server (they do have an named pipes transport after all).
Windsor manipulates the environment (think Castle.DynamicProxy) to provide a very similar set of context-based services. It handles lifestyles (singleton anyone?). It can handle transactions (with a little extra help). And it handles a whole host of other things (not to mention IoC).
COM+ also manipulates the environment (using Contexts) to provide a nearly identical stack of services as WCF and Windsor. Transactions? Yep. Activation/Lifestyles? Yep.
Yes, windsor is much more light weight. That's beside the point. These three things are all built on the exact same patterns.
They all value configuration over code (which is slightly different than the ruby value statement).
If you are using Windsor today, is there a reason why WCF couldn't replace Windsor in your codebase (if someone were to create both local and remote IoC behaviors)? Remote dependency injection, now there's a concept. What if your Windsor configuration was replaced by a centralized repository (ie..a service which might live on another machine) that was used to resolve dependencies? What if Windsor understood UDDI for configuration?
If you are using WCF today, is there a reason that Windsor couldn't replace WCF if there was a remoting-type stack built into Windsor? What if Windsor could interop with Spring.NET? It parallels the Java/.NET Interop of WCF.
Ironically enough, even COM+ had publish/subscribe. Neither Windsor nor WCF offer any type of publish/subscribe facilities/bindings.
At some point, these things need to converge. They all do the same thing. WCF was an evolution of COM+, but we still see sets of features that are missing.
The truth is, they all provide Component Services.
What if Microsoft built local and remote IoC into WCF? What if that also included basic Pub/Sub?