Today, when we build distributed applications, we have a choice of programming models.
Each programming model has a different set of APIs, different feature sets, and a different core set of scenarios:
• ASP.NET Web Services (ASMX) – Our current Web services stack provides basic Web services support and interoperability with Web services running on non-Microsoft platforms.
• Web Services Enhancements (WSE) – A supported extension to the .NET Framework that provides end-to-end standards-based security for Web services.
• System.Messaging – This namespace in the .NET Framework provides managed APIs to MSMQ, enabling developers to build asynchronous reliable distributed applications.
• Enterprise Services – Provided through the System.EnterpriseServices namespace in the .NET Framework, Enterprise Services (or “ES”) provides managed APIs to COM+. COM+ provides component-based programming for doing enterprise critical functionality such as transactions.
• Remoting – Provided through the System.Remoting namespace in the .NET Framework, .NET Remoting exposes the CLR type system remotely and provides location transparency for objects.
While these technologies provide a wide range of functionality, they exist in silos – isolated from one another.
This creates an impedance mismatch across the technologies hindering our ability as developers to “compose” or combine functionality across them. For example:
• You want to use .NET Remoting for it's rich extensibility model, but you want a ES-style transaction to flow. How do you do this?
• You want to use ASMX for its interoperability, but you want to provide direct reliable messaging guarantees. How is this accomplished?
Today, scenarios like these that involve the combination of functionality across these technologies are more of a challenge than it should be. They often involve hundreds and sometimes thousands of lines of code to accomplish.
With WCF, the challenges of silo programming models becomes a thing of the past…
WCF provides you with a unified programming model that brings together the best aspects of existing Microsoft technologies.
What this means is that, with WCF, you will no longer need to wonder “which technology do I use (ASMX, Remoting, etc)” when building a connected system. All of the application-to-application and intra-application communication for your connected will be handled by WCF. This unified programming model is exposed to you through the System.ServiceModel namespace.
Since WCF provides all of the features of these existing Microsoft technologies, WCF supports all of the scenarios currently supported by these technologies.
In addition, WCF enables new scenarios that are currently not possible or very hard to implement with existing technologies because WCF allows you to compose functionality across these existing technologies.
For example, this means that you’ll be able to achieve secure, reliable, transacted Web services by combining/composing the functionality that previously existed in silos.
On a related note, we’re also doing a lot of work to preserve your existing investments in ASMX, ES, and other existing technologies shown on this slide. We do this through a number of mechanisms including the ability to communicate between WCF services and existing ES-based applications for example.
Simplifying the programming model was just one benefit of WCF. Another key benefit is how it enables you to build apps that communicate with other platforms - Interoperability!
Just as organizations collaborated on the basic standards for Web services interoperability (XML, WSDL, etc), they reconvened to begin building the WS-* specifications. These specifications would define the way in which services could interoperate securely, reliably, etc.
Because WCF will support the specifications shown on this slide, we know that the services we write using WCF will be able to interoperate with other platforms and tools that comply with the WS-* specifications.
By default, messages sent from WCF services comply with the WS-* specifications. In addition when possible, we take advantage of performance optimizations. For example, if two WCF services residing on the same machine want to communicate with one another, WCF can use named pipes instead of HTTP. Similarly, in such a scenario the WCF service would default to the binary format instead of text-based XML.
WCF enables you to build services that expose functionality for other applications to call. But what happens when you want to build an application that, for example, models long-running processes that span multiple services…
A workflow is stored as a model that describes a real world process.
Work passes through the model from start to finish and activities might be executed by people or by system functions. Workflow provides a way of describing the order of execution and dependent relationships between pieces of short or long running work.
WF provides a flexible flow model for various types of workflow:
• Sequential workflow in which one task is executed after another
• State machine workflow in which external events drive the flow
• Rule-driven workflow in which a set of rules in combination with the state of data drive the order of processing.