The Larger Move to SOA

Looking at what WCF provides, you will find that it is supporting of a larger move that organizations are making to the much-discussed SOA. Keep in mind that an SOA is a message-based service architecture that is vendor-agnostic. This means you have the capability to distribute messages across a system, and the messages are interoperable with other systems that would otherwise be considered incompatible with the provider system.

Looking back, you can see the gradual progression to the service-oriented architecture model. In the 1980s, the revolutions arrived amid the paradigm of everything being an object. When object-oriented programming came on the scene, it was enthusiastically accepted as the proper means to represent entities within a programming model. The 1990s took that one step further, and the component-oriented model was born. This enabled objects to be encapsulated in a tightly coupled manner. It was only recently that the industry turned to a service-oriented architecture, once developers and architects needed to distribute components to other points in an organization, to their partners, or to their customers. This distribution system needed to have the means to transfer messages between machines that were generally incompatible with one another. In addition, the messages had to include the capability to express the metadata about how a system should handle a message.

If you ask 10 people what an SOA is, you'll probably get 11 different answers, but there are some common principles that are considered to be the foundation of a service-oriented architecture:

• Boundaries are explicit—Any data store, logic, or entity uses an interface to expose its data or capabilities. The interface provides the means to hide the behaviors within the service, and the interface front end enables you to change this behavior as required without affecting downstream consumers.
• Services are autonomous—All the services are updated or versioned independently of one another. This means that you don't upgrade a system in its entirety; instead, each component of these systems is an individual entity within itself and can move forward without waiting for other components to progress forward. Note that with this type of model, once you publish an interface, that interface must remain unchanged. Interface changes require new interfaces (versioned, of course).
• Services are based upon contracts—All services developed require a contract regarding what is needed to consume items from the interface (usually done through a WSDL document).
• Schemas are used to define the data formats—Along with a contract, schemas are required to define the items passed in as parameters or delivered through the service (using XSD schemas).
• Service compatibility that is based upon policy—The final principle enables services to define policies (decided at runtime) that are required to consume the service. These policies are usually expressed through WS-Policy. A policy provides consumers with an understanding of what is actually required to consume a service.

If your own organization is considering establishing an SOA, the WCF is a framework that works on these principles and makes it relatively simple to implement. The next section looks at what the WCF offers. Then you can dive into building your first WCF service.

As stated, the Windows Communication Foundation is a means to build distributed applications in a Microsoft environment. Though the distributed application is built upon that environment, this does not mean that the consumers are required to be Microsoft clients; nor is any Microsoft component or technology necessary to accomplish the task of consumption. Conversely, building WCF services means you are also building services that abide by the principles set forth in the aforementioned SOA discussion, and that these services are vendor-agnostic—that is, they can be consumed by almost anyone. WCF is part of the .NET Framework and is available to applications targeting .NET 3.0 or later.

Capabilities of WCF

WCF provides you with the capability to build all kinds of distributed applications. You can build Web services just as you could previously in earlier .NET Framework releases. This means that your services will support SOAP, and therefore will be compatible with older .NET technologies, older Microsoft technologies, and even non-Microsoft technologies (such as any Java-based consumers).

WCF is not limited to pure SOAP over a wire; you can also work with an InfoSet, and create a binary representation of your SOAP message that can then be sent along your choice of protocol. This is for folks who are concerned about the performance of their services and have traditionally turned to .NET remoting for this binary-based distribution system.

The WCF framework can also work with a message through its life cycle, meaning that WCF can deal with transactions. Along with distributed transactions, WCF can deal with the queuing of messages, and it allows for the intermittent connected nature that an application or process might experience across the web. Of course, what WCF truly provides is a framework to communicate with tools that support many of these capabilities. It's not that WCF provides a message store and forward capability so much as it supports the protocols used in message store and forward.

When you need to get messages from one point to another, the WCF is the big gun in your arsenal to get the job accomplished. For instance, many developers might consider using WCF primarily to communicate ASP.NET Web Service–like messages (SOAP) from one disparate system to another, but you can use WCF for much more than this. For instance, WCF can be used to communicate messages to components contained on the same machine on which the WCF service is running.

This means you can use WCF to communicate with components contained in different processes on the same machine. For example, the same service might be called by a WPF application using a binary format within your organization, while the same service may expose an endpoint hosted on a web server and accessible over the Web via HTTP and SOAP. You use WCF to communicate with components on the same machine or on another machine—even accepting calls from a client that is not a Microsoft-based machine.

Contracts and Metadata

