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.

This article will detail the configuration steps for enabling SCMP on the registry WSRR and each of the currently supported connectivity providers, WESB and WMB. Setting up the SFM console will also be described, as will the configuration steps for a simple two domain scenario. More complex scenarios can be configured but this article will concentrate on the principles of configuration and setup.

By the end of this article the user will be able to set up:

• The products required to create 2 service domains, each containing an instance of WSRR acting as the registry along with either WESB or WMB as the connectivity provider.
• The SFM console running in a business space environment supplied by WSRR.

Summary of Service Connectivity Management Protocol

Other articles will go into many of the higher level concepts of SMCP, however here is a brief recap of some of the concepts this article will mention, and the parts that each of the products will play in relation to them.

In SCMP there are four server concepts:

• Federation server. A federation is a list collection of domains.
• Domain server. A domain consists of a registry and zero or more connectivity providers. Various domains may exist representing different departments or geographical locations of an organization. Each domain will have its own set of services that it uses (stored in a registry). SFM allows these services to be shared and managed with other domains.
• Registry server. A registry represents a service registry, where the service endpoints will be held (amongst other things). Each domain must contain one registry.
• Connectivity provider server. A connectivity provider represents an ESB which groups of services can be proxied in.

WSRR V7 provides all the capabilities for implementing the federation, domain and registry servers. Similarly, WESB and WMB V7 can both be used as the connectivity provider server. You use either WESB or WMB or both as a connectivity provider. The SFM console communicates with the products by accessing information through service documents URLs.

Each server used in SFM will have to map to an instance of the product. This means that if there are 2 domains, each containing a registry and a connectivity provider, a different instance of the registry will be required for each domain, and a different instance of the connectivity provider will be required for each domain. So for example, setting up 2 domains, each with a registry and a connectivity provider, will require 2 instances of WSRR to be installed and either a WESB and a WMB or 2 instances of WESB, or 2 instances of WMB. In this article, 2 service domains will be set up, the first containing WSRR and WESB, the second containing WSRR and WMB.

Back to top

Configuring WSRR for SCMP

The SFM feature pack can be downloaded for version 7 of WSRR. The feature pack will contain files for both SCMP enablement and for running the SFM console. When enabled with SCMP, WSRR can act as the federation, domain and registry servers for an SFM environment. The service documents and artifacts for enabling the services to be shared are managed by the registries and connectivity providers.

The following steps will show how to configure WSRR.

The examples in this section will focus on an environment without administrative or application security enabled. For some of the extra steps to enable security in WSRR, see the section titled 'Configure Security'.

For further information regarding the configuration of WSRR that is not covered below, please refer to the WSRR information center.

Installing WSRR

SCMP can be enabled on an existing version of WSRR v7, however if an install is required follow the steps below. As the SFM console runs within the Business Space environment, the steps for how to augment a profile to enable this function will also be described.

1. Install WSRR as per the instructions in the WSRR information center.
2. Create a service registry profile using either the PMT, or the profileManagement command line tool.
3. Start up WSRR and log into the WSRR admin console. This can be found at:
   1. http://<hostName>:<port>/ServiceRegistry
4. Create a configuration profile in WSRR:
   1. Select the Manage Profiles > Configuration Profiles option (As shown in figure 1).
   2. Using the 'Load Configuration Profile' button. Navigate to the <WAS_HOME>/WSRR/Config' directory and select the profile of choice. In this example select the 'GovernanceEnablementProfile_v70.zip'.
   3. Load this into WSRR with a suitable name.
   4. Return the 'Manage Profiles' panel and activate the new profile using the 'Make Active' button (As shown in figure 2).

5. Stop the server.

WSRR should now be ready to be configured with SCMP.

Install SFM Feature Pack

The next step is to install the contents of the SFM feature pack into WSRR. This is done via the IBM Installation Manager (IM) on distributed systems. For the z/OS platform, the feature pack is supplied as a tar file containing the deployment artifacts which will need to be extracted.

To begin with, a copy of the SFM feature pack zip file is required.

