Comment lines: Integrating WebSphere Service Registry and Repository with Tivoli Application Dependency Discovery Manager

Using the IBM® WebSphere® Service Registry and Repository Discovery Library Adapter (DLA), administrators can see the Web services present in an IT environment in the same IBM Tivoli® Application Dependency Discovery Manager user interface with which they view other resources, applications, and systems. Here is a high level overview of the integration possible between these two products that could help you enhance your understanding and visibility of your overall IT environment. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Robert R. Peterson (rrpeters@us.ibm.com), WebSphere Enablement Consultant, IBM

Robert R. PetersonRobert R. Peterson is a solution architect for Tivoli's Integration Center of Competency. He works to improve integration across Tivoli's Service Availability and Performance Management (SAPM) product portfolio. Robert is an IBM Master Inventor for his patent contributions, an IBM Press author, and a frequent conference speaker. Visit his website.


developerWorks Contributing author
        level

06 October 2010

Also available in Chinese Portuguese

Get a better view

If you are using IBM® WebSphere® Service Registry and Repository (hereafter referred to as Service Registry and Repository), chances are that you’re integrating it with other IBM WebSphere products, such as IBM WebSphere Message Broker or IBM WebSphere DataPower® SOA Appliances. But did you know that you can also integrate Service Registry and Repository with several IBM Tivoli products as well? For example, the status of a service in Service Registry and Repository can be updated with IBM Tivoli® Composite Application Manager (ITCAM) for SOA, and Service Registry and Repository can also synchronize with IBM Tivoli Change and Configuration Management Database.

The purpose of this article, however, is to highlight how you can export metadata about WSDL services from Service Registry and Repository and then load that metadata into IBM Tivoli Application Dependency Discovery Manager (TADDM). With information on Service Registry and Repository Web services in TADDM, an administrator can have a holistic view of all the Web services and policies active in their IT environments from one place: the TADDM user interface.


What is Tivoli Application Dependency Discovery Manager?

A typical data center has an array of different systems and applications, and are used by multiple teams on multiple projects. Keeping track of the machine inventory and the applications running throughout a data center can easily become overwhelming. Taking things a step further, determining what dependencies and relationships these different systems have amongst each other can be an even more daunting task. This is where TADDM can help: Tivoli Application Dependency Discovery Manager is designed to serve as a repository for what is in your data center -- from switches to computer systems to applications -- and how they all interact with each other.

TADDM has an extensive graphical interface with which you can list and query for particular configuration items, as well as view relationships and topologies. TADDM also maintains a change history of configuration items along with the ability to take a "snapshot" of a version so that you can compare configuration items. With these tools, an administrator can easily see the changes to the data center over time. TADDM also has customization and organization capabilities for the components it stores; for example, components can be grouped into business applications.

TADDM can be populated with information about your IT environments in several ways. For example, TADDM can perform scans of IP subnets, during which it intelligently discovers systems and components for you. TADDM also has a bulk loading capability with which data can be imported in IDML (Identity Markup Language) format. Discovery Library Adapters (DLAs) are small standalone software components that collect data in IDML format. Several DLAs are available for Tivoli products (like IBM Tivoli Monitoring), z/OS environments, databases, and applications -- and also for WebSphere Service Registry and Repository, which you will see shortly.


How the integration works

The DLA for Service Registry and Repository is shipped as part of ITCAM for SOA; it is an independent component with its own installation package. Once installed and configured, the DLA has the capability to scan Service Registry and Repository and discover the services present in the repository. The DLA can be installed on an independent machine (Figure 1) or installed locally on the same server as Service Registry and Repository. If it is installed independently, it requires a copy of the Service Registry and Repository client JARs so it can communicate remotely with Service Registry and Repository. The DLA produces an XML file that contains metadata about all the WSDL services it finds in Service Registry and Repository, along with associated WS-Policy documents.

Figure 1. Overview of Discovery Library Adapter usage
Figure 1. Overview of Discovery Library Adapter usage

To execute the DLA, use the WSRR_DLA command found in the DLA's bin directory. For example, on Linux®, the command would be:

./WSRR_DLA.sh –r

The –r switch indicates that the IDML should refresh completely instead of listing only recent Service Registry and Repository changes. When the operation is complete, a file with a name similar to this is written to the DLA /staging directory:

WSRRv600-L.hostname.2010-09-13T16.05.23.449Z.refresh.xml

The Service Registry and Repository DLA can also be configured to copy the resulting XML file via FTP or SFTP to an off-box location. The DLA can be configured to include all WSDL services in Service Registry and Repository or, alternatively, it can pull in only services within one or more Service Registry and Repository classifications.

The XML files produced by the DLA conform to the IDML schema; the files produced are often referred to as IDML books. IDML uses a common data model which standardizes how system solutions and technologies represent resources and relationships. TADDM can import IDML books. It adds the resources and any relationships in the book to its repository.

