Get Acquainted With SOA and Indigo (Continued)

Create a Service-Oriented Example
Assume you're implementing a simplified customer support solution based on three primary services: a Help Desk service, a Dispatch service, and a Parts service. When a customer reports a problem, the Help Desk service assigns the problem to a support representative. You can resolve most problems over the phone by the help desk. If the help desk can't resolve a customer's problem, it escalates the problem to an on-site visit. A message is sent to the Dispatch service requesting a technician be sent to the customer.

If an on-site technician determines that a part needs to be replaced, a message is sent to the Parts service with a parts order. The Parts service sends a message to one of several vendors, depending on the specific part that has been ordered.

Now, consider how this solution holds up as time goes by and conditions change. Over time, the volume of customer activity increases until it is no longer practical for the Help Desk service to handle the volume with a single server. Also during this time, company policy changes, requiring technicians to obtain approval from the Accounting department before placing orders for parts. Lastly, the number of parts vendors increases (see Figure 2).

Each of these changes was simple, isolated, and not disruptive to the rest of the system. Customers still send requests to what they believe is the Help Desk service, unaware that it is now actually a router. The Dispatch service still sends out parts orders in the same way, unaware that an Approval service is intercepting them. No other part of the system is aware—or affected by—the fact that the Parts service now supports additional vendors. Despite the improvements to the solution, the original services' interfaces and relationships haven't changed at all.

Let's imagine a more dramatic change-management problem in which changes to one service do affect other services. Perhaps it is no longer sufficient for the Approval service to match the Parts service; the Approval service really needs its own unique interface. If the Approval service changes its interface, the Dispatch service, which calls it, must also change. One approach is to upgrade the Dispatch and Approval services at the same time, so the rest of the solution is not disrupted. Another approach is to add a new interface to the Approval service but continue to support the original interface. This allows the services to be updated at different times: The updated Approval service is deployed first, and the updated Dispatch service follows.

You've seen that the fabric of a service-oriented solution allows for constant change without constant headache. Now that you have a good feel for the principles of SO and the flexible nature of services, it's time to turn to look at Microsoft's technology for taking advantage of services most fully: WCF.

Build Connected Apps With WCF
Windows Communication Foundation (WCF) is the Microsoft platform for creating connected applications (see Figure 3). It was designed from the ground up with SO in mind. The result is a powerful infrastructure for integrated communication and enterprise services with a simple programming model. WCF has been described in several ways: as sockets for the 21st century, as the next generation of Web services, as the Microsoft runtime for services, and as a single programming model for communication and enterprise features. Each of these characterizations is a valid way to think about WCF, and gives you some insight into how you take advantage of it.

Microsoft created WCF with specific goals in mind. Chief among these were delivering a unified programming model, rich communication, broad interoperability, and other enterprise-ready features. WCF's unified programming model brings together a lot of capabilities—some new and some available formerly as separate technologies. The programming model gives you one way of doing things. It's no longer necessary to switch gears as you go from one technology to another. WCF's communication features include multiple transports, multiple message formats, and multiple messaging patterns, allowing you to use the right messaging tools for the right job. On the interoperability front, WCF's communication is fully platform-independent and its services are self-describing. All WCF messages are SOAP envelopes containing XML payloads. WCF follows the Web Services Architecture and uses established standards in its communication, including the WS-* protocols. Service descriptions are expressed using WSDL, XSD, WS-Policy, and WS-MetaExchange.

In the past, interoperability has often come at the expense of features important to enterprises. The benefits of ubiquitous Web services had to be weighed against the consequences of compromised security, transactions, reliability, and performance. WCF overcomes this problem, providing interoperability and enterprise-strength features at the same time. Services can coordinate many sophisticated activities through the use of Web Services Architecture standards, including security, transactions, and reliable messaging. These standards are composable, allowing them to be intermixed. WCF makes use of them as needed based on what your program is doing.

As you would hope with any SO technology, WCF is transport-neutral, protocol-neutral, and format-neutral. For example, services are free to make use of HTTP, TCP, named pipes, and any other transport mechanism for which there is an implementation. You are free to add new transport providers. These details never affect the way you write your services. WCF isolates your program code from communication specifics. This allows services to support a spectrum of communication methods without any extra work on your part.