Managing and Monitoring Web Services in Project GlassFish

Print-friendly Version

[Part 1] [Part 2] [Part 3]

With the monitoring level set at HIGH, you can display the messages for a Web-service endpoint point by clicking the Messages tab of the Monitor page. Each message details the SOAP request, the response time, the status, and the HTTP header. You can also configure the number of messages that are kept in memory, which is 25 by default. Application Server retains in memory the messages for each server instance.

Figure 6 is an example of two messages for HelloImpl.

Figure 6: Example of Messages on a Web-Service Endpoint

To view additional details, click a message in the Messages page. Figure 7 is an example of the details that are then displayed.

Figure 7: Example of Details on a SOAP Request and the Response Status

In the case of an error in invoking a Web service, the response and status data often provide helpful clues. Click View Request XML to display the details in XML format.

Also, if you adopt message-level security, the decrypted content is displayed. Be sure to keep that data private.

This AMX code segment searches for all the Web services with QueryMgr.

try {
        final Set s = dr.getQueryMgr().queryJ2EETypeSet(J2EETypes.WEB_SERVICE);

	final Iterator iter = s.iterator();
	while ( iter.hasNext() ) {
	    final WebServiceEndpoint wsp = (WebServiceEndpoint)iter.next();
	    Map[] msgs = wsp.getMessagesInHistory();
	    if ( msgs == null) {
	        System.out.println(" No messages found");
		continue;
	    }

	    System.out.println(" Collected messages " + msgs.length);
	    for ( int idx =0; idx < msgs.length; idx++) {
	        MessageTraceImpl msg = 
		    new com.sun.appserv.management.ext.wsmgmt.MessageTraceImpl((Map)msgs[idx],
		    MessageTrace.CLASS_NAME);
		System.out.println(" message id " + msg.getMessageID());
		System.out.println(" application id " + msg.getApplicationID());
		System.out.println(" endpoint name " + msg.getEndpointName());
		System.out.println(" response size " + msg.getResponseSize());
		System.out.println(" request size " + msg.getRequestSize());
		...
	    }
	}
} catch(Exception e) {
    throw e;
}
(From WebServiceRuntimeTest.java)

For each endpoint, the getMessagesInHistory method locates and prints the details of the message trace.

An Application Server capability, Fast Infoset, specifies a binary format for XML infosets that typically improves performance by two to four times. As soon as you turn on Fast Infoset encoding, the message-trace content adopts that binary format. The client controls the content negotiation in Fast Infoset by means of the standard HTTP headers Accept and Content-Type. For a request received by a Fast Infosetenabled service, the reply is accordingly encoded in Fast Infoset.

For details on how to use Fast Infoset, see the pertinent section in its documentation. In addition, a technical article, Fast Infoset, shines a light on the concepts of the specification and other nuances.

With the Call Flow capability, you can track the processing time of a request in each of the major Application Server containers, such as the Web, EJB, Java DataBase Connectivity (JDBC), and Object Request Broker (ORB) containers. A Call Flow agent saves that information to a database, which you can then analyze at interception (trap) points to debug performance problems. For example, the flow data often reveal if a request is spending most of its time in a particular container or the backend database.

Call Flow is off by default. To turn that on for a running instance from the Administration Console, do the following:

1. Click Application Server, followed by the Monitor tab, and then click Call Flow Config in the bottom row of tabs.
   
   
2. Select the check box, Enabled, and then click Save.
   
   Afterwards, click Call Flow under Actions (see Figure 6) for a display of the callflow data.

Simply click Call Flow in the bottom row of tabs for the collected Call Flow data. See Figure 8 for an example of the data.

Figure 8: Example of Call Flow Data

To view the details of the Call Flow, click View Tree. The Administration Console then displays the stored trace data. Application Server EE 9 goes a step further and shows a pie chart that illustrates the distribution of the time the request has spent on each of the components.

To focus on certain requests so as to optimize performance, you can filter the data to reflect certain specifics only, for example, the host and user IDs, by specifying the filtering criteria in the Call Flow Configuration page.

