If 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.
To understand the MCE, you need a grasp on some basic WCF concepts. When talking about services, there are two key components: a contract 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.
The above discussion is important, because the MCE extendsrather than replacesthe 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 Consolea familiar administrative interfacerather than from an XML-based configuration file (see Figure 1). This decreases the need for a developer for every change.
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.