A while back, 
Windows Communication Foundation (WCF) uber master Juval Lowy, was doing the rounds and proclaiming that every class we DotNet developers wrote could and should be WCF Services. This was all part of the assertion that WCF is as big as .NET itself and in some respects the next .Net. A very interesting idea but nothing I am about to start doing and certainly something I have yet to see embraced. Jimmy Nilsson wrote of a ‘default architecture’, in reference to the use of DDD, but defaulting to a position of ‘every class a WCF class’, just feels wrong.
Udi pointed out a while back that this approach gave cause for concern with regards to performance. If I make every class a WCF Service I am going to end up with heaps of potentially redundant configuration code and or files and significantly pollute my objects with WCF attributes and for me that does not effectively express my intent. Are we meant to make our domain model classes services too? Surely not.
As far as WCF goes for messaging, it does provide an excellent way to move my message over various transports quite simply and uniformly, however it still encourages an RPC way of working and most development I see with WCF does in fact employ that approach. Now I haven’t seen Juval’s training session or presentation on this idea but it seems to me that if every class is a WCF service then I’m pretty likely to end up with JABOWS and frankly pilling up the the Web Services in my architecture is definitely not something I want to do.
Juval was recently in Sydney training and I couldn’t help but wonder if he is promoting this idea as part of his WCF master class now?
In a pod cast on DNR sometime back, with guest Aaron Skonnard, Richard Campbell suggested that it was time for BTS to be made free or at least parts of it. Richard also proposed that such a free product should be tooled as a part of the VS.Net out of the box experience.
I must concur with Richard on this view of the future for BizTalk Server. BTS includes some outstanding tools that developers would find incredibly useful and lowering the price barrier to entry would no doubt see a surge of solutions deployed using BizTalk and increase developer adoption of the product vastly and with haste.
Personally I find the BizTalk Mapper a compelling tool and have found it very useful in transforming data where it would have required significantly more effort to code a solution. One of the interesting byproducts of this tool is that it produces XSLT which can be reused outside of the BTS environment and executed out of band in any CLR process. NICE!
Recently Microsoft also announced the coming release of the R3 CTP for BizTalk 2006 and it included several ’so called’ SOA features. Personally I believe MS should make BizTalk available to developers to deploy at any point of their solutions, whether it be clients or service hosts etc. Give us a tool with BTS like functionality and allow us to deploy it anywhere in our architecture (free of course - just like WCF et-al) and watch the product uptake go through the roof. No doubt Microsoft would be able to find a way to support a free license version and allow for a continued Enterprise version at the more costly prices.
Some of the most visible Service Bus (open source) frameworks around in the DotNet community, utilise MSMQ as their choice of queuing technology. MSMQ usually gets a look in as both a store and forward mechanism and endpoint in those cases. Most would say that the options in the choice for a queuing technology are somewhat limited when it comes to being free and hence we see MSMQ fit the bill here more often than not.
It strikes me however that SQL Server Service Broker IS an option in solving this problem and in doing so we might gain some nice value added benefits . The objections to using SSB in architecting SOA solutions are generally that a multiple SQL Express Service Broker peer solution isn’t possible and that the alternative of having to use Standard or Enterprise Editions might be cost prohibitive (depending on your organisation). This complaint presupposes our intention would include using SSB features such as Services, Conversations / Dialogs etc and that ALL the messaging infrastructure would be taken care of by the out of the box SSB feature set.
Some other possible improvements on the MSMQ scenario are less friction in deployment, backup and administration, not to mention the benefit of having an instance of SQL Server close to applications that might actually be smart clients.
I feel some of my spare (?) time being lost in following this thought and moving it to code!
Windows Communication Foundation (WCF) uber master Juval Lowy, was doing the rounds and proclaiming that every class we DotNet developers wrote could and should be WCF Services. This was all part of the assertion that WCF is as big as .NET itself and in some respects the next .Net. A very interesting idea but nothing I am about to start doing and certainly something I have yet to see embraced. Jimmy Nilsson wrote of a ‘default architecture’, in reference to the use of DDD, but defaulting to a position of ‘every class a WCF class’, just feels wrong. 
