Remember Windows Distributed interNet Applications (DNA)? Appearing on the scene in the late 90s, Windows DNA was a term that defined a collection of Microsoft technologies, including Dynamic HTML (DHTML), ActiveX, and COM+, that was to form an architecture merging the Windows platform with the Internet. For many developers, this was also the first time they had encountered concepts like multi-tier applications and loosely-coupled components. Previously, most of the community had either been writing fat-client Windows applications or simple Active Server Page (ASP) Web applications.
When Windows DNA was introduced, it was quickly followed by a significant amount of architectural guidance. Microsoft moved to define the best practices for creating multi-tier applications, and the development community began to share design patterns that worked. I even wrote two related books—one on the Microsoft Transaction Server (MTS) and the other on COM+. At that time, it seemed that every developer was focused on identifying best practices and creating design patterns for multi-tier applications. When Microsoft.NET was released, developers continued to discuss distributed applications, but were challenged by learning several new technologies before they could absorb the guidance for each of them.
What happened with multi-tier applications reminds me of earlier days when Microsoft was just recognizing the importance of Internet development. Back in the mid-1990s when Microsoft was first introducing the newest tools for Internet development, I remember seeing a demo of a tool called the ActiveX Control Pad. The ActiveX Control Pad was little more than a colorized version of Notepad that helped create <Object> tags for inserting ActiveX controls in a Web page. Watching the demo, it was impossible not to be struck by the fact that the toolset was positively primitive. With the audience somewhat stunned, the presenter then said something that I've never forgotten: "Sometimes to make significant forward progress, you have to start by going backwards". What he meant was that not every advanced tool and technology that existed in the ActiveX world was going to be transferable to Internet development. This was definitely true of the ActiveX Control Pad, and this is exactly how I feel about distributed application development under the .NET platform in the years since DNA.
In an attempt to provide a bridge for developers, Microsoft took many of its existing Window DNA technologies—such as COM+ and the Microsoft Message Queue (MSMQ)—and built them into .NET. They also provided new ways to connect distributed components such as .NET Remoting and Web services. However, the emergence of .NET—just like the ActiveX Control Pad—caused developers to regress. Many developers retreated back to fundamental object-oriented principles and a more simplified Web development model while they learned to use the class framework of .NET. Distributed architecture design patterns became a casualty of the transition.
Slowly over time, as developers digested the .NET Framework, distributed architectures began to emerge again. Most of this development, however, soon became centered on the use of simple Web services. For the average developer, .NET Remoting, Enterprise Services, Message Queuing, and Web Service Enhancements (WSE) were the stuff of Microsoft Web casts, but not everyday development. Now with several years of development experience in place, I feel like it's the late 90s all over again. Developers have mastered the .NET Framework. The languages of VB.NET and C# have now completely replaced Visual Basic and C++ as the way we think and talk. The Windows Communication Foundation is entering a developer community that is primed and ready for its capability. Once again, distributed architectures will take center stage in the developer community.
Windows Communication Foundation is the next generation of technologies for creating distributed applications. Windows Communication Foundation is contained in the System.ServiceModel namespace of the .NET Framework and provides a unified solution whereas Web services, Remoting, Enterprise Services and MSMQ all provided partial solutions to the overall problem of distributed computing. The value of this unification is that developers no longer have to choose between the various capabilities of Web services, MSMQ, Enterprise Services, and .NET Remoting. Along with the lack of effective multi-tier design patterns, distributed application development under .NET long suffered from the fact that each of the available namespaces had different capabilities that were difficult to merge effectively. Therefore, distributed applications were either created as a collection of various functions from different technologies or as a less-than-perfect implementation of a single technology. Now, Windows Communication Foundation gives the developer just one programming model to learn. Using this single model, developers will be able to create full-featured distributed systems.
Unlike previous technologies used to create distributed applications, Windows Communication Foundation is designed from the ground up to build service-oriented connected systems. What this means is that Windows Communication Foundation components must be written to exchange messages, not types. Passing messages between Windows Communication Foundation components allows each component to stand alone. This means that the components may be written in different languages and potentially involve other components on non-Microsoft platforms. As long as each component understands the shared encoding and shared schema that defines the communication contract, messages may be exchanged as necessary to accomplish a task.
Windows Communication Foundation components also have explicit boundaries. This means that Windows Communication Foundation components do not appear as if they are part of the same system. In fact, the best way to think of Windows Communication Foundation components is as a cooperative set of services working together for a common goal. This means that each component can implement security and policies that affect its execution of the shared contract. If you're interested in learning the basics along with a complete example, check out this article from MSDN magazine.
While Windows Communication Foundation offers a strong approach for building new applications, developers may have some issues with existing distributed applications. First, some good news, if you have made a significant investment in Web services, Windows Communication Foundation will interoperate with those services easily. However, if you have built applications based on .NET Remoting you will have to do some work to get Windows Communication Foundation to interoperate. In the case of Enterprise Services, you may also be able to expose some of the components using Windows Communication Foundation as a wrapper.
Once developers have mastered the fundamentals of Windows Communication Foundation, they will look for architectural guidance to be successful when creating production systems. In the past, distributed object-oriented technologies tried to hide the boundaries and the network behind proxies that made remote objects appear local. This made distributed development look simple, but led to problems in more complex applications that needed additional flexibility. The service-oriented approach implemented in Windows Communication Foundation requires the system designer to explicitly delineate the boundaries among software entities, and they will want guidance on how to make those decisions correctly. Fortunately, there are many people working on patterns and practices for Windows Communication Foundation right now so that guidance and tools will be available when the technology ships.
The right place to get started with Windows Communication Foundation guidance is the patterns and practices Developer Center. Here you will find links to several useful resources. Additionally, you should visit Don Smith's blog. Don is a Product Manager with the patterns and practices group doing extensive work creating design patterns for Windows Communication Foundation applications. Don also owns a project on GotDotNet where you can download a software factory for creating Windows Communication Foundation applications.
A software factory provides patterns, application blocks, reference implementations, and new "guidance packages" designed to help developers build specific kinds of applications. Guidance packages are a new way to extend Visual Studio 2005. They appear almost like a project type in Visual Studio, but they are fully configurable and extensible so that they can be modified for your environment. Software factories and guidance packages are the way that Windows Communication Foundation patterns and practices will be given to the .NET development community.
In my mind, the release of Windows Communication Foundation is right on time. Over the last few years, developers have mastered the fundamentals of the .NET Framework. They have also gained significant experience connecting components with XML and Web services. Windows Communication Foundation is a natural extension of these techniques, which should make the technology easier to learn and cut the time required to build our first applications. As developers move into creating production applications and scaling them for many users, software factories will help provide the guidance needed to be successful.
Print
Dzone.com
Digg.com
Slashdot.org
Reddit.com
Del.icio.us