To import the Service Registry and Repository IDML book into TADDM, use the load command loadidml.sh from the TADDM server machine’s $COLLATION_HOME/bin directory. For example, on Linux the command would be:

./loadidml.sh –f \tmp\WSRRv600-L.hostname.2010-09-3T16.05.23.449Z.refresh.xml

Using these commands in conjunction with the DLA’s capability to transfer files, the process of importing Web services from Service Registry and Repository into TADDM can be easily scripted using (for example) simple shell scripts and UNIX® cron processes. This enables the WSDL imports to TADDM to be automated.

After loading the book, you’ll notice new resources listed in the TADDM user interface as Web service resources. For example, Figure 2 shows three Web services imported to TADDM from Service Registry and Repository: FinancialService, QuoteService, and CRService1.

Figure 2. TADDM user interface
Figure 2. TADDM user interface

Also notice that under the Details tab for a service, you can see the WSDL operations debitOperation and creditOperation. Using this process, a TADDM administrator can keep track of Web services in TADDM along with other components and systems in their IT environment.


Some extra integration tips

Here are some additional points to help you with this integration:

  • Logging

    The log file for the Service Registry and Repository DLA can be found at /logs/WSRRDLALog.log. Be sure to take a look at the log file after running WSRR_DLA.sh.

  • Validation

    TADDM comes with a certification tool for IDML files. The tool can validate the integrity of any IDML file, not just those generated by the Service Registry and Repository DLA. You should run the certification tool on Service Registry and Repository IDML books before they are imported into TADDM. The tool consists of a JAR file called idmlcert.jar located in /cmdb/dist/sdk/dla/validator/v2 within your TADDM installation directory. Listing 1 shows an example of its usage along with some example output.

    Listing 1. Using the IDML certification tool
    java -Xmx256m -Xmx256m -jar idmlcert.jar 
    -verbose WSRRv600-L.hostname.2010-09-3T16.05.23.449Z.refresh.xml
    
    CDM.xsd version=2.10.6
    idml.xsd version=0.8
    NamingRules.xml version=2.10.11
    DL model version=2.10.6
    
    =======================================================================
    File: WSRRv600-L.nc185067.tivlab.raleigh.ibm.com.2010-09-13T16.05.23.449Z.refresh.xml
    =======================================================================
    
    Certification tool found:
      19 Managed elements
      32 Relationships
    
    [PASS] - TEST 00 (XML Parse)
    [PASS] - TEST 01 (All MEs have a valid ID)
    [PASS] - TEST 02 (superior reference IDs in book)
    [PASS] - TEST 03 (Attributes are valid)
    [PASS] - TEST 04 (All managed elements have a valid naming rule)
    [PASS] - TEST 05 (All managed elements are valid)
    [PASS] - TEST 06 (All relationships are valid)
    
    Classes used: (occurrences)
       process.Document (4)
       process.ManagementSoftwareSystem (1)
       process.Repository (1)
       soa.WSOperation (4)
       soa.WSPort (3)
       soa.WSPortType (3)
       soa.WebService (3)
    Relationships used: (occurrences)
       definedUsing(soa.WSOperation, process.Document) (5)
       definedUsing(soa.WSPort, process.Document) (4)
       definedUsing(soa.WSPortType, process.Document) (4)
       definedUsing(soa.WebService, process.Document) (4)
       federates(process.Repository, process.Document) (4)
       federates(soa.WSPortType, soa.WSOperation) (4)
       federates(soa.WebService, soa.WSPort) (3)
       invokedThrough(soa.WSOperation, soa.WSPort) (4)
    
    Book passed all certification tests
    Elapsed time: 5.9 seconds

    The certification tool is not guaranteed to find all problems with an IDML book, but if a problem is found the tool provides helpful debugging information.

  • Viewing

    You can view all the objects that have been imported into TADDM from the IDML book. To do this, select MSS from the TADDM Edit menu, then scroll to the bottom and select the Service Registry and Repository DLA. Click List CIs. You should see a list of objects similar to Figure 3.

    Figure 3. WSRR objects imported into TADDM
    Figure 3. WSRR objects imported into TADDM

Conclusion

With the WebSphere Service Registry and Repository DLA, administrators can see the Web services present in an IT environment in the same Tivoli Application Dependency Discovery Manager user interface with which they view other resources, applications, and systems. This article provided a brief introduction to TADDM with an overview of the integration between Service Registry and Repository and TADDM that’s possible using the product-specific DLA, and offered additional tips when using the Service Registry and Repository IDML book. Use the Resources below to further investigate how TADDM can help you by enhancing your understanding and visibility of your overall IT environment.

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Tivoli
ArticleID=549096
ArticleTitle=Comment lines: Integrating WebSphere Service Registry and Repository with Tivoli Application Dependency Discovery Manager
publish-date=10062010