SOA Federation Use Cases

SOA Federation solutions are sometimes called shared-services solutions, or SOA infrastructure.  It is important to note that SOA Infrastructure is very different from SOI (or service-oriented infrastructure).  SOI provides common IT infrastructure services (single-sign-on, user self service, etc) in a service oriented way.  SOA Infrastructure ensures that services in the context of SOA are relevant, consumable, policy compliant, and aligned with demand from the enterprise.

SOA Federation is a subset of a comprehensive SOA Infrastructure solution.  To understand the function of an SOA Federation solution in the context of the scenarios described earlier we will examine a few common use-cases:

Publish services for sharing
One of the most basic use-cases for an SOA Federation solution is the ability for a service creator to request the publication of their service into the Federation solution where it can be discovered and consumed by interested parties.

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.

Consume Shared Services
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.

Consume External Services
Another common use-case is the need for internal applications to consume external services.  The architect or developer of an external application might find the WSDL of an external service via Internet search or a simple referral.  In most instances, the organization won’t want, or allow, internal applications to directly consume external services.  They won’t have any way to monitor the performance and availability of the service, or to control which internal applications are consuming these external services.

The SOA Federation solution allows the architect or developer of the internal application to request the virtualization of an external service by submitting its WSDL.  The SOA Federation solution administrator can then approve or reject the request and generate a virtual instance of the service with its own WSDL and with endpoints inside the corporate network.  The virtual service can then monitor the service for service levels, authenticate and authorize the requests from the internal application(s) and implement any policies required by the external service.

Platform Tolerance
In many cases it application architects or developers may wish to access a service that their application’s platform isn’t capable of consuming.  There are many potential types of impedance between consumers and services including but not limited to:

• Different versions or implementations of standards
• Different transports
• Different message exchange patterns
• Different synchronicity models
• Different security policy requirements
• Different reliability models

One of the most important roles of an SOA Federation solution is to use service virtualization to mediate between these impedances to provide a highly tolerant and interoperable environment.  Tolerance can be seen as the opposite side of the governance coin, but in reality governance and tolerance go together, the goal should be to ensure that services are adequately governed while remaining tolerant of impedances.