AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=736&pId=-1
Windows Communication Foundation: Steroids for your Enterprise Service-Oriented Architecture (Part I)
page
by Tom Fuller
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 30336/ 33

Introduction

[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.

 

  1. Web services are only invoked via HTTP. Services are not limited by transport. As you will see later in this article, there are a number of other transports that can be used to invoke WCF services.
  2. Web services today are limited to request-reply communications. Services are capable of many other types of communication techniques.
  3. Web services do not contain a robust set of features. Services, on the other hand, have features that allow them to be considered more of an enterprise strength technology set.
  4. Web services are not flexible. The limitations of web services today have created numerous challenges when attempting to satisfy the services are autonomous tenet of service orientation. Services on the other hand remain very agile. The remainder of this article will show how.

 

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.

 

The Unified Programming Model

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.

  1. Typed Services: These services use precise parameterization when invoking a service method call and respond with a well-defined type. Services of this type most often resemble remote components and have limited flexibility when it comes to versioning.
  2. Un-Typed Services: An un-typed service will use XML to transport the input parameters and the response output. These services are the most flexible, but provide very little value back to the consumer. Un-Typed services require a consumer to parse XML in order to understand what it is that a service is returning. This type of service does not adhere to the service boundaries are explicit tenet.
  3. Typed Message Services: This approach for designing services is more message-oriented. In this approach, a custom type is identified that will contain all of the required input parameters and yet another type that will wrap the output parameters. This approach is often referred to as RequestObj / ResponseObj, as these are the types of objects that are often a result of these types of services.

 

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.

 

Defining Endpoints: Then and Now

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.

  1. A is for Address: A WCF service endpoint has a unique address. Addresses are not necessarily something we have not seen with distributed technologies all along. However, in the past this was one of the only qualifying characteristics of an endpoint. In web services, the address was a defined URI; with .NET Remoting, it would be a TCP address.
  2. B is for Binding: Bindings are a portion of the Policy that a service and consumer have to agree on if they want to exchange messages. This binding will contain the information to support the features being exposed by the service. I will cover bindings in more detail in the following section.
  3. C is for Contract: There are a number of different types of contracts with WCF. The primary contract that defines service behavior is the service contract. This is analogous to the portType within WSDL today. This also rounds out the Policy definition of a service.

 

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>

 

The Significance of a Binding

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.

  1. What level of interoperability does this service have?

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.

  1. What type of encoding is used?

Answer: The binding will specify what encodings are supported. Options include Text, Message Transmission Optimization Mechanism (MTOM), and Binary.

  1. What type of transports can be used?

Answer: The binding will limit the transport options. This can include TCP, HTTP, Named Pipe, and MSMQ.

  1. What type of messaging patterns can be used?

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.

  1. What are the location limitations?

Answer: In the case of some bindings, the call cannot go outside of the machine (ex. Named Pipes).

  1. What type of security is supported?

Answer: Options include windows security, WS-Security, and transport level security.

  1. Is transaction flow supported? Are reliable sessions supported?

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

Transport

No

No

WSProfile

WS*

Text, MTOM

HTTP, HTTPS

Request-reply, Simplex

Transport, WS-Security

Yes

Yes

WSProfileDualHTTP

WS*

Text, MTOM

HTTP

Request-reply, Simplex, Duplex

WS-Security

Yes

Yes

NETProfileTcp

.NET

Binary

TCP

Request-reply, Simplex

Transport, WS-Security

Yes

Yes

NetProfileDualTcp

.NET

Binary

TCP

Request-reply, Simplex, Duplex

WS-Security

Yes

Yes

NetProfileNamedPipe

.NET

Binary

Named pipe

Request-reply, Simplex, Duplex

Transport

Yes

No

NetProfileMsmq

.NET

Binary

MSMQ

Simplex

Transport, WS-Security

Yes

No

MsmqIntegration

MSMQ

Text

MSMQ

Simplex

-

Yes

Yes

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.

Conclusion

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

 



©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-18 11:53:50 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search