f there is one truth in software development it is that change is constant. The best any developer can do is to isolate the things that change from the things that stay the same. At all levels of an architecture the fact that things will change must be taken into consideration. Change is an especially touchy issue in the world of Service Oriented Architecture (SOA). Service consumers depend on consistency from services so a change to a service contract can have consequences that ripple through multiple organizations and systems. Managing change is a challenge and comes at a very high cost.

If you are building and publishing your web services using Visual Studio and Windows Communication Foundation (WCF), then you?ve no doubt discovered several key issues with this approach:

• Service clients are tightly coupled to the services. Often, a simple change in the service contract requires all service clients to be touched.
• The software developer is involved in almost every change in the service. Changes in service implementation, contract, and policy all require a software developer.

Versioning of services is difficult if not impossible.

• Service management is not centralized and there is no good way to view all the services currently running in an organization.
• Service clients have a dependency on the service implementation being in place. Because of this, most often, the development of service clients cannot begin until the services themselves are implemented.

Together, these points make developing and keeping an enterprise SOA up and running difficult at best. There is no easy way to isolate service callers from changes in the services they depend upon. Luckily, there are products that can ease this pain. The Managed Services Engine (MSE) is a Community Technology Preview from Microsoft currently in its second release. The MSE addresses these issues through the use of service virtualization. Service virtualization is the addition of a new service fa?ade layer on top of your existing services. This additional layer assumes control over the management of endpoints, policies, security, versioning, and all other non-implementation specific aspects of services. Software developer can once again concentrate on what they care about most, the service implementation. Simply put, the MSE separates the service interface from its implementation.

A Few Words about Windows Communication Foundation
To understand the MCE, you need a grasp on some basic WCF concepts. When talking about services, there are two key components: a contranct and an implementation. The contract defines the operations a service can perform and the data that can be passed to and received from those operations. The implementation is the actual code or business logic behind the service. The service consumer cares only about the contract, because the implementation is hidden behind the service contract. In WCF, an endpoint is responsible for exposing a service implementation at a specific address. The actual service implementation does not (and should not) care about what protocol is being used to access it or how the message data will be formatted. A channel is the component that is responsible for knowing how to deal with a specific communication protocol or formatting type. A binding links a channel with a specific endpoint. In actuality, a binding represents a set of channels (a channel stack) which each, in turn, represent a specific communications mechanism such as HTTP. In this way, each endpoint can leverage a specific binding. For example, an endpoint might use the BasicHttpBinding, which utilizes the HTTP channel. Finally, a service host is responsible for hosting the endpoints along with the related service implementations. WCF also offers an extensibility mechanism known as behaviors. A behavior is a component that can influence or alter the way a message is processed within a specific channel. Throttling is an example of an out-of-the-box WCF behavior. The throttling behavior allows you to control the maximum number of concurrent calls that can be made to a given endpoint. Additional behaviors include error, transaction, and concurrency. WCF also supports the development of custom behaviors.

	?
Figure 1. The MSE Management Console: The MSE allows you to directly manage many of the same items you would expect to configure in the WCF configuration file.

The above discussion is important, because the MCE extends?rather than replaces?the concepts of WCF. The MCE does not replace your service host; it simply acts as a proxy service host that sits between the service client and your specific implementation. If, for example, your WCF service is hosted in Internet Information Services (IIS), it will remain in IIS, but instead of accessing your endpoint directly, the service client would access an endpoint defined within the MCE. In this way, the client is isolated from changes to your implementation and endpoints. The MCE is the only point of entry into your SOA. In addition, many of the management points within the MCE are direct counterparts of those in WCF. Endpoints, bindings, behaviors, and channels, are all present and manageable from within the MSE Management Console?a familiar administrative interface?rather than from an XML-based configuration file (see Figure 1). This decreases the need for a developer for every change.