1. In IM, add the SFM feature pack as a repository. This is done by:
   1. File > Preferences...
   2. Click 'Add repository’
   3. Browse to the location of the SFM feature pack zip file, and select it.
   4. Click 'OK' to close the preferences window. Figure 3 shows the new repository added.

2. In IM, click Install and follow the steps through,
   1. Select 'IBM WebSphere Service Registry and Repository Version 7.0 Feature Pack for Service Federation Management' on the panel titled 'Install Packages'. Figure 4 shows the SFM package option.
   2. Select the appropriate WSRR install location.

3. The Feature page lists the available features contained in the feature pack:
   1. IBM Service Federation Management console
   2. IBM WebSphere Service Registry and Repository Service Connectivity Management enablement

Select both if you plan to install the SFM console on this instance of WSRR, as well as just enabling SCMP. If the console is being installed on a different WSRR, then 'IBM WebSphere Service Registry and Repository Service Connectivity Management enablement' is the only option required. For this example the console is required, so select both options, as shown in Figure 5.

4. Click 'Install', then 'Finish'. As shown in Figure 6.

Further details of the installation process can be found in the WSRR info center here: http://publib.boulder.ibm.com/infocenter/sr/v7r0/index.jsp?topic=/com.ibm.sr.sfm.doc/tsfm_installing_fp.html

At this point the SFM feature pack files should have been added to the file system in the directory:

<WAS_HOME>\feature_packs\WSRR-SFM 

Enable SCMP on WSRR

SCMP enablement and configuration involves loading some of the files supplied in the SFM feature pack into WSRR and configuring WAS settings.

