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
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
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
IIS Hosted Service Config
<endpoint address="" bindingSectionName="basicProfileBinding"
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.
Request-reply, Simplex, Duplex
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
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.
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