VISUG Event (03 April 2008): WCF - Beyond endpoint - Juval Löwy

WCF : A brave new world


The Belgian Visual Studio User group (VISUG) had invited no one less than Juval Löwy to present a session on WCF Juval is an authority on the subject and is/was? a member of the advisory comitee of WCF. From the summary on the VISUG website (http://www.visug.be/) you could tell that this wasn't going to be your typical WCF 200 type of presentation (or 300 or 400 for that matter).

Juval immediately set the tone of his presentation (or should I say show) by stating that WCF is a better .NET . WCF will deprecate .NET. During the next hour and a half it took the audience the numerous of demo apps to make his point.

WCF is the next development platform according the Juval. He pushed it a little bit further by saying Microsoft is masquerading this "Truth" from us. He mentions the whole marketing message Microsoft put behind the start of the first version of .NET : .Net is the platform to build web services. We all learned in time that there is much more than web services to .NET. This was primarily done to soothe the organisations and companies that just spent tons of money in making their developers COM- savvy and converted their applications to VB6 / C++ ATL/ COM + . Don't worry, people. We have got this new thing here but it is for web services. Don't be alarmed. By the way we have created VB.NET . You already know half. And yes there were migration wizards and .NET - COM interoperability features. In the end .NET was not so easy ...

Comes along WCF: ....It is a new breed of communications infrastructure built around the Web services architecture ... ( MSDN site) Again they stress onto web services (although the term connected systems is more present in the WCF literature on MSDN) . Again to soothe the companies that have invested in their developers to learn ASP.NET web services but also other technologies like Messaging (MSMQ) , .NET remoting, Enterprise services (COM+). Again ...don't be alarm folks, it is only about web services.



Juval has more visionary message to tell regarding WCF. We are standing again on the foothill of a big mountain. We at the brink of a new paradigm shift. A service-orientation, declarative program model we you , if you like, also can create web services. But the granularity of what a service might be is not solely at level of web services. According to Juval the interception mechanism of the WCF run time can be used at every class. WCF everywhere is the nirvana. At least to Juval. I don't know if he really meant that or just wanted to keep us on the edge. I think the message was as your class need certain services (security, reliability, transactions, etc) And WCF can offer them , why need turn your class into a "service" and leave to plumbing to WCF.
To me that was the thing I learned from the presentation. Don't ever write plumbing code yourself, leave it to the experts. Concentrate on the domain logic.

With a few smart examples he showed us the essence of what WCF can give to you . And the sheer power you sometimes get by just changing the config settings or changing an attribute on a class ( or should I say service). Some of things you of course could do with regular .NET but the amount of effort and knowledge you need to have to do so are so big ,that it can be difficult to defend not using the out-of-the-box features of WCF. And don't talk about the testing effort and maintenance effort you have to put into all this plumbing code (your customer hasn't asked you for in the first place. After the session we al received the WCF resource CD from IDesign with lots of demo's.

But the again developers love to know how things work ( so they can share this "wisdom" with the world in for example VISUG event ...or blogs :-) They love make their own stuff. But like Juval said "By giving a VB programmer the ability the use over the threading library is like giving a child a hand full of blades. They will bleed to dead. " But he immediately added "C++ don't always do it better. They are only more used to seeing blood."

Sometimes we act more as "Google-programmers" . We (me included) look something up . Bend it and shape it a little so it works for us; Put the name of the original author on it and carry on. Sometimes not really really understanding what is going on under the hood. Disasters lurk around the corner.

WCF takes responsibility for all that hard plumbing code . You never should create it on your own (except if you are the plumber). In WCF you actually don't see any plumbing code. All its powers get unleashed by configuration and attributes. Will not writing the infrastructure code yourself doesn't mean you don't need to understand conceptually what is going own or what the annotations are for. In fact Juval mentions that we need to think about the design more than ever but we do not necessarly write it our selves (as application programmer) . The paradigm shift maybe needs a somewhat different approach to the design process and the way we need to structure our applications.

This is the foothill Juval is talking about. Of course he can offer that guidance :-) He wrote a book on the subject (Programming WCF Services) and gives master classes on the WCF and Service Orientation in his own company IDesign .

So enter this brave new world of service orientation. It may like a class but offers so much more . A whole application of services , all running in their own "process" giving you a lot of infrastruture functionality right out of the box.

Still I have some concerns.

• Focus on your own domain code. Leave plumbing to someone else. We heard that one several occasions and other (non-Microsoft) technologies before. In fact in 1996 when Microsoft transaction Server was released as part of option pack for NT4, you already had that notion of interception. In COM+ additional "services" were made available to "objects" hosted in the COM+ space. What is different now? Yes of cours WCF can do lots more. But still COM has been deprecated. (Has it? Office is still COM isn't it ?) and .NET came along. Now WCF is there.
• Companies have invested lots of money in applications running on previous . Programmers have invested time in learning these technologies. Now we have to learn something new again ! Of course in each branch there is a progressing insight how things work and how problems can be solved. Our business the pace is somewhat quicker. If you come to think about it .NET started somewhere in 2001-2002. Time for something new thus . Maybe this is another reason not (as a application developer) get too deep into the nitty-gritty details of something although I must admit... I too like to know how things work). We should concentrate on acquiring domain knowledge or the skill to translate requirements to the platform . So actually the abstraction gap between the real world needs we translate into an information system and the actual code bits gets pushed from both side of the gap. On the one hand coding it becomes more clear, no nuisance of infrastructure code. On the other the whole model-driven movement is trying to find a way to abstract the requirements in such a way "machinery" can kick in to produce the (part) of the code. I think both efforts will find its way to each other. ( Entity Framework, Web Service Factory Modelling edition, Volta, Oslo) . I wonder how this all stand against "agile development"? Are these opposites?
• Technology is one thing. Process (design , methodology) and people are other big variables in the equation. Or maybe synergy is a better word. How will WCF affect our design process. What skills do I need to learn understand WCF and correctly apply WCF. How to do I architect my apps?
• Besides development there is also the operations side. How will this be affected?
• Is WCF everywhere actually feasible with the current WCF. Juval made a special in proc factory to ease some of the config burden. Will this be enough to ease configuration (XML hell ) Will it not be too slow?
• Why is an outside expert promoting this vision? Where are the Microsoft Evangelists? Where is Don Box actually?

Best regards,

Alexander