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
To execute the DLA, use the
found in the DLA's bin directory. For example, on Linux®, the command would be:
–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:
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
loadidml.sh from the TADDM server
machine’s $COLLATION_HOME/bin directory. For example, on Linux the command
./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
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:
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
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.
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
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.
- Information Centers
- Redbook: Integrating Tivoli Products
- IBM developerWorks Tivoli
- IBM developerWorks WebSphere
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.