Monday, February 18, 2008

How to debug SOAP on Mac with tcpdump

I’ve been using several tools to debug SOAP on Mac and Windows. I would like to share my experience in using some of the tools and show some examples.

So far I found four major categories of tools that are useful in debugging SOAP:
  1. Interface listeners such as tcpdump and others
  2. Proxy tools such as TCPMonitor
  3. Servlet filters
  4. Application server logging. For example, Weblogic has a special logging option that dumps SOAP requests and responses to the sever log.
All of these tools have their own advantages and disadvantages. In this article, I will describe the first type - an interface listener tool called tcpdump. I am planning to describe other three categories in the future posts.

The tcpdump is a tool that sniffs IP traffic and dumps it to a file or a standard output stream. It was originally developed by Van Jacobson, Craig Leres and Steven McCanne from the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. It is open source. The tcpdump documentation and source code is available at http://www.tcpdump.org/. The tcpdump has been ported to many platforms. The version for Mac comes with MacPorts ( http://www.macports.org/).

Here is an example of capturing SOAP traffic where the service is deployed on the local host:

$ sudo tcpdump -i lo0 -A -s 1024 -l 'dst host localhost and port 8080' | tee dump.log

I use sudo because tcpdump requires root privileges to run. In this example, the tcpdump listens to the loopback interface defined on my Mac as lo0 and pipes out the data to dump.log file. To see all available interfaces, run ifconfig or tcpdump with –D option.

The Web service I use in this example is deployed on an instance of Glassfish Open Source Application Server for J2EE 5 (https://glassfish.dev.java.net/). It has a couple of methods:


/**
* Coffee Shop service.
*
* @author mykola
*/
@WebService()
public class CoffeeShop {
@WebMethod
public String getName() {
return "CoffeeShop, Inc.";
}

@WebMethod
@WebResult(name="price")
public int placeOrder(
@WebParam(name="product")
String product) {
int price = -1;
if ("coffee".equalsIgnoreCase(product)) {
price = 2;
} else if ("cake".equalsIgnoreCase(product)) {
price = 5;
}
return price;
}
}


I created a client application and once I call getName() Web service method I’ve got these SOAP request and response in the dump.log file:


Request:



Response:


The tcpdump logs lots of data. For SOAP debugging, we are interested in the <S:Envelope> content and HTTP headers.

This is a quick and dirty way of getting raw SOAP on the wire. The advantage of this approach is that it is not intrusive, i.e. no special client or service configuration is required. It does not affect performance of the web service or the client. It logs every byte in the message, even control symbols, which could be a disadvantage in some cases. The tcpdump would be very hard to use for debugging SOAP over HTTPS. Also, this approach is hard to use in cases where automated SOAP validation is required. I use filters for that. This is a topic for a future post.

I hope this post was helpful. Please let me know if you have any questions or comments. Thank you for reading.


Friday, February 15, 2008

Deploying BlazeDS to Weblogic 10.0

The BlazeDS is a free and open source J2EE application that provides data services to Adobe Flex and AIR applications. I’ve deployed it to Weblogic 10.0 server. I thought somebody else would be interested to do the same. Here is how.

In case you need to install Weblogic 10.0, the developers copy is available for free at http://commerce.bea.com/products/weblogicplatform/weblogic_prod_fam.jsp.

I have it installed on my Windows XP at D:\bea10 folder.

I have created a new domain for my BlazeDS applications. It is easy to do, see http://edocs.bea.com/common/docs100/confgwiz/index.html for details.

In my case, the domain name is blazeds and it is located in D:\bea10\user_projects\domains\blazeds folder on my computer. The domain name and the folders names can be difference, I just mentioned them so it is easier to follow the examples..

Once the Weblogic server is installed and a domain is ready, the BlazeDS applications can be deployed.

A copy of BlazeDS is available at http://labs.adobe.com/technologies/blazeds/. I downloaded the latest version - blazeds_b1_020108.zip and unzipped it to D:\java\blazeds_b1_020108.

There are three WAR files provided in BlazeDS distribution: blazeds.war, ds-console.war, and samples.war. Copy them to autodeploy folder of your Weblogic domain. In my case it is D:\bea10\user_projects\domains\blazeds\autodeploy.

Start the Weblogic servert. If you run it on Windows, simply click on Start -> All Programms -> BEA Products -> User Projects –> blazeds (or your domain name) -> Start Admin Server.

If everything ok, the Weblogic server log window will appear on the desktop:


Now is a good time to verify that the BlazeDS applications were deployed successfully. It is easy to do by checking the status of the applications in the Weblogic Admin console and scanning the log files for errors.

My server is configured with HTTP port 7001. My Weblogic console URL is http://localhost:7001/console. The console application asks for the admin’s name and password. Just want to remind that they were specified during the domain configuration step. Once you logged in, select Deployments in the Domain Structures window. You should see these applications deployed

I also like to check the log files for errors. The BlazeDS log file is created in

D:\bea10\user_projects\domains\blazeds\servers\AdminServer\logs folder and it is called blazeds.log. I could not find any errors in the log, which is a good sign.

Now the BlazeDS is ready. Open examples URL: http://localhost:7001/samples/. You should see a page

The BlazeDS samples use the database that is provided in the BlazeDS distribution. To start the database, open a command prompt window, navigate to \blazeds_b1_020108\sampledb folder and run startdb.bat:

Now lets test drive the BlazeDS. Navigate to the BlazeDS Test Drive page

http://localhost:7001/samples/testdrive.htm and follow the sample instructions. All sample applications worked nicely in my case. I’ve got data via HTTPService, Web Services, Java Remoting mechanism just fine.


I verified blazeds.log and AdminServer.log files for errors and could not find any. Everything run just fine.

I hope you found this post helpful. Please submit any comments or questions. I will be glad to help.