As SOA is becoming widely adopted in business, the maturity levels which people are operating at is rising. As is standard for SOA, services are set up and made available through an enterprise service bus (ESB) for applications to use these services. In order to allow providers to advertise services and for consumer to look up services, registries are used to store information about the services.
It is often be the case that businesses are composed of a number of business units, each of which have a registry and services that are isolated from the other units. These are known as service domains. While each service domain is operating as a SOA, they won’t be sharing service between each other. This can be seen as “islands of SOA” within the enterprise. Service domains are also often implemented in a variety of technologies from different vendors.
There are a number of reasons an enterprise may end up with multiple service domains which have adopted SOA technologies, but are not sharing services with each other:
- Historically, each domain may have started SOA adoption with an isolated proof of technology experiment.
- Through mergers and acquisitions. When two companies merge, their individual SOA environments will have to co-exist, at least to start with, while capitalizing on the merger will require sharing of some of the services between them.
- To allow a business unit to have more control and move faster then a single enterprise SOA domain allows.
Service reuse is a core part of SOA. Service reuse allows enterprises to be able to respond quicker to changing business needs. Advantages of service reuse are that less code has to be written (resulting in faster turnaround), it can be maintained in one place and everyone has access to the same service and same shared information. Sharing services between domains and allowing that service reuse across a whole enterprise is a key part of that value proposition.
The following cases studies illustrate this.
Case study 1
A company is currently using an ESB and registry at the enterprise level for controlling services which are used by many departments. Some of the departments find that because of this enterprise control they are unable to act very quickly in bringing new services on line or making updates to their services, especially ones which are only used within their division. They decided that if they were to have their own local services in a local ESB and registry they would be able to act with greater speed. To compliment this they also decided to use SFM to share the services which were relevant to the rest of the organization with the main enterprise registry and domain.
Case study 2
A company is split up into a number of different departments. Each of these departments faces a different set of challenges and as a result has adopted different technologies to use. Each of these different departments has begun to run internal projects experimenting with adopting SOA. Having found that they are starting to see the benefits of using SOA on a department level, the company has decided that they want to roll out the use of SOA across the whole enterprise. The enterprise decided to adopt SFM to share services between the different departments to scale up their use of SOA across the whole company.
What is Service Federation Management?
Up until now there have been no specific products or product features to help with sharing of services between service domains. The WebSphere Service Registry and Repository V7.0 feature pack for Service Federation Management (SFM) addresses this by providing the tools for sharing information about services between service domains and to set up the connectivity required to make those services useable between domains.
SFM includes a console to graphically view a federation of service domains, and to define the way in which services are shared between them using simple drag and drop. SFM also supports automatic creation of proxies for services on ESBs in each service domain.
SFM does not attempt to connect the infrastructure (the registries and ESBs) in the various service domains directly, as this creates a very tight coupling and is almost impossible where different technologies are used in each domain. Instead, SFM copies information about the services between the registries of each service domain to make the information about a provider service visible to a consumer in another domain. This maintains a loose coupling between the domains, and simplifies problems with security, heterogeneity and governance when accessing that information.
Sharing a service
When sharing a service from one service domain to another, the simplest scenario is just to make the service visible in the second domain. This is illustrated in Figure 1, which shows the service reference for the service in the provider domain being copied to the consumer domain: the consumer can now find the service in its local registry and call it.
Figure 1. Sharing a service with no proxies
A more common deployment pattern however, is that when a service is shared from one domain to another, it will be necessary to place a proxy in one domain or the other, or commonly in both, (as illustrated in Figure 2) to enforce one or more policies, such as security policies or service level management.
Figure 2. Sharing a service with a proxy on the consumer and the provider domains
SFM hides much of the complexity of this from the user. The user can specify the qualities of services required when a service is shared from one domain to another and SFM will select where proxies need to be placed in order to meet this, and create these automatically when a share is created. Figure 3 shows a screenshot from the SFM console, showing the sorts of qualities of service available and how they are selected. In this example a proxy which will enforce security and perform message validation will be created on the provider domain.
Figure 3. A share path creating a proxy on a the provider domain
Aspects of connectivity
When considering any type of connectivity there are a number of aspects that should be considered, and when looking at making connections between different domains these take on even more importance. These can be broken down into four aspects of connectivity: service visibility, service management, service security and service governance.
- Service visibility. The ability for a provider to advertise that a service is available, and for a consumer to look up this service and call it. Essentially allowing a consumer to be able to “see” a provider’s service. This is usually provided by a combination of service registry and service bus.
- Service management. This enables understanding of and sometimes dynamic adaptation to changing service conditions. An example of this might be checking to see if a service is getting a higher number of requests than expected, and then taking some action based on this information.
- Service security. The act of making sure that a service can be accessed over a secure connection by a consumer with the correct user ID. Also when looking at calling services in different domains, considerations need to be made for issues like identity mapping between an id which makes sense in one domain, to an id which makes sense in the other domain.
- Service governance. In the context of federation, governance is about managing the contracts between service domains and the dependencies between service consumers and providers. It is important for a domain to be able to make sure that if it is relying on a service in another domain, this service is not just going to be removed with out warning, and instead this service should be governed in the correct life cycle.
Concepts and terminology
There are a number of different concepts that Service Federation Management introduces. Some of the key terminology is as follows:
- Service Domain. A service domain is a single well-bounded section of the overall enterprise, sometimes referred to as a business unit. Often traditional SOA practice works within a single service domain. SFM provides the capability to easily share services between these service domains. In the context of SFM, a service domain will contain one registry and may contain zero or more ESBs or connectivity providers.
- Federation. Within SFM, a federation is a collection of service domains. Services can be shared between service domains within the same federation. While it is possible to have multiple federations, it is best to think of an enterprise as being a single federation, made up of a number of separate business units, known as domains.
- Service Group. An enterprise will likely have a very large number of services. Many of these services will be related in some way. Within SFM, the user can place related services into service groups. This allows these related services to be shared as one entity, rather than having to work at the level of individual services. As a result it's just as easy for SFM to share one service as it is to share 10 or 50 services.
- Proxy. A proxy provides a new interface to the service. The proxy then forwards the request onto the actual service. Proxies are created by SFM, when requested by the user, in the service consumer domain, the service provider domain, or both. The proxies can provide additional functionality, such as enforcing HTTPS.
- Service Connectivity Management Protocol (SCMP). SCMP is a protocol which facilitates the sharing of services between domains. SCMP enabled products are used by SFM to provide the required function, while hiding this complexity from the user.
There are various tasks that are associated with federating services between domains. These tasks would most likely be performed by a number of different people with different roles. It is possible for a single individual to perform all of the steps. However, it is important to understand that these different roles exist, so they are described below.
- Domain Administrator. It would be the domain administrator's responsibility to create and configure the domain they are responsible for in the SFM console. Each domain would have its own domain administrator.
- Federation Administrator. The federation administrator would create the federation, add the chosen domains to that federation, be responsible for the federation going forward, and share services between domains. The federation administrator would likely have their own install of the SFM console through which they work.
- System Administrator. The system administrator would be responsible for the install of the base products. This might include WebSphere Service Registry and Repository, WebSphere Enterprise Service Bus or WebSphere Message Broker. It would also cover the steps of creating profiles, message queues, message brokers, as well as the SCMP enablement of these products. Additionally, it would include the install and configuring of Business Space, and the SFM console.
- "Configuring products involved in a Service Domain for IBM Service Federation Management, Part 2: Configuring IBM Service Connectivity Management Protocol on products involved" (developerWorks, Apr 2010) describes how to enable IBM WebSphere Service Registry and Repository, IBM WebSphere Enterprise Service Bus and IBM WebSphere Message Broker V7 products to manage and federate those services.
- "Using the IBM Service Federation Management (SFM) console to share services, Part 3: Sharing services between two service domains using the SFM console" (developerWorks, Dec 2010) describes how to use the SFM console to perform some of the core functions that are available, for example sharing a group of services between two service domains.
- The WebSphere Service Registry and Repository V7.0 feature pack for Service Federation Management download site.
- The SFM Information Center, contains information about the installation and use of SFM.
- Read the IBM Redpaper "Exploiting IBM WebSphere Service Registry and Repository Feature Pack for Service Federation Management to Share Services Between Two Domains".
- Read the IBM Redpaper "Using IBM WebSphere Service Registry and Repository Feature Pack for Service Federation Management to Share Services from an SAP Domain".