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.

Back to top

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

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

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:

• WSRR: http://<hostName>:<port>/ServiceRegistryFeeds/servicedocument
• WESB: http://<hostName>:<port>/rest/scmp/servicedocument
• WMB: http://<hostName>:<port>/scmp/servicedocument

For example:

• http://myWSRRHost:9080/ServiceRegistryFeeds/servicedocument
• https://mySecureWESBHost:9443/rest/scmp/servicedocument
• http://myWMBHost:8085/scmp/servicedocument

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

4. If the service document has been successfully read, the Server Type should be displayed in the server type column (See Figure 4).

5. Repeat steps 2 - 4 for each system being used.

Back to top

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

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

6. Click the '...' button to browse for an available connectivity provider (See Figure 7).

7. Browse for the connectivity provider which will represent the connectivity provider you wish to use (See Figure 8).

8. Click 'Finish' to add the connectivity provider to this domain.
9. If more connectivity providers are required for this domain, repeat steps 5-7.
10. 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).

3. On the Service Groups tab, click the 'Create Service Group' button.
4. 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'.

5. Click 'Create Service Group'
6. 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).

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

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

Back to top

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.

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

4. Select the domains to be added to this federation (See Figure 15). In this example select 'Warehouse' and 'Retail'.

5. Click the 'Add domain' button.
6. The domains should now be visible in the view below (See Figure 16).

Back to top

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)

4. In the right hand side of the screen a panel named Share details will be displayed.
5. 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'.

6. Click the Share Service Group button. This will display a section titled New Share Details in which the new share may be customized.
7. 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).

8. To create the share, click the 'Finish' button.
9. 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).

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

Back to top

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

• "An introduction to IBM Service Federation Management, Part 1: An overview of the concepts involved in the IBM Service Federation Management feature pack" (developerWorks, Dec 2010) examines the motivation and business case for SFM, and introduces some of the concepts and terminology that are involved.
  
  
• "Configuring products involved in a Service Domain for IBM Service Federation Management, Part 2: Configuring IBM Service Connectivity Management Protocol on products involved" (developerWorks, Dec 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.
  
  
• 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".
  
  

About the authors

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

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Accessing the SCMP enabled servers
• Domains
• Creating a federation
• Sharing services
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers