Virtualization at the Endpoint?

Aaron Skonnard describes the Microsoft Managed Services Engine (MSE) over at MSDN.

Service virtualization is nothing new, of course - it's a pattern that underlies most SOA middleware products (ESBs) and agents (Actional, AmberPoint,..). Hosting platforms (WCF, App Servers) also provide rudimentary virtualization on top of the business logic.

The strength of virtualization lies in its power to isolate consumer and provider and decouple them -- more so than what would be possible if they interacted directly (somebody once said - not without irony - that "any problem can be solved by another layer of indirection" - was it an R. Johnson?). This shields a service developer from the requirements of the consumer and allows her to focus on business logic -- rather than getting multiple stakeholders to agree on the non-functional aspects of the service interface.

ESBs place service virtualization "in the middle" - the MSE that Aaron Skonnard describes places it at the endpoint. Endpoint-based virtualization is becoming a new trend. WCF does it and some other containers - to a limited degree. Some LOB packaged applications start to offer this functionality at the endpoint (e.g., Siebel with the inclusion of Fusion Middleware). This is also in support of pure SOAP architectures that describe the enterprise as just a collection of SOAP-speaking endpoints (with reliability, security, etc. all being controlled through WS* protocols).

Virtualization at the endpoint, however, is not equivalent to virtualization in the middle. It limits you to those aspects of a communication that occur -- well, at the endpoint -- just before hitting the business logic. All aspects that are more centralized conceptually, are more difficult to address. Think about location transparency, for example. If this aspect is implemented on a central, shared intermediation layer it is simple to move backend service providers to new locations. If there is no such infrastructure, then every consumer must be able to directly address the provider endpoint. Either you configure these addresses in peer-to-peer fashion (which is a mess) or you do some kind of lookup: this could be via DNS (only works with HTTP), a registry or a centralized resolver service. The two latter solutions require that the consumer endpoint (either the stack or the business logic) handles the address resolution.

Then, think about content-based routing -- and things get more difficult. This would be a functionality that the consumer endpoint would provide -- or an intermediate infrastructure service. Other examples for virtualization/intermediation requirements taht map more easily onto a (conceptuall) centralized implementation, rather than onto a set of distributed smart endpoints:

• messaging patterns (pub/sub, reliable, async) - reliable queueing can be done at the endpoint but it's a maintenance nightmare (think trapped messages, poison messages, ...)
  
• complex event processing - for correlation/pattern detection, all events must be brought together at the event correlation engine for the application of rules
  
• message routing (addressing, CBR) - as mentioned above
  
• layered security defense - combination of multiple security mechanisms where threats are filtered out at multiple policy enforcement points (PEP) along the communication path
  
• control point for runtime governance (can you really rely on your distributed containers?) - to some degree, since you can monitor messages in progress, but not the availability of services that are not in use
• Provididing multiple interfaces to different clients at different network locations - maybe you only want to make a certain "engineered" interface (different operations, different policies) available to another department, DMZ-external, etc.

The following diagram gives a conceptual idea of where intermediation/virtualization can take place when looking at the consumer-provider communication path: