Introduction

WebSphere Business Services Fabric V6.1.2 (hereafter called Fabric) now offers significant integration with WebSphere Service Registry and Repository. The previous WebSphere Business Services Fabric integration with WSRR has been removed because the new integration offers better ways of working with WSRR. This new integration is as simple as importing endpoints from WSDL files on one or more WSRR servers or real-time integration, updating endpoints in WSRR, and having those endpoints updates reflected in Fabric. This article describes all the integration options available in Fabric V6.1.2 and describes how to use this new integration.

Prerequisites

You need to be familiar with the Fabric Composition Studio as well as WSRR.

To obtain the functionality described in this article, it is expected that WebSphere Process Server 6.1 (hereafter called Process Server) is configured with Fabric V6.1.2 and with WSRR V6.1 or later.

Back to top

Setting up the WSRR connection

Before using WSRR from Fabric, you must configure a connection to a WSRR server. If WebSphere Enterprise Service Bus (WESB) has been used previously with WSRR, this has already been configured.

To create the appropriate connection:

1. Bring up the Integrated Solutions Console for the WebSphere Process Server where Fabric was installed. From the left hand menu, open up the Service Integration branch, click WSRR Definitions, and then click New to create a new connection.
2. A form to create the connection is displayed. Enter a name for the WSRR Connection, click OK, and save the configuration.
3. After saving, open the new definition. On the right side, click Connection properties, which opens the configuration properties for the connection. If WSRR was installed on the local Process Server instance, then the registry URL is most likely correct.
   Otherwise, you may need to correct the scheme (http or https), server, or port. If security is enabled for WSRR, then additionally, you may need to configure the authentication alias and SSL configuration. More information about setting up this connection is found in Administering access to WSRR.
4. After configuring a WSRR definition, Fabric is ready for integration with WSRR as shown in Figure 1.
   
   Figure 1. Sample WSRR definitions in WebSphere Process Server
   
   
   

Back to top

Importing the WSRR WSDL

Fabric now allows the import of Web Services Description Language (WSDL) files from WSSR as well as the file system. This is a direct replacement of the legacy Fabric-WSRR integration that imports all endpoints and interfaces from WSRR at a scheduled interval. The legacy integration is no longer supported and has been removed from the product. This new import facility allows you to be explicit about which interfaces you want imported into your Fabric project. It is also more efficient than loading WSDL directly from the file system as you can load more than one WSDL file at once if imported directly from WSRR.

1. Upon invoking the "Import Interface from WSDL" or "New Interface" Fabric wizards, the following dialog is displayed as shown in Figure 2.
   
   Figure 2. First page of the Import Interface from WSDL Wizard
   
   
   The Project and Namespace fields are the same as they have always been. The only change to this page is that you can select the source of the WSDL file, a file on the local file system or WSRR. The next step in importing WSDL from WSRR is to define your search parameters.
   
   Figure 3. WSRR Interface query definition
   
   
   
2. Figure 3 shows the WSRR search parameters page. You need to select the WSRR connection first. See Setting up the WSRR connection for details on how WSRR connections are defined. The Search Type drop-down is whether you want to join your Search Fields together with AND or OR operators. The Search Fields table defines what properties for the WSDL document you want to match on. The field names can be anything, which allows for querying based on custom properties attached to WSDL documents. You can edit "Field Name" and "Values" by clicking in the appropriate columns in the table. You can add new rows to the table by clicking the Add... button and remove by clicking the Remove button. There is a special field name, Classification, that when the value is edited, it brings up the Classification Selection Dialog as shown in Figure 4.
   
   Figure 4. Classification Selection dialog
   
   
   
3. This is a single select dialog, but you can add multiple classification rows to the table. Select the Match Children Classifications check box if you want the search to also match any child classifications of the classifications you have selected.
   Note: The name, namespace, and version properties are placed in the table by default. Wild card matching (*) is allowed.
