SOA Federation ScenariosClick here to view a print-ready version of this pageSOA 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
Services that are intended to be shared widely throughout the enterprise must comply with a defined set of constraints:
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
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.
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:
ESB Federation
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:
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:
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.
|