Probably the biggest and most exciting part of the WCF model is that it enables you to develop a service once and then expose that service via multiple endpoints (even endpoints on entirely different protocols) via simple configuration changes. These changes start with the interface definition. As part of creating a service you'll be able to define an interface, and that interface has two top-level contracts.

From an implementation standpoint a contract is an attribute that is associated with either an interface or a class definition. The <Service Contract> is used as part of an interface definition. That interface will expose a series of <OperationContract> method definitions, which describe what services this service provides.

A Service Contract with at least one operation is required in order to have a service. Without this minimum definition there isn't anything to call. The methods within the ServiceContract interface are attributed with the <OperationContract> to define the various interfaces.

Optionally, if your service is going to accept data types other than primitive types, it needs to provide metadata to define these data types. A <DataContract> attribute can be associated with one or more classes to define these custom data structures. An interface does not need to expose any custom data structures, but if it does, it needs to determine which properties of the class to include in the interface. Each property to be exposed is associated with a <DataMember> attribute to identify it as part of the DataContract.

Working with the WS-* Protocols

WCF understands and can work with the full set of WS-* specifications, and these specifications can be enabled to create messages that meet defined ways of dealing with security, reliability, and transactions. A few of these protocols and an understanding of how messages are managed are important enough to take a closer look at their implementation details.

Messages, as defined by the Messaging layer, rely on SOAP (sent as open text or in a binary format). The advanced WS-* specifications make heavy use of the SOAP header, enabling messages to be self-contained and not have any real reliance on the transport protocol to provide items such as security, reliability, or any other capability beyond the simple transmission of the message itself. Message Transmission Optimization Mechanism (MTOM) is a capability to replace Direct Internet Message Encapsulation (DIME) as a means to transmit binary objects along with a SOAP message. An example binary object would be a JPEG image that you want to expose through a WCF service.

The security implementation in WCF enables you to work with WS-Security. Before WS-Security came along, the initial lack of a security model in Web services kept many companies from massively adopting them companywide and moving to a service-oriented architecture. WS-Security addresses the main areas that are required to keep messages secure—credential exchange, message integrity, and message confidentiality.

To do this WS-Security supports implementing security at two levels. The first is at the message level. WS-Security enables entities to provide and validate credentials within the messages that are exchanged. Alternatively WS-Security also enables transport level security. This form of security focuses on establishing credentials based on the transport protocol, for example, using HTTPS to securely transmit data.

With message-level security WS-Security enables two entities to exchange their security credentials from within the message itself (actually, from the SOAP header of the message). The great thing about WS-Security is that it doesn't require a specific type of credential set to be used. Instead, it allows any type of credentials to be used. In addition, it is possible to send messages through multiple routers. In effect, this allows your solution to bounce messages from here to there before they reach their final destination while ensuring that the messages are not tampered with in transport. As messages move from one SOAP router to another, these SOAP nodes can make additions to or subtractions from the messages. If such SOAP nodes were to get into the hands of malicious parties, the integrity of the messages could be compromised. This is where WS-Security comes into play.

The other area in which WS-Security helps is when you need to have WS-Security encrypt all or part of your SOAP messages. When your messages are zipping across the virtual world, there is a chance that they might be intercepted and opened for viewing by parties who should not be looking at their contents. That's why it is often beneficial to scramble the contents of the message. When it reaches the intended receiver, the application can then use your encryption key and unscramble the message to read the contents.

WS-SecureConversation works to establish a connection that enables entities to exchange multiple messages and maintain their established security arrangements. WS-Trust, conversely, works in conjunction with WS-Security and allows for the issuance of security tokens and a way in which entities can exchange these tokens. This specification also deals with establishing trust relationships between two entities.

WS-ReliableMessaging allows for reliable end-to-end communications of messages to ensure that they are delivered.

The Transactions section allows for the use of WS-Coordination and WS-AtomicTransaction. WS-Coordination is there for the purpose of addressing the description of the relationships that multiple services have to one another. As a company starts developing a multitude of services within its enterprise, it realizes that many of the services developed have a relationship with one another, and that's where WS-Coordination comes into play. This specification is meant to be expanded by other specifications that will further define particular coordination types.

WS-AtomicTransaction uses WS-Coordination and WS-Security to allow for the definition of a service transaction process. An atomic transaction is a way of creating a transaction process that works on an all-or-nothing basis. These are meant to be short-lived transactions, so when you use them you are locking data resources and holding onto physical resources such as connections, threads, and memory.

The main point of this discussion is to emphasize the slew of WS-* specifications at your disposal. Even better, when working with WCF you really don't have to be aware that these specifications are even there—you can access the capabilities these specifications offer through programmatic or declarative programming.