With a wealth of experience going back to his involvement on the .Net advisory council and more recently with the Windows Communication Foundation (formally known as Indigo) strategic design review, it’s not surprising IDesign founder Juval Lowy is considered one of the world’s top experts in all things .Net.
As a Microsoft “Software Legend” and Microsoft’s regional director for Silicon Valley, Lowy is taking his vast knowledge around the world in a series of Windows Communication Foundation (WCF) master classes to share his expertise on building secure, reliable and interoperable service-oriented applications.
Before he arrived in Australia to host his WCF Master Class, Lowy took time out to share his thoughts on the changing landscape of software development and its future.
What advantages does WCF offer over other frameworks?
WCF is Microsoft’s implementation of a set of industry standards defining service interactions. WCF unifies the previous generations of Microsoft’s technologies, offering the interoperability of ASP.Net web services, the extensibility of remoting and the productivity and power of Enterprise Services. There is just a ton of off-the-shelf plumbing to use, something nothing else offers over standards.
What makes WCF a good platform for developing service-oriented applications?
It is designed from the ground up for that. You cannot tack it on things like raw .Net or Windows service-oriented architecture (SOA) — they are just unaware of it. WCF enforces many of the SOA tenets, and enables the rest. It is deliberately different from classic .Net — there is no type-sharing, it is all based on message exchange, and it supports most of the industry web services standards that facilitate services interoperability. Not only that, there is a ton of built-in plumbing that does all the hard work for you.
Can you detail some features of the built-in plumbing that takes care of the hard work for developers? And can you specify the hard work it eliminates?
In a decent-sized application, the bulk of the effort, the development and the debugging time is spent on addressing plumbing issues such as hosting, instance management, asynchronous calls, synchronisation, reliability, transaction management, disconnected queued calls and security, as opposed to focusing on business logic and features. To make things even worse, since the end-customer (or the development manager) rarely cares about plumbing (as opposed to features), the developers are not given the adequate time required to develop robust plumbing.
Instead, most hand-crafted plumbing solutions are proprietary (which hinders reuse, migration and hiring) and are of low quality because most developers are not security or synchronisation experts and because the developers were not given the time and resources to develop the plumbing properly. In WCF, all that plumbing is built in. You write business logic, and you let WCF glue it together, expose it as a service, secure it, host it, manage the instances, propagate transactions for you, enlist resources, synchronise access to the service by concurrent client, throttle callers, queue up calls for you and so forth. This is huge in terms of boosting productivity.
Can you highlight some of the common pitfalls in WCF programming and how developers can avoid them?
Developers often think WCF is about web services, while in fact it is actually the “new C#” or the new .Net.
Developers try to learn WCF on the job, and that is just not possible. I see all the time developers equating one-way calls with asynchronous calls, or turning off security because they cannot make it work. They must allocate the time to attend training, read the top books and articles, and experiment before they move into production.
What’s the one idea or lesson that people who attend this master class should leave with?
That developers should focus on business logic and not on plumbing. Let WCF provide the plumbing for you. That is the only fighting chance you have to deal with the complexity of modern applications, the aggressive deadlines and the limited budgets.
Why did you start working with .Net and what has kept you developing on it for so long?
I was invited to a strategic design review of .Net when it was still on the drawing board. The various .Net program managers who taught me .Net, invited me to sit on the design reviews, and I was hooked.
I never looked back to C++, where I spent my entire career before .Net. And this was when I was a contributing editor to the C++ Developers Journal. I spoke at the C++ developers conference and I wrote a book on C++. The productivity boost of .Net was too impressive to turn away from.
What’s in store for the future of software architecture and more specifically .Net?
We will see at some point a service-oriented language, where the basic construct is not a class, but a service, where every integer is transactional and every string is secure. We are probably a few years away though. We will also see the Workflow Foundation being more mainstream, on-par with C#, and being used by non-professional developers, much like VB was at the time.What is halting the evolution of a single service-oriented language?
Technology takes time to evolve. There is huge inertia with existing code-bases and applications, organisation maturity and process, developers’ skills and so forth. There is also a grave need to address the problem of the present, not of the future. But more than anything, software is not perceived or practised as an engineering discipline.
There is a multi-dimensional industry-wide crisis that drives the cost and effort of ownership of software through the roof and unless we do something about it this industry will eventually find it uneconomical to develop software in the West.
It’s not that you cannot do good software — clearly there are plenty of fine examples of both high-quality products and well-managed companies that are within the adequate limits of budget, time-to-market and quality — but that tends to be the exception rather than the rule.
Unlike almost any other engineering disciplines there is no regulated licensing process or industry standard. There is no requirement for studying software engineering in order to program for a living.
Hardly any university in the world is teaching software engineering as opposed to computer science, and there is at least as wide a gap between the two as between teaching physics and teaching mechanical engineering.
On top of all this, there is a huge skill gap between what most developers should know and what they actually do know, and that translates into a gap between what most developers should be able to do and what they actually produce. Most organisations lack development process maturity for producing good software, and most projects resemble a lucky strike or a death march, with little repeatability. I am not even talking about good design, architecture or security.
All of these reasons [apply], despite the fact that software development is a highly engineering-oriented activity and that we have both the process and the design methodology to do it right. This is really what is holding back the industry.
What’s holding back the Workflow Foundation from being mainstream at this moment?
It is at the core a development tool, oriented for developers — not business analysis, domain experts, product managers or end-customers. As soon as you deviate from the garden path you need to be a hardcore developer. At some point I assume this will get better.
What are some of the biggest and best changes you have seen over the evolution of .Net?
The addition of generics, ClickOnce and .Net 2.o’s transaction infrastructure.
What’s in store for the future of SOAs?
I think next we need to take care of the clients. We solved the service side, the client is still way behind. Perhaps a fusion of WF with a service-oriented language to drive things. We should also see other players besides Microsoft, things like SCA that will support all those standards on the Java side. Presently there is precious little consistency there in terms of comprehensive offerings.
And finally, what is the most important lesson you have learned from being a .Net developer?
That the future belongs to the smart client, not the web client.