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.
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.
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.
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. Click to enlarge
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.
This article was first published on DevX.com.