An introduction to IBM Service Federation Management (SFM), Part 3: Sharing services between two service domains using the SFM console

The Service Federation Management (SFM) feature pack enables enterprises to expand their SOA capabilities by federating and sharing services across domains. This article 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.

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.



Martin Holder (mholder@uk.ibm.com), Cast Iron Developer, IBM

Martin HolderMartin Holder is software engineer at IBM Hursley Laboratories. He worked on the initial release of SFM and is currently working on WebSphere Cast Iron. Martin has previously worked on WebSphere Message Broker and WebSphere Enterprise Service Bus.



06 December 2010

Introduction

The release "WSRR v7 Feature Pack for Service Federation Management" (SFM) aims to simplify the process of reusing business services across multiple and heterogeneous service domains. The SFM console provides a web browser GUI, running in Business Space which allows the user to specify their service sharing "intent", and will make use of the Service Connectivity Management Protocol (implemented in v7 WebSphere® Service Registry and Repository, WebSphere® Enterprise Service Bus and WebSphere® Message Broker) to drive the copying of service metadata and the creation of service proxies in the underlying products. The business value lies in avoiding the complexity associated with doing this manually.

The Service Connectivity Management Protocol (SCMP) provides a way of defining the connectivity concepts which are relevant to federation. For steps on how to SCMP enable products either see their relevant information center or in Part 1 of this article series.

This article will detail the steps for using the SFM console for connecting to SCMP servers, sharing groups of services between them and creating proxies of those services. This article assumes that the SFM console has already been installed and that required products have been SCMP enabled.

By the end of this article the user will be able to use the SFM console to:

  • Connect to SCMP enabled servers.
  • Model a system as a collection of federated domains.
  • Discover and group services on these domains.
  • Share and proxy groups of services between the federated domains.

This article will run through some examples showing some golden paths of how to share services. It will include information about secure systems; however it will not go into any details about governance at this point.


Accessing the SCMP enabled servers

In order to manage and work with SCMP enabled products, the SFM console needs to be directed to them, and will need to be able to read them. The concept of service documents is used for this. Each SCMP enabled product will supply a service document which allows SFM to expose relevant artifacts to be managed.

Configuring security via the SFM console

If the SCMP systems are secured, then in order for the SFM console to be able to access the service document for that system, security settings will need to be configured.

In order to use SFM securely, the various products involved will need to be configured to trust each other. Typically that will be done via a combination of SSL and basic authentication. For example the WAS running the SFM coordinator will need to have exchanged SSL certificates with the WebSphere Message Broker or the WebSphere Enterprise Service Bus if those products are being used as connectivity providers.

