SOA Federation Solutions

The SOA Federation solution offers a particular set of capabilities delivered by a combination of an SOA Intermediary, an SOA Registry/Repository, an SOA Policy Management System, and an SOA Management system.

The SOA Federation solution can be deployed independently of, or integrated with any other SOA platform or Governance solution to provide a convenient service virtualization, mediation, publication and discovery automation solution.

Service Virtualization

Service Virtualization is the creation and hosting of a new service, exposed through an SOA Intermediary.  This service has its own WSDL, interfaces, endpoints and policies, but rather than executing its own business logic, it invokes another service (the virtualized service).  In many ways a virtual service is a proxy for a physical service, but with a wide range of routing, mediation, security, and other governance capabilities added.

An effective SOA Federation solution should offer a simple virtualization allowing users to rapidly create and host virtual services without having to write code, or create process descriptions.  The virtual service should implement its own policies and be able to declaratively mediate between inbound messages, and the requirements of the virtualized physical service. 

The capabilities of virtual service include:

  • Policy enforcement – the virtual service should have its own policy set defining security, monitoring, reliability, and other requirements.  These policies should be enforced by the SOA Intermediary hosting the virtual service.
  • Tolerance/mediation – one of the core goals of virtualizing services is to remove impedances between services and consumers.  These impedances can be introduced by different platform versions, network topologies, policy configurations, message styles, and a whole host of other factors.  Tolerance and mediation are discussed in more detail in the next section of this document.
  • Aggregation – virtual services can contain multiple operations taken from more than one back end service that may be deployed on multiple platforms with different policies, message styles, transports, etc.  Alternatively, a virtual service could contain a subset of the operations offered by a physical service.  Virtual services have their own WSDL and endpoints, so they provide an ideal way to hide the physical infrastructure from potential consumers.
  • Change management/abstraction – virtual services provide abstraction against change for consumers.  The service provider can change the underlying physical service in a wide range of ways from something simple like adding a new endpoint on another server for load-balancing to moving the service to a new platform or even upgrading the service to a new version.  The virtual service will automatically route requests to the appropriate endpoint based on policy, and can even perform transformations to model an older version of a service as needed by consumers.
  • Capacity planning/management/monitoring – virtual services make it easy for administrators to see how service performance is changing over time to understand that they need to provision a new endpoint, or decommission an endpoint as needed.  Because the virtual service provides a stable endpoint, consumers will not be affected with the SOA intermediaries performing dynamic load-balancing in the background.

Trust and Management Mediation

One of an SOA Federation solution’s core strengths is its mediation capabilities.  It should offer a range of 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. There are three types of message exchange pattern mediation; Sync-Async mediation (synchronous consumer wants to access asynchronous WS providers); Async-Sync mediation (asynchronous consumer wants to access synchronous WS providers); Asynch-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. The SOA Federation solution handles this mismatch through declarative configuration. Several types of syntactic standards mediation are available: 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

The SOA Federation solution should be able to mediate between a wide range of standards, message styles (SOAP, POX, etc), MEPs (REST, SOAP, MOM, etc), transports (http, https, JMS), reliability models (WS-RM, WS-RX, MOM, etc), security tokens (SAML, Kerberos, X.509, session cookies, etc).  Mediation should be enabled declaratively through the standalone intermediary based on impedances between inbound messages and the requirements, capabilities, and policies of the destination service.

Publication and Discovery Automation

One of things that is often overlooked, but is most valuable, about an SOA Federation solution is the capabilities around publication and discovery automation.  The SOA Federation solution includes a registry/repository with built-in workflow processes to govern the ability of service owners to publish and virtualize their services, and potential consumers to request contracts for those services.

The SOA Federation solution should facilitate this process by providing both standards (UDDI Publish API) and UI/Wizard based mechanisms service owners can use to publish and virtualize their services into the SOA Federation solution.  Of course, this is not enough.  The publish operation should typically not actually result in the service being generally available, but rather should result in a request to the SOA Federation system administrators to approve the publication.  Once the request is approved, a virtual instance of the service should be visible to potential consumer who can then request access to it via a consumer contract provision process (see below).

Optionally, the request approval process could be part of a broader SDLC governance process, and could be subject to compliance policy validation.  These capabilities are more normally considered to part of a comprehensive enterprise SOA Governance solution, and should be available as an upgrade to the SOA Federation solution.

Of course, once services are published and available in a standardized way, consumers need to be able to find them, request access to them, and consume them with confidence that the services will meet their requirements.

The SOA Federation solution should provide a standards-based registry allowing application architects and developers to search and browse for services.  Once they find a suitable service (suitability being determined by a wide range of factors from description, interfaces, schemas, service metadata, attached documents, policies, published service levels, and even actual real-time and historic performance and availability data) they should be able to request access to the service with specific service levels.  This access request should be subject to a simple negotiation and approval process resulting in a defined, agreed contract between the consumer and the provider.