4. The next page in the wizard shows the results of the query you just defined as shown in Figure 5. You can select any number of WSDL documents to import on this page.
   
   Figure 5. WSRR interface query results selection page
   
   
   
5. To validate your search, you may select one of the WSDL documents and click the View button. This displays the raw WSDL contained in this document as shown in Figure 6.
   
   Figure 6. WSDL Viewer dialog
   
   
   
6. Again, you may select more than one WSDL document to import from this page. The next step is to select the specific interfaces and which endpoints to create based on the WSDL documents being imported. This has not changed from previous versions of Fabric as shown in Figure 7.
   
   Figure 7. Interface Selection page
   
   
   

From here, the wizard behaves exactly the same as it did in previous versions of Fabric or as if you imported a WSDL document from the file system. Select the interfaces you want to import and determine what, if any, endpoints you want to create for these interfaces. Note that endpoints created from this wizard are not WSRR endpoints. They will be the standard HTTP-based endpoints that have always been created in this wizard.

Back to top

WSRR dynamic endpoint selection

Loading endpoints from WSRR WSDL files is an easy way to get up and running using information from an existing WSRR deployment. However, to keep WSRR as the system of record, loading WSDL a file from WSRR into Fabric is not the way to go. The reason is that if an endpoint is changed in WSRR, this change is not reflected automatically within Fabric and requires a re-import to update the endpoints. To avoid continuously re-importing from WSRR, Fabric allows for dynamic endpoint selection from WSRR. This feature defines an endpoint that generates a query to WSRR at request time.

There are two ways to specify the query to be used:

1. Field-based query: You can enter commonly used fields to fetch endpoint addresses from WSRR. This is less flexible, but easy to set up.
2. Name-based query: This allows for user-defined queries to be called that obtain the addresses. This is more flexible, but involves more steps to set up, especially within WSRR.

Using either of these queries achieves the same end goal; that is, retrieving endpoints from WSRR and invoking them from Fabric. If a WSRR endpoint is in the candidate pool, the Fabric runtime queries WSRR based on the endpoints associated query. Any results returned from WSRR are turned into "transient" endpoints with the same properties as the WSRR endpoint (base cost and so on). These endpoints are incorporated back into the candidate pool.

Endpoint selection example

A Fabric request is processed that selects three non-WSRR endpoints and one WSRR endpoint. WSRR is queried and it returns six results as shown in Figure 8.

A total of 9 (3 + 6) endpoints are available in the final candidate pool. The six endpoints that were generated from the WSRR endpoint (EP 3) have the same properties (base cost and so on) and are cached for future use (see the Server Cache Time field on the WSRR Endpoint screen in Figure 10).

The final candidate pool looks like Figure 9.

Back to top

Specifying a field-based query

The recommended method of specifying this dynamic query is by using a field-based query. This query returns endpoints from WSRR that are stored in WSDL as well as endpoints that are stored in SCA export files. It allows for endpoint addresses that are stored in typical WSRR fields. If endpoints are instead stored in a user-defined WSRR concept or user-defined property, then a field-based query will not suffice, so a named query is in order (see the following section, Specifying a name-based query). The field-based query method of searching for endpoints intentionally mimics the WebSphere Integration Developer Endpoint Mediation Primitive (see Endpoint Lookup mediation primitive).

1. To display the dialog to create and edit field-based queries, right-click in the Business Service Explorer, and then click New > Endpoint. This brings up the New Endpoint dialog. Enter a name for the endpoint and select WSRR as the address type and click Next. The following dialog appears as shown in Figure 10.
   
   Figure 10. Field-based query definition
   
   
   There are three properties that you can use as parameters for a WSDL Port Type: Name, Namespace, and Version. These correspond to the name, namespace, and version properties of Port Type. For the related WSDL Port, there is more flexibility. The properties for name, namespace, and version are already populated, but you can add more fields, including system and user-defined properties and classifications on the port.
