Indigo (WCF) is going to be huge….
Indigo, or more correctly WCF : Windows Communication Foundation, is going to be huge. After taking a few hours out to read the latest MS white papers on it my immediate reaction was where and when can I get this! I’m currently envisaging the architecture of a large SOA (Service Oriented Architecture) and Indigo appears from even a quick look to be a very good fit for rampantly decreasing the amount of infrastructure coding that would need to be done.
Basically, if you are working on and SOA project, or an SOA/EDA (Event Driven Architecture), there is a multitude of plumbing tasks that needs to be done to allow services to be easily delivered when you get rolling. This includes things like communication endpoint configuration, implementing the correct WS-Security facilities, ensuring these are followed, having common mechanisms to achieve these things irrespective or whether the service is called via a queued or web service interface, handling distributed transactions, etc.
WCF does all this and more. The two main things that I liked about it are the following:
Firstly, you have independence of transport/protocol/binding from the actual service. So if you want a service to be called via MSMQ for some operations, and via web services for others, that’s all supported. In fact WCF appears to provide a commonality across standard web services (think ASMX), MSMQ, Remoting and Serviced Components. The configuration couldn’t be easier and all the WS option you ever wanted, such as security and reliable delivery as well as transactional control are all there.
I can see this halving or more the amount of infrastructure coding that would be required compared to an SOA project that was started today without WCF.
Secondly, MS has taken a big step up from the web services that were provided from VS2002 (.Net 1.0) onwards. Under WCF the tools generate interfaces rather than concrete proxy client and server classes.
Up until and including 2005, Visual Studio and associated tools always generated concrete proxy classes, which meant you wound up with what was a static and frustrating class that you would need to somehow encapsulate further on the client side if you wished to provide added methods for client applications to easily use. In affect you would need to build another entire layer on the client side to gain ease of use, but with much more cost.
Now with WCF you get a client interface class and you simply implement it in your concrete client class. You can do likewise on the server side. Thus both sides are singing from the same hymn sheet and both sides of the contract can implement as they see fit. You can still let the tools generate the proxy client and server classes if you wish, but the tools sensibly do this as a concrete implementation off the generated interfaces.
I personally can’t wait for WCF and will be experimenting with it at home as soon as I can. If you are doing serious SOA/EDA applications development in any environment, check out WCF as soon as you can. If nothing else you can ensure that your architecture is compatible with WCF so that cutting over to it at a future date will be relatively painless. If you don’t get a heads up on WCF, you probably risk reinventing what is going to be a pretty big wheel when it arrives!
An excellent paper on WCF for developers through to architects can be found here:
http://msdn.microsoft.com/webservices/indigo/default.aspx?pull=/library/en-us/dnlong/html/introtowcf.asp
Thanks to Nils van Boxsel from MS Canberra for pointing me in the right direction for WCF.
Basically, if you are working on and SOA project, or an SOA/EDA (Event Driven Architecture), there is a multitude of plumbing tasks that needs to be done to allow services to be easily delivered when you get rolling. This includes things like communication endpoint configuration, implementing the correct WS-Security facilities, ensuring these are followed, having common mechanisms to achieve these things irrespective or whether the service is called via a queued or web service interface, handling distributed transactions, etc.
WCF does all this and more. The two main things that I liked about it are the following:
Firstly, you have independence of transport/protocol/binding from the actual service. So if you want a service to be called via MSMQ for some operations, and via web services for others, that’s all supported. In fact WCF appears to provide a commonality across standard web services (think ASMX), MSMQ, Remoting and Serviced Components. The configuration couldn’t be easier and all the WS option you ever wanted, such as security and reliable delivery as well as transactional control are all there.
I can see this halving or more the amount of infrastructure coding that would be required compared to an SOA project that was started today without WCF.
Secondly, MS has taken a big step up from the web services that were provided from VS2002 (.Net 1.0) onwards. Under WCF the tools generate interfaces rather than concrete proxy client and server classes.
Up until and including 2005, Visual Studio and associated tools always generated concrete proxy classes, which meant you wound up with what was a static and frustrating class that you would need to somehow encapsulate further on the client side if you wished to provide added methods for client applications to easily use. In affect you would need to build another entire layer on the client side to gain ease of use, but with much more cost.
Now with WCF you get a client interface class and you simply implement it in your concrete client class. You can do likewise on the server side. Thus both sides are singing from the same hymn sheet and both sides of the contract can implement as they see fit. You can still let the tools generate the proxy client and server classes if you wish, but the tools sensibly do this as a concrete implementation off the generated interfaces.
I personally can’t wait for WCF and will be experimenting with it at home as soon as I can. If you are doing serious SOA/EDA applications development in any environment, check out WCF as soon as you can. If nothing else you can ensure that your architecture is compatible with WCF so that cutting over to it at a future date will be relatively painless. If you don’t get a heads up on WCF, you probably risk reinventing what is going to be a pretty big wheel when it arrives!
An excellent paper on WCF for developers through to architects can be found here:
http://msdn.microsoft.com/webservices/indigo/default.aspx?pull=/library/en-us/dnlong/html/introtowcf.asp
Thanks to Nils van Boxsel from MS Canberra for pointing me in the right direction for WCF.
posted by Ross W Nelson at 4:38 PM
0 Comments:
Post a Comment
<< Home