In the case of basic authentication, the SFM console will be used to create authentication aliases and to map these to specific systems which they are to be used with. The steps for doing this are as follows:

  1. Log onto the SFM console on business space (e.g http://host:9080/mum/enabler) then select the space containing the SFM console.
  2. Navigate to the Administration tab, then to the Authentication Aliases sub-tab.
  3. Click the 'Create Authentication Alias' button.
    1. Fill out the details in the dialog box (see Figure 1), giving the authentication alias name which will identify it later.
    2. Create the alias by clicking 'Create Authentication Alias'.
Figure 1. Authentication alias dialog box
Authentication alias dialog box
  1. In order specify which alias applies to which SCMP enabled system, create an Authentication Alias Mapping. This mapping will match an authentication alias to one or more servers which match the pattern specified.
    1. Click 'Create Authentication Alias Mapping'
    2. Fill in the relevant fields (see Figure 2), for example, in order to match an authentication alias myAlias to the servers are myHost1.example.com and myHost2.example.com, using the wild cards * or ? for the host name. (Note: Wild cards can only be used for the host name field).
      • Host name: myHost*
      • Domain name: example.com
      • Authentication alias: myAlias
    3. Click 'Create Authentication Alias Mapping' to create the mapping.
Figure 2. Authentication alias mapping dialog box
Authentication alias mapping dialog box

Adding the service documents

A service document will need to be added in the SFM console for each SCMP enabled system that SFM is going work with. These service documents will take following forms:

For example:

To add a service document to the SFM console, use the following steps:

  1. In the SFM console navigate to the Administration tab, then to the Service Document URLs tab.
  2. Click the 'Add Service Document URL' button.
  3. In the dialog box that appears (see Figure 3), add the URL of the service document required (see above for details about the format), and then click the 'Add Service Document URL'.
Figure 3. Adding a service document
Adding a service document
  1. If the service document has been successfully read, the Server Type should be displayed in the server type column (See Figure 4).
Figure 4. A successfully added service document
A successfully added service document
  1. Repeat steps 2 - 4 for each system being used.

Domains

A service domain represents a logical functional area of an enterprise, in which service metadata is stored and looked up in a single registry. A domain may make use of some form of ESB to provide the connectivity backbone for the services. This will be referred to as a connectivity provider. A domain representing a service domain can be modeled using the SFM console. This domain must contain one unique registry and may contain 0 or more connectivity providers.

Examples of this could be an enterprise which has departments including a warehouse and a retail department. Each of these departments might have their own services which are being stored in their own registries. If the enterprise decided that they wished to be able to make use of services that the other department has, then they could use SFM to share these services.

Another example of different domains in an organization might be when two companies merge. Each company would have their own services located in their own registries, and when they have merged they would require a way of accessing certain services that are being run.

Creating a domain

To create a domain in the SFM console complete the following steps:

  1. Navigate to the 'Domain Management' tab.
  2. Click the 'Create Domain' button.
  3. Fill in the details of the form, e.g. select a domain server (while it is not essential, it is good practice to select the domain server which is running on the same WSRR instance as the registry that will be used in creating this domain), give the domain a unique name (in this example call it 'Warehouse' and select the Service Registry to be used in this domain.
  4. Click 'Finish' to create the domain (See Figure 5 for a completed domain).
Figure 5. The details of a domain
The details of a domain
  1. Now the domain has been created. At this point this domain can only be used to share services exactly as they are. In order to create any kind of proxies of this service (i.e. to enforce HTTPS) a connectivity provider will need to be added. To do this, click the 'Add Connectivity Provider' button (See Figure 6).
Figure 6. Adding a connectivity provider
Adding a connectivity provider
  1. Click the '...' button to browse for an available connectivity provider (See Figure 7).
Figure 7. Click to browse for a connectivity provider
Click to browse for a connectivity provider
  1. Browse for the connectivity provider which will represent the connectivity provider you wish to use (See Figure 8).
Figure 8. Selecting a new connectivity provider
Selecting a new connectivity provider
  1. Click 'Finish' to add the connectivity provider to this domain.
  2. If more connectivity providers are required for this domain, repeat steps 5-7.
  3. Repeat these steps to create a second domain called 'Retail'.

Service Groups

Instead of dealing with individual services when performing shares, SFM deals in groups of services. This allows the user to share large numbers of services between domains with ease. Each domain may contain a number of service groups. As well containing a list of service endpoints, service groups have various properties associated with them including whether or not they can be shared with other domains, or whether they are supposed to be called directly by a consumer or not.

To create a service group in the SFM console, complete the following steps:

  1. Navigate to the Domain management tab.
  2. Using the View Domain drop down list, select the domain the new service group will be created in, in this example select 'Warehouse' (See Figure 9).
Figure 9. Viewing a domains details
Viewing a domains details
  1. On the Service Groups tab, click the 'Create Service Group' button.
  2. In the 'Create Service Group' dialog box (See Figure 10), fill in the details about the new service group i.e.:
    • Service Group Name : warehouseServices
    • Visibility : Public
    • Shareability: Shareable

In order to share this group with another domain, the Shareability value must be set to 'Shareable'.

Figure 10. Create service group dialog
Create service group dialog
  1. Click 'Create Service Group'
  2. The details of this service group can be seen on the right hand side of the screen. In order to add service end points to this service group, click the 'Add Service Endpoints' button (See Figure 11).
Figure 11. Adding service endpoints
Adding service endpoints
  1. As mentioned previously, each domain has an associated registry. The endpoints from this registry will be read and displayed in a list of available endpoints. To add endpoints to this service group, select the ones required and click the Add Selected button (See Figure 12).
Figure 12. Adding the selected endpoints
Adding the selected endpoints

A service group, containing a group of endpoints, has now been created and is ready to be shared.


Creating a federation

A federation is a collection of domains which wish to reuse each others services. A federation is a discrete unit; all sharing activities will take place within this unit. While each SCMP enabled WSRR can act as a federation server to host federations, only one federation (and therefore one federation server) is required to perform SFM activities. A federation consists of a number of domains. Each of these domains can only belong to one federation.

Creating a federation

  1. Select the 'Federation Management' tab.
  2. Click the 'Create Federation' button.
  3. Fill in the details of the federation (See Figure 13), including:
    • The federation server via the federation server dropdown.
    • The federation name. In this example, name the federation 'federation1'. Try to make this name unique if there are going to be multiple federations.
  4. Click the 'Finish' button.
Figure 13. Creating a federation
Creating a federation

Adding domains to a federation

Before a federation can be used, domains need to be added to this federation. As mentioned earlier, domains can only be federated to one federation. Follow these steps to add domains to a federation.

  1. Select the 'Federation Management' tab.
  2. Select the federation in question. In this example select 'federation1'.
  3. Click the 'Add domain' button (See Figure 14).
Figure 14. Add domain button
Add domain button
  1. Select the domains to be added to this federation (See Figure 15). In this example select 'Warehouse' and 'Retail'.
Figure 15. Add domain dialog box
Add domain dialog box
  1. Click the 'Add domain' button.
  2. The domains should now be visible in the view below (See Figure 16).
Figure 16. A federation containing 2 domains
A federation containing 2 domains

Sharing services

SFM enables a user to share groups of services between a provider and a consumer domain. These services can be exposed directly as they are or via proxies (e.g. forcing them to be called via HTTPS).

Sharing services

A consumer in one domain may not be able to access the registry located in another domain, as a result that consumer would be unable to look up service endpoints stored in that registry. When sharing services between the provider and the consumer domains, the metadata exposing the endpoints which are being shared will be made available in the consumer domains registry. As a result a consumer can now look up and call these endpoints.

Proxing service groups

It is likely that one of the domains will not wish to expose their service endpoints directly and instead will wish to create a proxy of them which will be used instead. One example of this would be to enforce security. A proxy can be created on either the provider or consumer domain, or both. In order to create a proxy, the domain must contain a connectivity provider which will support the required proxy capabilities. The endpoints for these proxies will also get stored in the relevant registries.

Note: When creating a share, it will be possible to see a message saying that the domain does not contain a connectivity provider which matches the required capabilities. The reason for this is that different connectivity providers offer different capabilities.

Sharing a service group

Follow these steps to share and create a proxy for a service group between two domains:

  1. Select the 'Federation Management' tab.
  2. Click on the domain which will act as the provider. This domain will need to have at least one service group in a shareable state. In this example this will be 'Warehouse'.
  3. A blue circle will appear at the bottom of the domain icon. Click and drag the mouse from this circle to the consumer domain (in this case 'Retail'). This will draw an arrow. Drop the arrow over the consumer domain. (See Figure 17)
Figure 17. Dragging an arrow between 2 domains
Dragging an arrow between 2 domains
  1. In the right hand side of the screen a panel named Share details will be displayed.
  2. Use the provider service group drop down box to select the service group that will be shared (See Figure 18). This list will only contain service groups in the provider domain which are in the shareable state. In this example select the group named 'warehouseServices'.
Figure 18. Selecting the group to share
Selecting the group to share
  1. Click the Share Service Group button. This will display a section titled New Share Details in which the new share may be customized.
  2. This example will create a proxy for the service group on the provider domain which enforces the use of HTTPS. To do this select the 'Always use HTTPS' check box. Note that the value of the 'Proxy Positions' drop down has now been updated to say 'Provider only', this has also been updated in the Share Path section below which offers a visual representation of the structure of the share (See Figure 19).
Figure 19. Updated share path
Updated share path
  1. To create the share, click the 'Finish' button.
  2. Once the progress summary has indicated that this has been successfully completed, it’s possible to see the new groups that have been created. To do this, select the consumer domain (Retail) and click on the Service Groups tab, this will display the new service group that has been created in this domain. This will be named warehouseServices @ Warehouse (See Figure 20).
Figure 20. New group created in Retail domain
New group created in Retail domain
  1. To manage this share to perform functions like deleting it, viewing proxy information (more details of share management can be found in the Information center), select the arrow again and then select the share from the list of shares on the Share Details panel.

At this point the group of services will be available in the consumer domain. Any consumers running in that domain that wish to access these services can now look them up via the registry in this domain.


Summary

This concludes an example of using SFM to share a group of services between a provider and consumer domain. As mentioned earlier, the reader will now be familiar with how to:

  • Connect to SCMP enabled servers.
  • Model a system as a collection of federated domains.
  • Discover and group services on these domains.
  • Share and proxy groups of services between the federated domains.

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=593901
ArticleTitle=An introduction to IBM Service Federation Management (SFM), Part 3: Sharing services between two service domains using the SFM console
publish-date=12062010