2. To add additional filter criteria on a port for another property or classification, click the Add... button next to the table. This brings up a dialog allowing for the selection of either a property where you can specify the name and value. For a classification, you can specify the value of the classification by selecting from a tree of classifications (see Figure 4). The classifications will match on exact matches as well as match on children of the classification. These criteria combined allow for a good deal of variety in searching for endpoints within WSRR.

Back to top

Specifying a name-based query

For more complex situations, where the field-based query does not cover the appropriate search criteria, or possibly the endpoint is stored in a user-defined property, a name-based query is required. This is actually easier to set up in Fabric, but it does require additional set up in WSRR; that is, the creation of a custom query. There are two kinds of queries that you can define within WSRR: property queries and graph queries. We recommend that a property query is used for integration purposes when building the query from scratch. Graph queries do not make as much sense to use, unless they already exist.

To create a name-based query in the Fabric, create a new WSRR endpoint as you did for the field-based query, but additionally click the Search Method drop-down and select Search using named query. Two pieces of data are needed to perform a name-based query. The first, "Named Query", is simply the name of the query. The other, "Search Expression", is the name of the property to be used as the endpoint address, which of course, must be returned by the named Property Query.

For example, if the Property Query returns a user-defined property called endpointAddress, then you can fill the Search Expression as endpointAddress. It is possible to leave the Search Expression field blank, which means the system will return endpoints that are stored in WSDL Port and in SCA Export format. However, to do this, the property query must minimally return two properties:

• The first is the bsrURI.
• The second is the sdoType that represents the type of element.

The query only returns an element of WSDLPort or Export. With this information, the appropriate endpoints are extracted from WSRR.

Note: Unfortunately, building property queries with the WSRR UI does not typically return the expected results when used in a programmatic manner; that is, from the Fabric. We recommend that the named query is built using the WSRR API; or alternatively, through the use of the WSRR - Connection client sample for .NET. Using this tool, simply create a user-defined property query, add the properties to be returned, test, and save the query for use with Fabric.

Endpoint selection simulation in Composition Studio

Simulation within the Fabric Composition Studio remains unchanged. You still need to specify your context specification and required inputs. If your simulation selects a WSRR endpoint, it does not query WSRR and get the final address that would be selected. This decision was made to continue to allow for disconnected simulations. Here are some results from a simulation that was created to select between an HTTP endpoint and a WSRR endpoint. The WSRR endpoints query test is shown in Figure 11.

When you run the simulation, there are two candidate endpoints, as shown in Figure 12.

Finally, the WSRR endpoint is selected, but again, we do not query WSRR. One of the endpoints from the query test will be the final selection at execution time as shown in Figure 13.

Back to top

Conclusion

This article covered the new WSRR integration feature in WebSphere Business Services Fabric V6.1.2. This new integration allows importing endpoints from WSRR in a static manner as well as endpoints from WSRR using two dynamic methods: field-based and name-based queries. You can test these queries and simulate endpoint selection with WSRR-based endpoints. These features allow WSRR to be the system of record for endpoints and allow for the dynamic selection of endpoints from WSRR. This is a significant step for leveraging an existing WSRR installation while incorporating the power of WebSphere Fabric.

Resources

• WebSphere Process Server Information Center: Administering access to WSRR
  
  
• WebSphere Integration Developer Information Center: Endpoint Lookup mediation primitive
  
  
• WSRR - Connection client sample for .NET
  
  
• WebSphere Service Registry and Repository product site
  
  
• developerWorks WebSphere business process management zone
  
  

About the authors

Joel Trunick is a Software Engineer at IBM in Austin, Texas. He works on WebSphere Business Services Fabric Administration tools.

Michael Thompson is a Software Engineer at IBM in Austin, Texas. He currently develops Eclipse plugins for WebSphere Business Services Fabric Composition Studio.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Setting up the WSRR connection
• Importing the WSRR WSDL
• WSRR dynamic endpoint selection
• Specifying a field-based query
• Specifying a name-based query
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Service Registry and Repository
• Article: WebSphere Service Registry and Repository
• Buy: WebSphere Service Registry and Repository

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

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

Special offers