The full instructions (including details on loading files via scripts, and clustering) can be found in the WSRR infocenter (http://publib.boulder.ibm.com/infocenter/sr/v7r0/index.jsp?topic=/com.ibm.sr.sfm.doc/tsfm_configuringenablement.html), however the configuration steps for single server WSRR via the WSRR admin console are as follows:

1. Start the WSRR server and log into the admin console at: http://<hostName>:<port>/ServiceRegistry (i.e. http://myHost:9080/ServiceRegistry)
2. Ensure the 'Configuration' perspective is selected, as shown in figure 7.

3. Load the SCMP business model objects:
   1. Navigate to Active Profile > Business Model Systems > Load Business Model System
   2. Browse to <WAS_HOME>\feature_packs\WSRR-SFM\owl
   3. Load the files:
      • scmpfdBusinessModel.owl
      • scmpsdBusinessModel.owl
      • scmpsrBusinessModel.owl

4. Load the SCMP plugin jar:
   1. Navigate to Active Profile > Plug-in JARs > Load JAR Plug-in
   2. Browse to <WAS_HOME>\feature_packs\WSRR-SFM\pluginJar
   3. Load the file SCMPEnablement-1.0.0.jar
   4. Provide the plug-in jar with a sensible name

5. Load the atom feed:
   1. Navigate to Active Profile > Atom Feed Application > Load Atom Feed Application Configuration
   2. Browse to <WAS_HOME>\feature_packs\WSRR-SFM\feedApp
   3. Load the file SCMPFeedsApp.xml
   4. Provide the Atom feed configuration with a sensible name.

6. Enable WSRR to act as a registry server. Do this by creating an instance of the ServiceRegistry object.
   1. Switch to the Administrator perspective.
   2. On the Home page, you should see a list of names under the "Business Objects" box.
   3. Select "ServiceRegistry", as shown in Figure 11.
   4. On the next page, click "New".
   5. Put in a name (e.g. "My Service Registry") and other descriptive details i.e. contact and organization.
   6. Click "Finish".

WSRR provides a WAS environment variable that can be used to specify the host name and port that are used as the URL prefix in Service Connectivity Management (SCM) enablement. This environment variable must be defined. This will need to be carried out in the WAS admin console. A new WAS variable called WSRR_ENDPOINT_URL_PREFIX needs to be created which will point at this instance of WSRR:

1. Log onto the WAS admin console at http://<hostName>:<port>/ibm/console
2. Navigate to Environment > WebSphere variables
3. Select the appropriate scope, in this example server scope can be used.
4. Create a new variable called WSRR_ENDPOINT_URL_PREFIX, with the value "http://hostname:port" or "https://hostname:port", where hostname and port point to the location that WSRR is installed on, as shown in figure 12.
5. Save the changes.
6. Restart the WebSphere Application Server.

At this point WSRR should have been configured to run SCMP code. As mentioned previously, WSRR will act as the federation, domain and registry servers in the SCMP model. The registry will be exposed to SFM via the service document url, which will be in the form of: <host>:<port>/ServiceRegistryFeeds/servicedocument

i.e. http://myHost:9080/ServiceRegistryFeeds/servicedocument

This url will be required when using the SFM console. As mentioned earlier, each registry can only be used in 1 domain at a time. As a result in order to create 2 service domains, 2 instances of WSRR will be required, each enabled via the above steps.

Back to top

Configure WESB for SCMP

WebSphere Enterprise Server Bus (WESB) V7 already contains the SCMP enablement code but some configuration steps are required to enable it to be used as a connectivity provider.

When enabled with SCMP, WESB can act as a connectivity provider in a service domain, meaning that SFM can create proxies on it representing service groups that are being shared.

The examples in this section will focus on an environment without administrative or application security enabled. For some of the extra steps to enable security in WESB, see the section titled 'Configure Security'.

Install WebSphere Enterprise Server Bus

1. Install WESB as described in the WESB information center (http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wesb.doc/doc/welcome_wps_ins.html).
2. Using either the PMT or the manageprofiles command line tool, create a default.esbserver profile for WESB (i.e. a stand-alone server). For details of how to configure a clustered environment check the infocenter (http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wesb.doc/info/welcome.html), but this article will focus on setting up a standalone environment.

Enable SCMP on WESB

The following steps will set WESB up to work as a connectivity provider server with SFM.

1. Start up and log onto the WESB admin console at http:// <hostName>:<port>/ibm/console (i.e. http://myHost:9060/ibm/console)
2. Navigate to Services > REST Services > Rest service providers > REST Service Gateway, as shown figure 13.
   • Make sure the value specified at hostname is fully qualified and in lowercase (i.e. myhost.ibm.com instead of just myHost).
   • Make sure that the values for protocol and port match the expected level of security (i.e. if protocol = https the port should be something like 9443, and if protocol = http the port should be something like 9080) The ports will be the ones found in either WC_defaulthost and WC_defaulthost_secure (depending on the level of security). Port information can be found under Servers > Server Types > server1 > ports, as shown in figure 14.

3. Create a new SCM connectivity provider.
   1. Navigate to Service Integration > SCM Connectivity Provider.
   2. Add a new connectivity provider.
   3. Fill in the details, keeping in mind that the host value will be the fully qualified host name and the port values will be the ones found in WC_defaulthost and WC_defaulthost_secure. As shown in figure 15.
   4. Save the changes.

For more information about running WESB with security on see the security section. The service documents url for this connectivity provider server will now be in the form of: <hostName>:<port>/rest/scmp/servicedocument.

i.e. http://myHost:9080/rest/scmp/servicedocument. This url will be required when using the SFM console.

Back to top

Configure WMB for SCMP

WebSphere Message Broker (WMB) V7 already contains the SCMP enablement code but some configuration steps are required to enable it to be used as a connectivity provider.

When enabled with SCMP, WMB can act as a connectivity provider in a service domain, meaning that SFM can create proxies on it representing service groups that are being shared.

The examples in this section will focus on an environment without administrative or application security enabled. For some of the extra steps to enable security in WMB, see the section titled 'Configure Security'.

For more details than supplied below about setting up SCMP on WMB, please check the WMB information center (http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/bn19100_.htm).

Configure products

This article assumes that WMB and associated components such as WebSphere® MQ have been installed. For more information on how to obtain and install WMB please refer to the information center. (http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ax01445_.htm).

1. Startup MQ and the MB explorer.
2. Create a broker. In this example the default broker configuration will be enough. In MB explorer click the ‘Create the default configuration’ button.

Now that WMB is installed and a broker has been created we can enable the broker to be used as a connectivity provider for SFM.

Enable SCMP on WMB

This example assumes default ports. For more information about broker ports check the WMB information center (http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/bn19020_.htm).

1. Open a message broker command prompt to execute the following steps.
2. Run the following mqsichangeproperties commands to enable SFM in the broker over HTTP:
   mqsichangeproperties brokerName -b servicefederation -o scmp -n enabled,enableSSL -v true,false
3. Set the hostname and context root for the service document URL that will be required when adding the broker to the SFM Console. The full domain qualified hostname should be used to ensure reliable addressing:
   mqsichangeproperties broker name -b servicefederation -o scmp -n hostname,contextRoot -v <fully_qualified_hostname>,/scmp
4. Run the mqsichangeproperties command to configure the properties relating to the HTTP port to be used:
   mqsichangeproperties brokerName –b servicefederation –o HTTPConnector –n port –v 8085
5. Configure the properties that relate to the SFM capability of an execution group. The hostname specified needs to be fully qualified. This example will assume default ports, if this is not the case check the WMB information center for more details:
   mqsichangeproperties TEST -e exgroup1 -o ServiceFederationManager -n proxyURLHostName -v <fully_qualified_hostname>
6. Stop the broker.
7. Start the broker and check the system log to ensure that it reports the Service Federation listener has successfully started. This message, BIP3769, also confirms the service document URL value that must be configured into the SFM console.
   Service Federation SCMP listener initialized. Additional information : "SCMP Service Document URL" "http://myHost.ibm.com:8085/scmp/servicedocument"

For more information about running WMB with security on see the security section.

The broker has now been enabled with SCMP. As a consequence of enabling the broker for SCMP, the execution groups in the broker are also enabled for SCMP; they can now create and host the proxy instances to provide service availability.

The service document URL for this WMB will take the form of: <host>:<port>/scmp/servicedocument. e.g. http://myHost:8085/scmp/servicedocument. This url will be required when using the SFM console.

Back to top

Install SFM console on business space

At this point, all of the various products have been enabled for SCMP. The next step is to install the SFM console.

The SFM console comes in 2 parts:

1. An application to be installed on WAS containing the SFM coordinator, named SFM-Coordinator-xxx.ear.
2. A business space widget for the SFM console, named SFM-Widgets-xxx.zip.

Create database

The SFM console requires a database to store some information. The feature pack download contains the ddl files needed to set up the databases. These can be found in <WAS_HOME>\feature_packs\WSRR-SFM\ddl\. For details about creating databases on z/OS refer to the information center. This article will assume a distributed environment. Details about the databases supported can be found in the information center here: http://publib.boulder.ibm.com/infocenter/sr/v7r0/index.jsp?topic=/com.ibm.sr.sfm.doc/tsfm_configuringconsole.html .

1. Run ddl (found in <WAS_HOME>\feature_packs\WSRR-SFM\ddl\) for chosen database, to create SFM tables.

Example: To create the required database tables using derby follow the steps below:

1. Navigate to <WSRR_HOME>\derby\bin\embedded
2. Run ij.bat/.sh
3. Run the following commands:
   Connect
'jdbc:derby:consoleDB;user=<username>;password=<password>;create=true';
run '<WSRR_HOME>\feature_packs\WSRR-SFM\ddl\derby\SFMConsole.ddl';
commit;
quit;

Once a database has been created, to enable the SFM console to use the database we will now configure a datasource in the WAS administrative console.

1. Log onto the WAS admin console at http://<hostName>:<port>/ibm/console
2. Create the authentication alias matching the user name and password used when creating the database.
   1. Navigate to Security > Global Security.
   2. In the authentication section at the right, expand Java™ Authentication and Authorization Service section and click the J2C authentication data link, as shown in figure 16.
   3. Create a new authentication alias, giving it the alias name sfmAlias and the username and password matching the database created.

3. Create a JDBC provider for the database created previously
   1. Navigate to Resources > JDBC > JDBC Providers.
   2. Select node scope.
   3. Click 'New' to create a new JDBC provider.
   4. Select the database type to match the database created earlier. Figure 17 shows an example of this during a derby set up.
   5. Follow the rest of the steps through giving the provider sensible values.

4. Save your changes.
5. Create a datasource for the SFM database
   1. Select the JDBC provider created in step 3.
   2. Under 'Additional properties' select 'Data sources', as shown in figure 18.
   3. Create a new data source.
   4. Give it a sensible name and the jndi name of jndi/SFMDB, as shown in figure 19.

• In the example above, the database name required would be 'consoleDB', as shown in figure 20.

• Set the sfmAlias as the auth alias where required, as shown in figure 21.

• When the wizard steps have been finished save the changes.
• Select the newly created datasource and use the 'Test connection' button to check the database can be connected to correctly, as shown in figure 22.

Install SFM Coordinator app

The following steps will show how to install the SFM coordinator application into WAS. Note that the SFM coordinator app MUST be installed on the same server as the SFM business space widget will be installed on.

1. Log onto the WAS admin console at http://<hostName>:<port>/ibm/console e.g. http://myHost:9060/ibm/console.
2. Load the SFM Coordinator ear file.
   1. Navigate to Applications > Enterprise application > New enterprise application.
   2. Browse to <WAS_HOME>\feature_packs\WSRR-SFM\installableApps.
   3. Select SFM-Coordinator-xxxx.ear.
   4. Click 'Next'.
   5. Click 'Detailed'.
   6. Click 'Next'.
   7. Select the step named "Map resource references to resources" and browse for the datasource that was created in the previous section (with the jndi name "jndi/SFMDB" in the example provided), as shown in figure 23.
   8. Finish the wizard.

3. Save the changes.
4. Restart the server.

Install SFM Business Space widget

As mentioned in a previous step, the SFM business space widget and the SFM coordinator application must be installed on the same server. The SFM console is supported on the version of Business Space supplied with WSRR.

To check to see if Business Space has already been installed, attempt to access the Business Space console on the url: http://<hostName>:<port>/mum/enabler. If the Business Space console can be seen (as shown in figure 24), then Business Space has already been installed.

If Business Space has not been installed, follow the steps to install it.

1. The installation mechanism for Business Space is a WAS augmentation. This augmentation is not available from the Profile Management Tool (pmt), it has to be done using 'manageprofile' in <WAS install dir>/bin on the command line.
2. Augment an existing WAS profile using the following command:
   manageprofiles -augment -profileName <profilename> -templatePath
<WAS_HOME>\profileTemplates\BusinessSpace\default.bspace -cellName <cellname> -nodeName <nodename>

Now that Business Space has been installed install the next step is to install the SFM business space widget as follows:

1. From a command prompt:
   1. cd <WAS_HOME>/profiles/myProfile/bin
   2. wsadmin.bat -conntype NONE
   3. $AdminTask installBusinessSpaceWidgets {-nodeName myNode01 -serverName server1 -widgets <WSRRHome>\feature_packs\WSRR-SFM\installableApps\SFM-Widgets-xxxx.zip}
   4. $AdminConfig save
   5. exit
2. Stop (if the server was running) and restart the WAS server.
3. Add the SFM widget to the business space console

• Log onto business space at: http://<hostName>:<port>/mum/enabler
• Navigate to Actions > Create Space (As shown in figure 25)
• Give the new space a name.
• Under the dropdown titled "Create a new space using a template", select the "Service Federation Management" template, as shown in figure 26.
• Click "Save"

4. The SFM console will be visible in the newly created space, as shown in figure 27.

At this point the SFM console has been added to Business Space and products involved in creating 2 service domains have been configured with SCMP.

Back to top

Configure security

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.

These steps will need to be done manually, as SFM will assume the products in question have the authority to communicate with each other. For more information about SFM security visit the SFM information center at (http://publib.boulder.ibm.com/infocenter/sr/v7r0/index.jsp?topic=/com.ibm.sr.sfm.doc/rsfm_security.html).

Basic authentication in WAS

The simplest form of security in WAS is basic authentication, which essentially means a user name and password will need to be supplied in order to access the server and applications. For simplicity, this article will describe enabling administrative, application and Java™ 2 level security on the WAS (WESB or WSRR) server.

1. Log onto the WAS admin console at http://<hostName>:<port>/ibm/console i.e. http://myHost:9060/ibm/console
2. Navigate to Security > Global security
3. Use the 'Security Configuration Wizard' button to configure administrative, application and Java™ 2 security for the server.
4. Save changes.
5. Restart the server.
6. The admin console url will now be https://<hostName>:<secure_port>/ibm/console, i.e. https://myHost:9043/ibm/console.

For more information about WAS security see the WAS information center: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welcome_nd.html.

Swapping certificates (WSRR and WESB)

In order to get 2 WAS based servers (e.g. WSRR or WESB) talking to each other over HTTPS, each will need to exchange SSL certificates before they will trust the other. In an SFM setup this will typically need to happen between each of the servers involved and the server hosting the SFM console. There are a number of ways to exchange certificates. For full details check the WAS information center. For this example certificates can be exchanged via the following steps:

1. Go to the console for each of the servers.
2. Navigate to Security > SSL certificate and key management > Key stores and certificates
3. Click on NodeDefaultTrustStore > Signer Certificates, as shown in figures 28 and 29.

4. Click 'Retrieve from port' and fill in the details of the other profile. The alias is just a name for this certificate.
5. Click on 'Retrieve signer information' (as shown in figure 30) and then OK and Save.

6. Repeat the same steps on the second profile.
7. Stop and restart both servers.

Security on WMB

For full details on configuring security on WMB refer to the WMB information center. http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/bp28220_.htm). Some extra steps will be required in order to configure SCMP on WMB to use HTTPS.

1. Run the following mqsichangeproperties commands to enable SFM in the broker: mqsichangeproperties brokerName -b servicefederation -o scmp -n enabled,enableSSL -v true,true
2. Set up the Broker's keystore
   1. Find the ikeyman program in MB's install directory: e.g. /opt/ibm/mqsi/7.0/jre16/bin
   2. Run ./ikeyman
   3. Select 'Key Database File' > New
   4. Browse to a directory that’s NOT in the WMB install path.
   5. Provide a password for that new store when prompted (this will be required in a later command).
   6. Click on 'New Self-Signed ...' then fill in the first field at the top of the new window, and enter 'broker', click OK.
   7. Now click on 'Extract Certificate ...' and browse to save in the same place as the saved keystore file, accept the name of cert.arm and the given type.
3. Import the cert.arm in your WAS profile in which the SFM console runs.
   • Log onto the WAS admin console at https://<hostName>:<port>/ibm/console
   • Navigate to Security > SSL certificate and key management > key stores and certificates > NodeDefaultTrustStire > Signer certificates
   • Click on Add, enter a sensible name as the alias, and put the full path to where you copied the file, then click OK.
4. Configure the broker to use the keystore:
   • mqsichangeproperties brokerName –b servicefederation –o HTTPSConnector –n port,keystoreFile,keystorePass –v 8086,keys.jks,<password> (where 8086 is the port used and keys.jks refers to the location of the keystore)
5. Configure the broker's truststore:
   • The value of '/tmp/key.jks' should be replaced with the directory used in step 1: mqsichangeproperties brokerName –o BrokerRegistry –n brokerTruststoreFile –v /tmp/key.jks
6. Set the password to use with the truststore:
   • <password> is the password set earlier on for the keystore: mqsisetdbparams brokerName –n brokerTruststore::password –u <user> –p <password>
7. Set the userid and password to use with SCMP using the following command (e.g. admin/admin): mqsisetdbparams brokerName –n sfm::scmp –u <user> –p <password>
8. Stop and restart the broker.
9. Setup the information for the proxies:
   • Set up the proxies using the following command to specify the values of the host name, the insecure port and secured port:
     mqsichangeproperties brokerName –e default –o
ServiceFederationManager –n
proxyURLHostName,port,securePort –v myHost,8811,8844

Back to top

Summary

The reader can now configure all of the products involved in setting up service domains which can be managed by SFM. They can also setup and access the SFM console, running in Business Space, which can be used to manage and share services between the service domains.

Resources

Learn

• "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.
  
  
• "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.
  
  
• In the SOA and Web services area on developerWorks, get the resources you need to advance your skills.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

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.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Configuring WSRR for SCMP
• Configure WESB for SCMP
• Configure WMB for SCMP
• Install SFM console on business space
• Configure security
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Message Broker

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