Testing Web Services

[Angela Truce]

Hi,

I have been testing my web services remotely on my machine and I was wondering how I could test it over the internet from home or over a network with traffic?

Thanks in advance.

[Masoud Kalali]

when you deploy your web application on some remote host you will have an IP address to your host/web application or your domain name will be the root for you web application.

indeed testing web services on your own computer or in your network have no differences with testing your eb services on internet except that you will use your domain name instead of your localhost ort , and you will just have some traffic in the network which may cause some delay.

i hope i understand your question correctly , let me know if you intend something else with your question

[Angela Truce]

Hi,

Is putting 2 home computers connected to a router the same as a LAN network? I want to know how to set up the network in order to test the web service. I understand that you just change the address of the server to where the machine is.

Would I need to install Tomcat on the server computer to make it work? I am currently using Tomcat 5.5 and Apache Axis 1.4. My web service is being tested for speed and I need the traffic from the network to give more realistic results if I were to use it say on the internet.



Thanks.
[ August 16, 2006: Message edited by: Angela Truce ]

[Watsh Rajneesh]

To load test your webservice a free tool you can use is TestMaker. In order to have the service running on one host and the client on another in your home environment, you can get a switch/hub and connect it to the DSL/Cable modem on the frontplane and your test machines can be connected to the switch's backplane (which will typically have more than 2 rj45 slots to connect your network cables to). You will also need to assign an IP address either manually (a virtual ip like 192.168.1.x) or a dhcp one to both your test machines.

If you want to host your sevice on the internet you will need a real ip host for hosting your webservice. The client can then run from any host with real/virtual ip (ie from behind your organizations/isp's firewall).

[Angela Truce]

Hi,

i have found a web site called xmethods.com which allows you upload your web services. I was trying to upload a wsdl file but I realise I will need to change some parts of it for it to work on the internet. I have 2 wsdl files for the same service, one i have written and deployed, the other i copied from the axis localhost in browser.

Could someone indicate what I should change in my wsdl file and which wsdl file to use?


thanks.
[ August 18, 2006: Message edited by: Angela Truce ]

[Watsh Rajneesh]

The xmethods.org/com/net only provides you the facility to register/publish your webservice which is not the same as uploading a webservice. When you register a service at xmethod you basically identify your service with a name and provide the url for its wsdl so that if another user can access use your wsdl file to access your service (hosted at some other location on the internet - on a host with a real ip). If this registry is a UDDIv2 registry, then it will allow you to associate multiple services against your organizations name. A uddi v3 registry is available here. But thats not what you want, right?

[Angela Truce]

nope...hmmm...is there any way of testing a web service other than remotely to give more realistic speeds?

thanks.

[Watsh Rajneesh]

If you want to simulate delay/loss at the receiver then you can do so by writing message handler at the service end. In the handleResponse() for receiver side message handler, you can introduce some delay by sleeping the handler for sometime at random intervals or simply throw a JAXRPCException causing a faultcode=soap:Server to be returned to the client.
On the server side a JAXRPC Exception always results in a SOAP fault being generated and sent back to the client (assuming Request/Response messaging). The SOAP fault message has a fault code of "soap:Server" to indicate that the problem is not related to the SOAP message itself, that it results from some server-side error.
Also to simulate the condition when the arrived soap message at the receiver end is corrupt you can throw a SOAPFaultException at random intervals in your handleRequest() method of the message handler on server side. A SOAPFaultException can be thrown only by the handleRequest() methods of a handler chain on the server side, when a message handler encounters a problem with the SOAP message itself. This will result in a SOAP fault of faultcode=soap:Client.

So message handler can be used to simulate
- a faulty soap message arriving at the receiver and
- a delayed response received at the sender.

To read about how to work with message handlers read this and this.

Also you may be interested in reading this which talks about how to make the webservice's idempotent and then implement sender retries in case when a soap fault is received from the receiver.

[Angela Truce]

Sounds a bit all too confusing! I don't know if I am using Jax-RPC, I think I am using SAAJ?

My web service is based on 2 types, the first one is a general call up method where the server is basically a .java file renamed as a .jws file dropped into Tomcat, where the parameters are passed to the server using something like this:

 responseArray = (String[]) call.invoke( new Object[] {strArray} );   

the other uses a MIME multipart based on the Axis SwA sample in the samples folder. The SOAP message and attachment is in an envelope that is sent as a multipart to the server and server sends the modified multipart content back.

I was hoping for a simpler solution like imitating delay using 2 computers hooked up via a router. But I know that this isn't really like a large network as the computers are technically directly connected to each other.
Is there message handling methods for SAAJ?

thanks again, I am new to this and it's very difficult to get my head round all the web service jargon.

[Watsh Rajneesh]

The javax.xml.rpc.Call interface is a part of the JAX-RPC API. So you are already using JAX-RPC and not SAAJ. If you were to use SAAJ alone to send out a soap message from the client/sender then you will use SOAPConnection class in javax.xml.soap package.

When you process the headers in the message handler's handleXXX() methods, you have to use SAAJ itself, as seen in the code snippet below. But the GenericHandler class or Handler interface are from the JAX-RPC API. If you are using Axis 1.2, then JAX-RPC API will be available as Axis 1.2 implements the JAX-RPC 1.1 spec.

 
import javax.xml.rpc.handler.*;
import javax.xml.rpc.handler.soap.*;
 
public class MyHandler extends javax.xml.rpc.handler.GenericHandler{
public boolean handleRequest(MessageContext context){
   SOAPMessageContext soapCntxt = (SOAPMessageContext)context;
   SOAPMessage message = soapCntxt.getMessage();
   SOAPHeader header = message.getSOAPPart().getEnvelope().getHeader();
   Iterator allHeaders = header.getChildElements();
   ...
}

The MessageContext object is passed to your handler's handleXXX() methods. This can be used to access the SOAPMessage and thence the SOAPPart and SOAPEnvelope, SOAPHeader etc. These classes are from javax.xml.soap package (SAAJ API).

As you will know that message handlers are typically used to process headers in the soap message. But we want to use the handlers at the receiver to simulate a delay and loss of soap response.

The message handlers are associated with a particular header in the wsdd configuration file. So your outgoing soap message from sender will need to have a soap header element.

[Angela Truce]

thanks, I will give that article a go and let you know if i stumble again.