[Download Sample]
Application designers and developers have been attempting to deliver loosely coupled services using technologies like ASMX, .NET Enterprise Services, MSMQ, and .NET Remoting for roughly the past five years. These experiences have proven to be very challenging, and there have been limitations found in each of the .NET programming techniques. The result has been passive adoption by enterprises and constant confusion in the development community on what technology is best suited for delivering building block application components.
Enter Windows Communication Foundation (formerly Indigo). This technology stack from Microsoft claims to be the unified technology best positioned to help developers deliver a service-oriented strategy. In this two-part article I will briefly talk about the goals of a service-oriented architecture. Following that overview, I will describe the feature set that has been delivered with Beta 1 of the Windows Communication Foundation (WCF). As we look at each feature, I will talk about how it overcomes many of the limitations of the previously fragmented approaches. I will also discuss how these features help to reinforce the four primary service-oriented tenets.
Why Do We Care about Service Orientation?
The features delivered with WCF are positioned as the best technology stack to date that facilitates designing and delivering service-oriented components. Service-orientation is often misrepresented as a technology stack itself. In actual practice, service orientation is a design concept. That concept focuses on delivering concise loosely coupled application components that can stand the test of time. Application architects today have a challenging task. The constant pursuit of renewable investments in a companys application development deliverables requires careful planning and extreme flexibility.
There are also other reasons that service-oriented components continue to be the focus of most enterprises. Reusable application components will continue to find new clients that will need to consume them. In the past, component-based code reuse would suffice, but in most companies today the need for cross-platform reuse makes any proprietary strategy very short-sighted. The constant need for agility, platform independence, return on investment (ROI), and multi-client capabilities will continue to drive any enterprise to service-oriented design.
Services vs. Web Services
Most, if not all, conversations about service-oriented architectures progress into a broad overview of the shortcomings of ASMX. One of the most important concepts to realize when looking at the WCF technology is that we are no longer talking about web services alone. WCF is positioned to help deliver services, not simply web services. The following four items help to better describe the differences.
What is Windows Communication Foundation?
Windows Communication Foundation is the unification of all the technologies used to deliver distributed systems that run on the Microsoft platform. WCF is also an evolution of the recent attempts to promote service-oriented delivery on top of the ASMX stack. Microsoft has used the experiences from the industry after delivering the web service enhancements version 1.0 and 2.0 and shipped a consolidated set of features for developing distributed interoperable systems.
WCF can promote service orientation, but it is definitely not limited to that design strategy. WCF can be used just as .NET Remoting and .NET Enterprise Services were in the past. When the application requires physical separation of its tiers, WCF can be used.
At its core WCF is the unification of a number of different technologies. This unification has allowed WCF services to deliver feature-rich components that have transactional capabilities, reliable messaging, transport independence, and time independence. Microsoft has delivered a flexible set of features that allows us to leverage it using a number of different techniques.
The Power of Unification
One of the most obvious benefits of WCF is the unified programming model. This consolidation of programming techniques will translate into increased productivity for all distributed systems developers. Prior to WCF, the programmer who would be best suited for building ASMX services was not necessarily the same as the developer best suited for building COM+ Enterprise Service components. With these technology sets merging, developers will be able to continue to gain strength developing services that have some consistency to them no matter what features they are required to deliver. Although this does not necessarily map back to one of the key SO tenets, it does map back to the goals of any enterprise. When there is an opportunity to create some type of synergy between the developer and their programming model, the efficiency gains are potentially awesome.
Patterns for Message Transfer
WCF presents developers with the ability to use three different messaging patterns: simplex, duplex, and request-reply. Simplex communication provides true fire and forget capabilities when invoking WCF services. This can also be seen commonly referred to as one-way communication. This approach is used when asynchronous write-only services are the design goal for that service. It might seem as though this capability already exists with ASMX today through the use of Begin and End methods. These methods do allow us to invoke a web service asynchronously, but the actual result is still request-reply.
Another of the messaging patterns available is duplex communication. This mode differs from simplex significantly. In this mode, we have true asynchronous two-way communications. With WCF services, if a consumer needs to use duplex messaging, it must provide a service that the WCF service can invoke a callback operation on. The important fact to remember here is the asynchronous nature of the communication. In simplex and duplex communication, the consumer is not locked into waiting for a reply.
Lastly, the most common approach for invoking services is request-reply. It is this technique that we find proliferating web-based communications today. ASMX is exclusively request-reply, and WCF gives us this capability as well. I have often heard that services must be asynchronous in order for them to be scalable. It is true that remaining asynchronous has huge benefits when discussing scalability. This knowledge does not change the fact that most applications need immediate responses. One of the service-oriented tenets states that boundaries are explicit. If you are building services that provide no response, it becomes very difficult to determine the success of our operation. Although the messaging patterns are all very flexible, I see that most of the services being delivered require synchronous request-reply execution.
Declarative, Imperative, or Configuration-Based
WCF has implemented broad flexibility in how you leverage the features available. Many of the features can be used one of three ways: 1) declarative programming, which uses attributes to decorate portions of your code, 2) imperative programming, which uses the object model to set properties directly in the code you write, and finally, 3) configuration-based programming, which gives you the flexibility to make changes at runtime. It is important to note that not all features within WCF can be managed with any of these three techniques; in some cases you are limited to one or two styles based on the feature.
Developers should be practical when choosing between these programming techniques. The most critical decision comes when you decide what should be configuration-based. If you are looking for flexibility at runtime, the configuration-based approach is your obvious decision. The decision to use declarative (attribute driven) or imperative (object model driven) is largely a matter of style.
Service Type Support
WCF provides support for three different types of services. These service types are not necessarily unique to WCF. Similar types of services could be delivered in any number of distributed programming models. What WCF has added is additional types and contracts for supporting these service types in different ways. The following are the three types of services that can be written with WCF.
WCF has delivered various features that support all of these different service types. In the case of typed services, WCF provides out parameters and byref parameters. This gives developers more flexibility in the return types from a service, allowing for method designs that have multiple responses. Un-typed services have had a new type added to the service model. The System.ServiceModel.Message type gives developers the ability to create messages that can be sent to WCF services that have a wide degree of variation. Typed message services can have a WCF message contract added to the custom typed message, allowing a developer to specify how a message is formatted on the wire.
The Service Model
Most of what I have talked about to this point is made possible because of the System.ServiceModel namespace. This assembly is the application programming interface for all of the WCF features I will discuss moving forward. The service model comes complete with a large percentage of the features necessary for common distributed development tasks. That does not mean that this is what you are limited to when programming with WCF. The service model comes with numerous extensibility hooks that allow developers to create anything from custom bindings to custom channel stacks.
One of the most inflexible aspects for distributed development today is endpoint definition. Whether we are talking about the tight coupling introduced by interface definition languages or the rigidity of an ASMX endpoint, a service has very little flexibility once it is being consumed. WCF has made some huge strides in this area. Endpoints are no longer limited to a single transport or a single contract version. More importantly, services are no longer limited to a single endpoint.
Anatomy of an Endpoint
The popular mnemonic being used to remember what an endpoint is comprised of is: Endpoints contain the ABCs of a service. Specifically the ABC portion of that statement is being used to reinforce endpoint definition.
Why Is This Better Than What I Have Today?
Endpoint definition up until now has had little to no flexibility. With the introduction of WCF, multiple endpoints can be defined, allowing service consumers to satisfy a variety of application requirements. If you have a .NET to .NET scenario where you would like to leverage TCP transports and Binary message encoding, then go ahead. Of course, you could do this before with .NET remoting, but what you could not do is have a parallel endpoint that was exposed via HTTP and used text-based SOAP encoding to service a Java client. The flexibility for service invocation has the potential to truly allow services to use policy-based communication. If you wanted to do this today, you would likely have two versions of the service, which would lead to an increased maintenance costs.
Here is an example of an endpoint definition that is hosted in IIS. Use some creativity to envision a scenario where I might want to communicate to this service with a client on the same machine and use named pipe transports. Also notice that when hosting in IIS the address can be left blank and it will default to the location where it is hosted within IIS. This is not much different than what we would do in ASMX today. In the case of the configuration below an appropriate address would be http://localhost/Service/FamilyGuyQuotes.svc.
IIS Hosted Service Config
<system.serviceModel>
<services>
<service serviceType="FamilyGuy.FamilyGuyQuotes">
<endpoint address="" bindingSectionName="basicProfileBinding"
contractType="FamilyGuy.IFamilyGuyGoodies"/>
</service>
</services>
</system.serviceModel>
Bindings describe exactly how a service will be communicated with. Binding definitions specify transport method, encoding, security, and other service feature capabilities. A binding provides a large portion of the information required to define the policy a consumer needs to adhere to if it wants to exchange messages with that service. Depending on the actual binding, different features are either enabled or disabled. Different bindings will also mean different levels of interoperability.
Exactly what does the binding tell us?
Bindings are capable of answering a number of questions about how a client and a service will communicate. Here are the key questions that are answered.
Answer: The binding will specify if communication can take place only in a .NET to .NET scenario, if it is usable by any consumer, or if it can be used by a consumer that adheres to the WS* specifications.
Answer: The binding will specify what encodings are supported. Options include Text, Message Transmission Optimization Mechanism (MTOM), and Binary.
Answer: The binding will limit the transport options. This can include TCP, HTTP, Named Pipe, and MSMQ.
Answer: We discussed earlier the use of simplex, duplex, and request-reply. Depending on the binding, only a subset of those techniques may be available.
Answer: In the case of some bindings, the call cannot go outside of the machine (ex. Named Pipes).
Answer: Options include windows security, WS-Security, and transport level security.
Answer: The binding will specify whether or not these features are supported.
Standard Bindings Delivered in the Service Model
When developing WCF services, the flexibility exists to define custom bindings that can answer the questions above based on the features available in the underlying channels. In most cases, the standard bindings delivered with the service model will satisfy your needs. The following is a list of the standard bindings available and their support for varying WCF features and underlying transports.
Binding
Interop
Encoding
Transport
Messaging
Security
Transaction
Reliable
BasicProfile
Basic
Text
HTTP, HTTPS
Request-reply, Simplex
No
WSProfile
WS*
Text, MTOM
Transport, WS-Security
Yes
WSProfileDualHTTP
HTTP
Request-reply, Simplex, Duplex
WS-Security
NETProfileTcp
.NET
Binary
TCP
NetProfileDualTcp
NetProfileNamedPipe
Named pipe
NetProfileMsmq
MSMQ
Simplex
MsmqIntegration
-
Intermediary
HTTP, TCP, named pipe
This listing is not a comprehensive definition of each of the standard bindings, but it will illustrate some of the limitations introduced. If you want more information on these bindings, you should look at the WCF documentation.
Does This Really Help Me Deliver Services?
The bindings in WCF help to make our communications with a consumer more explicit and truly policy based. This reinforces two of the service-oriented (SO) tenets. What Microsoft has done by enforcing these binding definitions is require consumers to agree to communicate in a specific way. At the same time, the construction of an endpoint allows for the flexibility to use multiple bindings to access a centralized service. You will see later how clients specify the information necessary to use the binding exposed by the service endpoint. At this point, we have become explicit at both ends of our communication.
In the first part of this two part series on Windows Communication Foundation I have introduced a portion of the value proposition and anatomy of WCF services. I have demonstrated the inherent value of the unification of the programming model and the increased agility extended to developers with next generation end points. In the second part of this article, I will explain how contract definition changes, how to configure a client to invoke a WCF service, and how we can host WCF services now and in the future.
References
1. Programming Indigo The Code Name For The Unified Framework For Building Service-Oriented Applications On The Microsoft Windows Platform By David Pallman, Microsoft Press 2005
User Comments