SOA Federation Scenarios

SOA Federation solutions can be applied to a wide range of problems.  For the purposes of this discussion we have chosen three common scenarios where SOA Federation solutions can offer particular value.

Common Services
One of the goals of most enterprise SOA programs is to identify and deliver a set of common services that can be leveraged throughout the extended enterprise by different applications, technologies, and teams. 

Services that are intended to be shared widely throughout the enterprise must comply with a defined set of constraints:

  • They must be broadly relevant
  • They must be consumable across a wide range of platforms
  • They must enforce and comply with consistent enterprise policies
  • They must be discoverable and visible across all applicable platforms, organizations, and teams
  • They must offer a mechanism to give consumers confidence that the service will deliver appropriate service levels

Ensuring that common services comply with these constraints is most often the job of an enterprise SOA CoE.  It can, however, fall to individual service owners (i.e. the teams that create services) to find a way to expose their services to other parts of the company in such a way that they meet these requirements. 

To ensure the relevance of common services, the SOA Federation solution should allow service owners to propose their services as candidate common services, and provide a lightweight approvals process for administrators (CoE staff for example) to accept or reject the services.  Depending on how much governance and governance automation is needed in this process, the SOA Federation solution could provide a comprehensive compliance policy validation framework to verify that service interfaces comply with enterprise, industry, and regulatory guidelines and requirements.

As the complexity of service interfaces grow to provide enhanced security and reliability capabilities, the set of consumers capable of consuming the services shrinks.  To make common services consumable across a wide range of platforms, the SOA Federation solution should provide a virtualization mechanism with strong mediation capabilities.  It should define and deploy virtual service endpoints that abstract service consumers from the implementation specifics of the actual service.  To achieve this, the SOA Federation solution must provide tolerance to ensure that the widest possible set of consumers can consume a service by making sure that the service is tolerant of different message types, policies, transport, and many other variables.

To ensure that common services comply with consistent enterprise policies, the SOA Federation solution needs to provide a uniform policy enforcement model, allowing for consistent, standard-based policy definition.  The solution should be able to integrate with existing policy systems, and should be able to audit when policies are enforced.

To make common services discoverable and visible across all applicable platforms, organizations, and teams, the SOA Federation solution needs to provide a catalog of common services.  This catalog should include all the information needed to consume the service, including interface definition, endpoint location, and policy information.  This catalog should be accessible using standards like UDDI and WS-MetadataExchange to facilitate broad access.

In order to give consumers the confidence that common services will meet service level requirements for performance and availability, the SOA Federation solution needs to offer a consumer contract provisioning capability.  This capability will provide a mechanism for consumers to request access with specific service level commitments, allowing administrators and service owners to negotiate, approve or reject the request.  The contracts also provide administrators and service owners with the data they need to effectively plan capacity for the common services.

Enterprise SaaS
Enterprise Software-as-a-Service (SaaS) solutions are becoming more and more widely adopted.  These solutions often offer Web services for easy integration with internal enterprise applications, however, it may not always be easy (or appropriate) for an application to consume these services.  The role of the SOA Federation solution is very similar to the role discussed above under common services, although the enterprise SaaS use case does differ in some important areas.

 

The core concerns are largely the same.  The SOA Federation solution needs to ensure that SaaS services look and behave the same as if they were any other common service.

  • They must be consumable across a wide range of platforms
  • They must enforce and comply with consistent enterprise policies
  • They must offer a mechanism to give consumers confidence that the service will deliver appropriate service levels

Where differences emerge is in the broad applicability (or not) of the SaaS services.  In this way the requirements for broad relevance and discoverability change subtly:

  • SaaS Services must be relevant to a governed set of internal applications – the SOA Federation solution will still need to provide a lightweight approval process, but in this case it is likely that the request for virtualization of a SaaS service will come from a potential consumer of that service.
  • They must be discoverable and visible across all applicable platforms, organizations, and teams – the SOA Federation solution should only make SaaS services visible to carefully chosen parts of the enterprise, and should leverage the consumer contract provisioning process to govern which applications are allowed to access these services.

ESB Federation
Most large enterprises either have, or will have multiple different ESBs from multiple vendors.  In many cases these ESBs will be used as local integration servers to build applications, often exposing these applications as services. 

 

The challenge comes when a team in another part of the extended enterprise wants to consume the service exposed by the localized ESB instance.  There are likely to be considerable impedances between the consumer application and the provider:

  • The service may require authentication from a domain to which the consumer does not belong and does not have access
  • The consumer may want guaranteed service levels
  • The consumer and provider may be technically incompatible
  • The consumer may not have physical access to the service (e.g. the service may reside on a local piece of message-oriented middleware)


In these cases, the service provider will need to find a way to expose their services as Governed endpoints.  This is similar to the common services use-case described above, but rather than relying on a central facility that may have its own constraints (see above), the service provider will run their own SOA Federation solution to virtualize their services to ensure:

  • They must be broadly relevant
  • They must be consumable across a wide range of platforms
  • They must enforce and comply with consistent enterprise policies
  • They must be discoverable and visible across all applicable platforms, organizations, and teams
  • They must offer a mechanism to give consumers confidence that the service will deliver appropriate service levels

The reverse is equally true.  There will be cases where an ESB needs to consume a service from outside its local domain.  In this case it needs to comply with the constraints imposed by the 3rd party service, including a wide set of likely technology constraints.