Collecting inventory from distributed repositories

---

Having read the previous portions of this redbook, you will note an immediate difference in some of the terminology associated with scanning distributed repositories. Figure A-1 illustrates the basics of the distributed architecture.

Figure A-1: Distributed architecture

The inventory process

The inventory process consists of a set of scanners, a set of analyzers, and a OS/390 DB2 database. WSAA takes an inventory of resources (such as, .java or .html files), analyzes them, and then stores information about them in the DB2 database. During the inventory process for distributed assets, scanners and analyzers running on a Windows server identify, analyze, and classify both physical assets (such as containers and files) and logical assets (such as classes, methods, and fields).

1. We begin the process with scanning the resources.

   A scanner is a module in WSAA that can access an enterprise server where code assets are maintained. To support scanning on different enterprise servers, the scanner component is composed of a set of scanners — one for each enterprise server type.

   Currently, WSAA provides scanners for:

   • File systems

   • Configuration management systems (Rational ClearCase, PVCS, CVS,

   CMVC, and a WebDAV interface for additional CMs)

   • WebSphere Application Server 4.0 Advanced Edition installations

   The scanner discovers, identifies, and accesses new or updated resources on the enterprise server.

2. When the scanner encounters an asset, it checks if an analyzer is registered for that type of resource.

   Note 

   An analyzer is a module in WSAA that can extract semantic and textual information from assets identified by the scanners.

   • WSAA ships with over 40 analyzers, including Java, HTML, JSP, EAR files,

   WAR files, EJB JAR files, JSP tag libraries, J2EE Client files, XML, bytecode, C/C++, and ASCII text.

   The semantic information extracted by an analyzer consists of attributes that are unique to the specific type of asset (and, coincidentally, something that you might want to query). For example:

   The semantic information for Java assets the semantic information includes (but is not limited to) the following:

   • Class

   • Superclass

   • Interface

   • Methods

   • Fields

   The textual information (or free-form text) consists of words for which a user may wish to search.

   If an analyzer is found for the resource type and the resource has not already been analyzed and its information stored in the database (or it has changed since the last scan), then the resource is analyzed, and the results are stored and indexed in a DB2 database.

   Note 

   For each analyzed resource, both the semantic and textual information are stored in a relational database on the host.

3. After all assets have been scanned and analyzed, a postprocessor is activated.

   The postprocessor infers relationships among assets and links them together.

Distributed analyzers

WSAA distributed analyzers take an inventory of the contents and relationships of code assets in enterprise repositories. WSAA provides over 40 analyzers for the distributed environment. These analyzers can take an inventory of the content and relationships of the following types of files:

• Text files (in ASCII format)

• Java/J2EE files (including archive files)

• Other languages, for example: C and C++:

Each of these languages is associated with a set of semantic characteristics and/or attributes. The corresponding analyzers detect these attributes in the scanned files, thus facilitating semantic search over these files (by giving values for selected attributes).

The majority of analyzers support the Java/J2EE domain. Many of the entities correspond to file assets. The following file types are supported:

• HTML and XML files

• JSP files and JSP tag libraries

• Java sources

• Java class files (bytecode)

• J2EE archive files:

  • EAR

  • WAR

  • EJBJAR

  • J2EE Client

Besides entities that directly refer to files, analyzers can take an inventory of the following types of entities:

• Physical entities, like sites and containers

• Servlets, EJBs (Session or Entity), Java packages, methods, and fields

• WebSphere Application Server 4.0 AE runtime entities, such as:

  • Cell

  • Node

  • Application Server

  • ServerGroup

  • Clone

  • VirtualHost

  • JDBC Driver

  • DataSource

  • JMS Provider

  • JMS Connection Factory

  • JMS Destination

  • Mail Session

  • URL Provider

  • J2C Resource Adaptors

  • J2C Connection Factory

  • Deployed J2EE applications

  • Deployed Web Applications

  • Deployed EJB JARs and EJBs

• Entities that are explicitly defined by the user

Metadata and dependencies among assets

One of the main features of the analyzers lies in the comprehensive set of relationships between Java/J2EE entities. Distributed analyzers can detect the following three types of links:

1. Containment links, such as between archive files and the individual files, or between a Java class and its methods and fields.

2. Hierarchy links:

   • These are defined separately for Java sources and for Java bytecodes.

3. References:

   • At the level of Java sources, the analyzers detect class-to-class referencing and hierarchy information.

   • At the level of Java bytecodes, the analyzers extend this level of class-to-class referencing and provide a higher granularity through method-to-method, method-to-field and method-to-class referencing.

   • J2EE referencing; the analyzers discover a rich set of J2EE references between HTML/XML files, JSPs, Servlets and EJBs.

   • Connections to middleware and legacy such as via JMS or JCA.

In WSAA V3.1, WSAA can scan a WebSphere Application Server 4.0 Advanced Edition runtime environment. It takes an inventory of the WebSphere Application Server resources and analyzes them. The resulting information is a topology of the WebSphere Application Server environment that includes the cell and its nodes, resources (such as JDBCDriver), and the EARs installed in it.

The WebSphere Application Server 4.0 AE scanner calculates which EJBJars and WARs are installed on which clone/application server and which clone is installed on which node. Each EAR that is installed in the cell is analyzed to its inner resources (for example, War and EJBJar). The WebSphere Application Server 4.0 AE scanner runs the Java pattern detector and the J2EE inference engine (see Appendix A, “Key features” on page 179) for more information) on a WebSphere Application Server cell.

At the end of this process, you can explore and understand the whole topology and application structure.

One of the main features of the tool lies in the comprehensive set of relationships between Java/J2EE entities. We distinguish between three types of links:

• Containment links, for example, between archive files and the individual files, or between a Java class and its methods and fields

• Hierarchy links:

These are defined separately for Java sources and for Java bytecodes.

• References:

  • At the level of Java sources, we provide class to class referencing and hierarchy information.

  • At the level of Java bytecodes, the tool extends this level of class-to-class referencing, and provides a lower granularity through method-to-method, method-to-field and method-to-class referencing.

  • J2EE referencing

  The tool discovers a rich set of J2EE references between HTML/XML files, JSPs, Servlets and EJBs.

  • Connectors to middleware and legacy code

---