Much of what we can expect from Windows Communication Foundation has been previewed, but what will it put in people's hands that they might not expect?
WCF is a unifying framework for building secure, reliable and transactive services. It's a very rich technology foundation for building distributed service-oriented systems, unifying both messaging style and RPC [Remote Procedure Call] style and at the same achieving platform optimization through binary as well as open standards-based communications. The key thing for me is there is a lot of awareness among the influential set, but I think what's going to get the developer space excited is is the elegance and the simplicity of the programming model. Service-orientation in many circles has gotten this sort of elite mindset to it. I think what WCF will do is it will take this mindset and make it real for the vast majority of the developers and even the architect space.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
If you look at certain sections of the developer and the architecture space people talk about SOA as being this elite, sometimes even esoteric thing. For us it's a mindset, it's a perspective thinking about loose coupling, about contracts, about messages. WCF will take this and make it real in a fairly simple way for the vast majority of our audience.
If you break it down to the fundamentals of loose coupling, I think what's adding to the confusion is the different tacks people take. Some vendors want to think of SOA as being a product or a platform. Some of the folks in the larger services space want to think of SOA as being this big-bang, boil-the-ocean perspective – enterprise SOA, which will take you 24 to 36 months or so. If you break it down and say SOA is fundamentally these principles that can help you address interoperability, integration and agility, it does relate to the vast majority. The elite part is more about the perspective that different vendors, different service providers, even some of the architect community have taken that's added to the intricate nature of how some people perceive it.
Service-orientation in its basic form is something people relate to because it maps very well to how we perceive the business -- IT as a provider of services with consumers acting upon and leveraging those services.Say I'm a Java user, what does WCF offer that ought to make me stand up and pay attention?
Two things. First, the elegance, the simplicity and the straightforward aspect of the programming model. The second thing I would call out would be how well we've mapped the configuration aspects of the service. From an IT admin or developer/architect perspective there is this lack of friction in terms of how do you decide which protocols, which standards, which mechanisms you want to use to communicate. We have some very ambitious goals. We are fundamentally redefining the messaging style and the RPC style of communication. Why does WCF have to be part of Vista? What does this have to do with operating systems?
We do have down-level support for WCF so let me be clear about that. As for why it's coupled with a certain release, we are ramping the .NET framework. There are fundamental aspects of the .NET framework that we want to leverage for WCF. That's really one of the keys.
But there is no hard-coupling of WCF to Vista. If you're a developer working with Windows 2003 you will still have the ability, flexibility and power of WCF.So if I'm using Linux or Solaris, will that be any sort of limitation?
It shouldn't be. The way I think of it is, in this world of distributed, connected systems, the higher event is really the interoperability, the integration, being able to share a common infrastructure or common set of protocols, like WS-*. It's less important that you have the same set of bits on every machine. As long as we can connect and communicate at the infrastructure level and as long as we can have shared semantics of what does a customer or an invoice mean, that is the higher priority. Has the thinking in Redmond changed concerning service-oriented architecture over the past year and how do you expect it to manifest itself in 2006?
I think two things will happen in '06. Service-orientation will become accepted as this pervasive style for architecting systems. Secondly, I think there will be growing realization that service delivery, the classic providing of services, is just one aspect of SOA, that service consumption is really where the rubber meets the road. I talk to a lot of architects, a lot of enterprise customers where IT has this "build it and they will come" perspective. The have this very sophisticated infrastructure for service delivery, for provisioning, for management, for building, but when you talk to the consumer side they don't quite know how to leverage it. I think what will happen is the service consumer will become the higher order and that will be reflected by our investments in Vista and on office tools from a consumer perspective. Unless the consumer gets value you could have the greatest infrastructure for service delivery, but it matters nothing if there's no business value.
At Microsoft over the past couple of years or so, there is this pervasive notion of model-driven design, model-driven development in most things we do. I wish we could accelerate this notion of using model to drive design, to drive communication. We just recently shipped our domain-specific languages toolkit and there will be more work from us on domain-specific languages that I wish we could accelerate. However, there are certain realities in terms of the infrastructure, the tooling and the platform that we have to deal with. The sooner we can get to using models for architects and developers, the better off we would be in terms of building these kinds of systems. Is there anything in Model-Driven Architecture that might be of help there?
MDA on one side is a brand. MDA is also this pervasive notion of platform independence and this almost single-minded notion that you build a model and then this model creates code. Those two things we have difficulty accepting. The platform offers certain advantages and for us it would make sense to leverage the platform as opposed to staying at this academic platform-independent level. Also, we don't believe that there is one language, as in UML 2.0, to describe these models. Look at, for instance, BPEL or XAML. Clearly different domains have different needs, different constraints and so we believe the notion of domain-specific languages makes more sense than constraining yourself to one language where UML is the only language you need. That's why I believe our [ACPI Source Language] investment is really going to pay off for us big time.
To read Part Two of this interview, click here.
This feature originally appeared on SearchWebServices.com.