An introduction to IBM Service Federation Management (SFM), Part 1: An overview of the concepts involved in the IBM Service Federation Management feature pack

Service Federation Management (SFM) feature pack enables enterprises to expand their SOA capabilities by federating and sharing services across domains. This article examines the motivation and business case for SFM, and introduces some of the concepts and terminology that are involved.

Share:

Jonathan Roberts (jonrober@uk.ibm.com), Service Federation Management Developer, IBM

Jonathan RobertsJonathan Roberts is a software engineer at IBM Hursley Laboratories. He has spent the last two years working on the Service Federation Management project. He has also worked on a number of WebSphere products, including working WebSphere Enterprise Service Bus and WebSphere Service Registry and Repository.



Nick Butler (nickb@uk.ibm.com), STSM, Service Federation Management, IBM

Nick ButlerNick is the architect for Service Federation Management. Nick started at IBM in 1982 and has had a varied career. He began as a hardware engineer, spending the first 9 years designing graphics display adapters, including the XGA. Moving to software, he then spent eight years working with telephony and voice response systems, a lead architect for DirectTalk/6000 voice response system. Following that he has had varied roles in business integration software, as an architect for autonomic computing initiatives, and architect for the connectivity aspects of WebSphere sMash, before starting the Service Federation Management project two years ago.



David Bell (david.bell@uk.ibm.com), WSRR - Integration Test Technical Lead, IBM

David Bell David Bell is the Integration Test Technical Lead for WebSphere Service Registry and Repository. He has 4 years of experience in SOA, primarily focused on WebSphere Service Registry and Repository. Prior to that experience, he spent 5 years working in the Java Technology Center. He has a First Class Honours Degree in Computer Science from the University of Nottingham. David is also an IBM Senior Inventor, a distinction that recognizes his contributions to invention within IBM.



03 December 2010

Background

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
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
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
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.

Roles

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=593606
ArticleTitle=An introduction to IBM Service Federation Management (SFM), Part 1: An overview of the concepts involved in the IBM Service Federation Management feature pack
publish-date=12032010