[jboss-user] [JBoss Web Services] - Re: Effective way of forming a WebService client

Rohit Macherla do-not-reply at jboss.com
Wed Sep 15 06:22:02 EDT 2010

Rohit Macherla [http://community.jboss.org/people/rohit.macherla] created the discussion

"Re: Effective way of forming a WebService client"

To view the discussion, visit: http://community.jboss.org/message/561523#561523

Thanks Alessio Soldano.

If I may follow it up with another question, is there any way that we can cache the WSDL, since each invocation of getPort (...)  (via the JAX-WS JBossWS-Native) involves a full parse of the WSDL ? Whats happening in this case is : Many invocations of the client WebService. As it involves invoking another WebService, each of the getPort(...) calls resulted in :
1. connecting to the target WSDL location: This can be verified as the WSDL parsing fails when the target host is down. What I mean is, there is no need to connect to the target host and then download the WSDL, if we know that its not gonna change. When I say "WSDL parsing fails", I mean that there are no WSDL parsing statements in the DEBUG log and Exception is thrown before such parsing happens.

2. full parse of WSDL: I find the full WSDL printed in the DEBUG log. Probably this is followed by a conversion of XML to Java artefacts, but this is unnecessary time taking operation (in my view) since the target WSDL is the same anyway.

Additionally, I find many open file descriptors accessing the WSDL in the server/<configuration>/data/wsdl/TargetWS/TargetWS001.wsdl (i.e., the WSDL created when I deploy the TargetWS. Though this seems contradictory to the point 1 listed above).

Message was edited by: Rohit Macherla

Reply to this message by going to Community

Start a new discussion in JBoss Web Services at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100915/567dd4a4/attachment.html 

More information about the jboss-user mailing list