Key features

 < Day Day Up > 



The impact analysis process has to detect dependency relations between the software components involved. Some of these dependencies are easy to discover, such as when one component invokes a method of another component or when component relations are defined in a deployment descriptor. Other dependencies are more complicated and less direct. In addition to detecting dependencies directly, WSAA searches for a sequence of calls (that is, patterns) in the module's code and infers additional indirect dependencies.

Java pattern detector

In J2EE, for example, modules communicate through their containers. When one EJB wants to access another EJB, it invokes the lookup method on a javax.naming.Context object. If the lookup invocation is found (assuming that the EJB name that is associated with that JNDI name can be resolved), it can be inferred that these two EJBs are communicating and that there is a dependency between them.

In the above simple example, the pattern to be found is a single instruction (the lookup invocation). In other situations, the code pattern is more complex, involving a sequence of method invocations. In fact, to more correctly identify an EJB lookup, it is better to also look for an RMI narrow invocation following the lookup invocation, since a lookup can be for any type of resource (such as DataSource) and not just an EJB.

The WSAA Java pattern detector can find patterns in java bytecode based on static analysis. WSAA can detect the following patterns:

  • JNDI lookup for EJBs and resources - Context.lookup(String...)

  • Servlet redirect - RequestDispatcher.forward(String....) and RequestDispatcher.include(String...)

  • CICS access through CICS Transaction Gateway - InteractionSpec.setFunctionName(String), CICSManagedConnectionFactory.setServerName(String), CICSManagedConnectionFactory.setConnectionUrl(String)

  • MQ Queue access - MQQueueManager.accessQueue(String)

  • JMS access through a sequence of calls:

    • A JMS queue connection is created - createQueueConnection()

    • A JMS queue session is created - createQueueSession(boolean, int)

    • A JMS queue is created - createQueue (java.lang.String)

    • A JMS receiver is created - createReceiver(javax.jms.Queue)

    • A JMS sender is created - createSender(javax.jms.Queue)

Detecting and exploring J2EE relationships

The J2EE/Web application is typically composed of a large variety of development resources (for example HTML, JSP, Servlet, Java Bean, EJB) which often access legacy code and EIS systems. One of the major strengths of the WSAA is in the exploration of dependencies between all of these resources, thus giving an end-to-end understanding of all related tiers (for example, HTML->JSP->EJB->Database).

Even at the level of Java code, the tool goes beyond the low granularity relationships among raw constructs (such as package, class, method), and detects a wide variety of patterns in the Java code that can be mapped into meaningful relationships between J2EE components (for example, forwarding between Servlets).

Activating the Java pattern detector

The Java pattern detector and the J2EE inference engine can analyze applications in the runtime, development, and assembled environments. The Java pattern detector and the J2EE inference engine can analyze a WebSphere Application Server 4.0 Advanced Edition runtime environment.

In a development environment, the Java pattern detector can analyze Java class files that are still under development. The runtime configuration (for example, class path, class loading) of the classes needs to be provided via an XML configuration file to fill in the missing information.

The Java pattern detector can find patterns in assets located in any environment that WSAA can scan (for example, file systems, CMVC, ClearCase).

For J2EE assembled applications, the Java pattern detector can analyze J2EE EAR files that have been assembled but not yet deployed into a WebSphere application server. The runtime configuration of the application server needs to be provided via an XML configuration file to fill in the missing environment information (such as class path).

Connector detection

WSAA supports middleware and legacy connector detection. Though J2EE defines a standard mechanism for identifying most of these connection types in deployment descriptors, the access is usually declared at the archive level with the target usually being a middleware connector. This level does not refer to the low-level code artifact that is actually doing the access, nor does it give information on the particular middleware target.

WSAA employs pattern detection to identify EIS resource accesses from within the code and attempts to identify actual values used in the code, such as the JMS Queue and EIS transaction names.

These middleware accesses are detected through various techniques such as specific API sequence usages (defined in rules files) along with data and control flow analysis on the deployed Java code. This information is combined with information in the WebSphere runtime environment such as JNDI bindings to provide a more complete picture of what external resources the J2EE application artifacts depend on. This could help answer questions in the future of what J2EE components (for example servlets, EJBs) need to be changed if you were to change the structure of the database or the parameters of an EIS transaction.

The types of connections that WSAA V3 will detect are anything that has a JNDI binding (for example, DataSource, J2EE Connector Architecture connectors such as CICS and IMS, JMS queues) as well as non-JCA connectors such as CICS CTG and MQ.



 < Day Day Up > 



IBM Redbooks - Websphere Studio Asset Analyzer
Adobe InDesign CS2 @work: Projects You Can Use on the Job
ISBN: 067232802X
EAN: 2147483647
Year: 2004
Pages: 84

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net