SOA Management and SOA Mediation

Management is one of the more overloaded terms in SOA Governance.  SOA Management solution typically cover a wide range of capabilities, but their primary goal is to provide visibility into, and ensure the security and reliability of the services and applications deployed throughout an enterprise SOA initiative.

SOA Management systems have many core elements:

Management Application
Management application is a term taken from the WS-Distributed Management standard (see standards for more details).  It refers to a server that monitors the performance, throughput, and usage of services and applications, and consolidates this information to provide valuable services such as SLA reporting, performance charting and trend analysis, and alert and exception management.

Management Console
The management console provides an interface for monitoring the entities in both the application and infrastructure layer, it also provides the central console for policy definition, metadata management, and can deliver a comprehensive service lifecycle management solution with Policy Manager.  The management console will interact with each of the infrastructure services, ideally using the standard interfaces they define and implement (UDDI, REST, WS-Trust, XACML, and “management standards”).

Intermediaries
Intermediaries provide the connection between the applications and entities that exist at the application and messaging layer, and the services offered by the infrastructure layer.  Over time the application servers and other entities at the application and messaging layer will evolve to be able to directly use the infrastructure services, but until this time a wide range of intermediary types continue to be critical.

  • Endpoint (Agent) - An endpoint intermediary exists inside the provider application as an agent.  There are a wide range of different agent types, although they should ideally be deployed as handlers in a standard programming model like AXIS or JAXRPC for Java applications, and should use published APIs for .NET and other programming models.  The agent intermediary model offers a number of advantages, mainly last-mile security – because there is no way to physically access the service without passing through the handler, and distributed processing – there is no central bottleneck for XML and cryptographic operation, this load is delegated to the application server.  The disadvantage of the agent model is that an agent cannot practically route traffic, once the agent has received a message, it has already been routed, and it does not make sense to try to use an agent model for load-balancing or failover type scenarios.
  • Proxy- A proxy intermediary exists as a standalone entity in the network.  There are several different proxy types, some that deploy into an application server container, others that are standalone, some that provide their own hardware as a network appliance, and others that are software only.  Proxies have the advantage that they can route traffic and so can deliver load-balancing and high-availability capabilities, and can even deliver complex mediation and routing services.  Good proxy architecture provides proxies that are stateless and clustered for high-availability and load-balancing themselves.  The proxies should expose “virtual services” – see sidebar. The main disadvantage of a proxy is that it cannot ensure the security of the service to the last mile, there is no way to ensure that consumers cannot send message directly to services bypassing the proxy.
  • Delegate - The delegate is a critical component of an SOA, but is less often considered by infrastructure providers.  The delegate is a client side intermediary, most often deployed declaratively as a client-side handler, or used as a full SDK.  It abstracts the consumer developer from any direct knowledge of the location, policies, or even the messaging style requirements of the service itself.  A good delegate provides automatic runtime discovery of service location, transport and policy requirements, and ensures that any message the client sends is formatted correctly, implements the right security policies – including XML-Signature, XML-Encryption, and credential insertion, before sending the message to right location.

One set of essential “management” capabilities is mediation. There are a wide range of possible and useful mediations including:

  • Multi-pattern mediation (agent, delegate, proxy, relay, gateway, router, switch, pipe & filter, Policy Enforcement Point)
  • Messaging mediation (programming model and synchronicity) - useful when consumers and providers use differing call models. Three types of MEP mediation are configurable; Sync-Async mediation (synchronous consumer wants to access asynchronous WS providers); Async-Sync mediation (asynchronous consumer wants to access synchronous WS providers); Aynch-Async mediation (asynchronous consumer wants to access asynchronous WS providers)
  • Reliability mediation – useful when unreliable consumers need to consume reliable services, or when reliable consumers need to consume unreliable services.
  • Standards mediation - useful when the consumers use and the providers expect differing WS standards. We handle this mismatch through design time configuration. Several types of syntactic standards mediation are supported: WS-Security, WS-Addressing, WS-Routing, and WS-Reliable Messaging.
  • Transport mediation - useful when consumers and providers use differing transport protocols. Common examples of this are SOAP/HTTP consumers who want to call non-soap message driven apps such as POX/JMS
  • Asynchronous delivery – required for synchronicity mediation
  • Guaranteed delivery – required for reliability mediation

SOA Software’s Service Manager is a comprehensive SOA Management solution with extensive mediatioin capabilities.  Service Manager can mediate between a wide range of standards, message styles (SOAP, POX, etc), MEPs (REST, SOAP, MOM, etc), transports (http, https, JMS), reliablity models (WS-RM, WS-RX, MOM, etc), security tokens (SAML, Kerberos, X.509, session cookies, etc).

Mediation is enabled declaratively through the standalone intermediary based on impedances between inbound messages and the requirements, capabilities, and policies of the destination service.