Ever wondered how to debug web services?
Debugging web services has been misconstrued by the folks, atleast the people I have been talking to. It is a normal practice to just debug the back end of the WS, example the EJB or an helper class that makes a call to the DB, and claim that the WS is debugged. This, apparantly, doesnot debug the actual service. I decided to come up with a check list for debugging the WS and here it is:
1. The primary stuff, the WSDL should be accessible from the browser
2. Validate request and response bodies against their schema definitions
3. Validate the definitions for WS-I (Web service interoperability) compliance.
The second and third points are of concern. I had been using the TcpMon, that is shipped with Apache Axis so far to see the SOAP messages. This would require "tunneling". Hmmm.. something non-intrusive would be better. I had been looking for some nice tools that does the true debugging of WS. Here is a list of tools and their descriptions:
1. WSUnit - Unit Testing a WS
2. WebService Studio - Invoking the WS, it a .NET program. Given the endpoint, generates the proxies and invokes the methods
3. SOAPUI - A very nice tool with all the required features. It doesn;t limit to just debugging, but provides features to load test and functional test the WS. Really cool!
I installed the SOAPUI and the experience is very good. I strongly recommend it to all folks using WS and wondering how to debug.
Sunday, July 16, 2006
Monday, July 10, 2006
CLOB issues in weblogic
I noticed a strange behavior with CLOB in weblogic. The CLOBs would work fine with the main method, but when the same code is run on Weblogic, it throws an "No more data to read from socket" exception. The interesting aspect is, the row in the table gets inserted perfectly including the CLOB column.
The first thing I suspected is with the driver version of the ojdbc.jar shipped with WLS, but that wasn't the problem as the driver I used in the application is same as the one shipped with WLS.
Since, the infrastructure appeared fine, I decided to debug and track the root cause. Debugging the problem brought out some intriguing points. The hack is to create the CLOB column with the default as EMPTY_CLOB() and do a post process after the insertion. The sequence would be:
1. insert some dummy string first cs.setString(4," ");
2. Excecute the proc
3. post process the clob
Clob clob = null;
pstmt = conn.prepareStatement("SELECT clob_col from clob_tbl where id=? FOR UPDATE");
pstmt.setString(1,id);
rs = pstmt.executeQuery();
if(rs.next()) {
clob = rs.getClob(1);
Writer writer = ((OracleThinClob)clob).getCharacterOutputStream();
writer.write(msg);
writer.close();
}
st = conn.prepareStatement("UPDATE clob_tbl set clob_col=? where id=?");
st.setClob(1,clob);
st.setString(2,msgId);
st.executeUpdate();
That is all to be done. Though, there is an additional step in the flow of control, this solution is clean. Whew! some solace.
The first thing I suspected is with the driver version of the ojdbc.jar shipped with WLS, but that wasn't the problem as the driver I used in the application is same as the one shipped with WLS.
Since, the infrastructure appeared fine, I decided to debug and track the root cause. Debugging the problem brought out some intriguing points. The hack is to create the CLOB column with the default as EMPTY_CLOB() and do a post process after the insertion. The sequence would be:
1. insert some dummy string first cs.setString(4," ");
2. Excecute the proc
3. post process the clob
Clob clob = null;
pstmt = conn.prepareStatement("SELECT clob_col from clob_tbl where id=? FOR UPDATE");
pstmt.setString(1,id);
rs = pstmt.executeQuery();
if(rs.next()) {
clob = rs.getClob(1);
Writer writer = ((OracleThinClob)clob).getCharacterOutputStream();
writer.write(msg);
writer.close();
}
st = conn.prepareStatement("UPDATE clob_tbl set clob_col=? where id=?");
st.setClob(1,clob);
st.setString(2,msgId);
st.executeUpdate();
That is all to be done. Though, there is an additional step in the flow of control, this solution is clean. Whew! some solace.
Tuesday, July 04, 2006
Script Debugger
Well, it has been a while since I coded something on the presentation layer. Infact, I had a very long term association with the Servlets, JSPs, and Struts and sort of bored with the web-db-web routines. The middleware is bit challenging and adventurous. Got some time yesterday, so explored the updates on the presentation layer including JSF. A friend pointed to a script debugger. This was really a cool tool that would literally eliminate the alert() in the javascript code. Progress!
If you'd like to try it out, the link to the tool is
Script Debugger. What more, it is from the Microsoft.
If you'd like to try it out, the link to the tool is
Script Debugger. What more, it is from the Microsoft.
Subscribe to:
Posts (Atom)