The MSE Architecture
The MSE is made up of four main components: the service catalog, the messenger, the broker, and the dispatcher. Each component in this architecture fulfills a specific role in the virtualization of services. The service catalog is a Microsoft SQL Server database responsible for storing all configuration and metadata related to your services. The messenger, as the name implies, is not concerned with the specifics of your service but rather, the message. The messenger hosts the endpoints and is responsible for managing any policies and behaviors associated with them. After the messenger has completed processing, the request is sent to the broker. The broker decides exactly which service implementation to use, and chooses an appropriate dispatcher. The dispatcher is then responsible for the actual execution of the service implementation. An MCE Runtime Server can be configured as a messenger, a broker, or both a messenger and broker. In this way, the responsibilities of the messenger and the broker can be installed on a single server or distributed among different servers, allowing your virtualized service architecture to scale out more effectively.

Getting Your Services into the MSE
You can import existing services into the MSE via the ?Import New Service? wizard. This is probably the easiest way to see how to set up a service. The wizard allows you to import an existing service endpoint (via its URI), and automatically creates the appropriate operations, channels, and bindings for you. Once imported, you can create a new endpoint for the operation and point service consumers to the new endpoint URI. To start the wizard, right click on ?MSE Management Console? from the Console and select ?Import New Service.? The Introduction Lab included in the MSE installation does a good job of walking you through the steps required to complete this wizard.

Versioning

	?
Figure 2. Operation Version Properties: The Operation Version Properties allow you to apply an XSL transform to both the request and the response. In addition, a Static Test Response can be specified.

A key feature of the MSE is its ability to version services (see Figure 2). It allows your organization to offer the latest version of a service to all new customers while maintaining previous versions for existing customers. To version a service, you make a distinction between an ?Active? service and a ?Published? service. A service is considered active when it is available via an endpoint. Individual services can be made active and inactive; multiple versions of the same service can be active. A published service is one that is specified in the Web Service Definition Language (WSDL). Only one version of any given service can be published. The combination of being active and published is how the MSE allows multiple versions of a service to exist. Internally, the MSE can host all versions of a service within a single endpoint. The runtime uses the service contract to determine which version of the service to route a request to. In the case where multiple versions have the same contract, the runtime will route requests to the latest active version, unless a specific version is requested by the caller.

Message Transformation and Stubbed Services
Two of the more powerful capabilities of the MCE are the ability to transform message requests and responses and the ability to return static XML in place of a response. The transformation capabilities have many useful scenarios, including allowing access to legacy services without re-coding them, turning HTTP Post operations into web services (this is explored in the HTTP Form Binding Lab included with the product), and allowing legacy clients access to newer web services. The ability to return static XML to callers means that an organization can expose a web service before the service implementation is complete. The result is that, once a contract is specified, development work can begin on both the service client and the service implementation. The dependency between them is essentially removed.

Policies and Behaviors
The MCE allows you to add behaviors to your end points (see Figures 3 and 4). These behaviors are the same ones you would expect in WCF. The advantage here is that they can be managed directly from the MCE Management Console. In the MCE, a policy is simply a list of behaviors that can be associated with an endpoint. The creation and configuration of a policy is covered in detail in the RegEx Behavior Lab included with the MSE installation.

Figure 3. Policy Properties: The Policy definition allows you to define one or more behaviors that can be applied to an endpoint. This example is the out-of-the-box WCF Throttling Override policy, which uses the WCF Throttling behavior.

?

Figure 4. Endpoint Properties: Endpoint Properties: Once created, a policy can be associated with one or more endpoints.

Conclusion
By extending the capabilities already present in WCF, the Managed Services Engine allows any organization to effectively manage their services while also isolating service consumers from changes in contract, implementation, and version. The tight coupling between service consumer and the service itself is eliminated. The implementation and management of services is effectively separated into two distinct tasks, freeing up developers to concentrate on implementation. While the MCE will not eliminate change in your SOA, it will do the next best thing: isolate your service consumers from those changes.