When filtering is enabled, Application Server generates Call Flow data for only those requests that match the criteria. Afterwards, you can inject requests into a running system—specifically to generate trace information. You can then watch your requests flow through the system and evaluate the performance of specific types of requests in the context of normal load, bypassing requests from other sources.

For a fine-grained control of Web-service request and responses, apply eXtensible Stylesheet Language Transformation (XSLT) rules to each of the Web-service endpoints. For example, on New Year's Day, you may want to greet readers with Happy New Year! instead of Hello Duke! How to do that? Rather than revising the application, you can apply an XSLT rule on the response, as shown in this XSLT file:

<?xml version="1.0" ?>
  <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:ns1="http://server/">
    <xsl:template match="/">
  <xsl:text>
    <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns1="http://server/"><soapenv:Body><ns1:sayHelloResponse><return>Happy New Year!</return></
ns1:sayHelloResponse></soapenv:Body></soapenv:Envelope>
  </xsl:text>
    </xsl:template>
</xsl:stylesheet>

This file is identical to the content of the SOAP response"with only one exception: the Hello Duke! string now reads Happy New Year! For other ways to achieve the same result, see Part IV, Using XSLT in the tutorial Working with XML.

Next, add the XSLT file on the CLI. Type:

asadmin create-transformation-rule -webservicename
server_HelloImpl#HelloImpl --applyto response --rulefilelocation happyNewYear.xsl

In this command, the --applyto response parameter applies the XSLT file to the SOAP response. Similarly, you can add a transformation rule to the request to modify the content of the incoming message before its dispatch to the server runtime.

Figure 9 shows the Transformation Rules page for HelloImpl.

Figure 9: Examples of Transformation Rules

Feel free to disable or enable these rules any time. Also, you can apply multiple XSLT rules to the same method in a Web-service endpoint. Application Server applies the rules according to the order in which they are added and stores the XSLT files in the generated/xml directory of the server repository.

Application Server EE 9 synchronizes the transformation rules to the remote server instances.

Now test with either the test form or a client application. To test with the latter, do the following:

1. Invoke HelloImpl with this sample code:
   
   

   package client; import javax.xml.ws.WebServiceRef; import server.HelloImplService; import server.HelloImpl; public class Client { @WebServiceRef(wsdlLocation="http://localhost:8080/HelloImpl/HelloImplService?WSDL") static HelloImplService service; public static void main(String[] args) { Client client = new Client(); client.doTest(args); } public void doTest(String[] args) { try { HelloImpl port = service.getHelloImplPort(); String ret = port.sayHello("Duke !"); if(ret.indexOf("Duke") == -1) { System.out.println("Unexpected greeting " + ret); return; } System.out.println(ret); } catch(Exception e) { e.printStackTrace(); } } }

    
   
2. Create a directory for the client. Type:
   

   mkdir $AS_HOME/client
   

3. Copy the client source file, Client.java, to $AS_HOME/client.
   
   
4. Generate the required client-side artifacts from the WSDL. Type:
   

   $AS_HOME/bin/wsimport -d client "http://localhost:8080/HelloImpl/HelloImplService?WSDL"
   

   For details on wsimport, see its documentation.
   
   
5. Compile the client. Type:
   

   javac -cp .:client:$AS_HOME/lib/javaee.jar client/Client.java
   

6. Set up the environment variable APPCPATH. Type:
   

   setenv APPCPATH .:$AS_HOME/client
   

7. Run the client. Type:
   

   bin/appclient client.Client
   

If the output reads Happy New Year! instead of Hello Duke!, you're all set.

Be sure to evaluate the pros and cons for adding transformation rules and for revising the application. Applying XSLT can mean a longer processing time for the Web services. In other cases, the XSLT way makes sense, as when a Web service is exposed to partners with different dialects and potentially different security requirements. In that case, transformation rules can act as proxies for the Web service and would be a big plus.

[Part 1] [Part 2] [Part 3]