Not for document/literal web services yet
As mentioned in the about document, this library is initially geared towards making it easier to call RPC/encoded or RPC/literal web services using SOAP over HTTP. Specifically, I've had lots of problems trying to get it to work smoothly with document/literal web services, which are also commonly seen (if you don't know what the difference is, read this article). I'd like to add that functionality, but it's not there yet. Also, don't try to use SMTP as a transport or do any calls to "messaging" web services -- that won't work either.
Thread [un]safety
No attempt has been made to make this code thread-safe, so be careful if you're sharing an object across threads. Add your own synchronization where necessary.
For numeric parameters, use Integer, not int
When you're passing numbers as parameters using callSimpleMethod
, make sure you use classes instead of primitives. For example, do not do this:
Object obj = sh.callSimpleMethod("methodName", 1);
Instead, make the call like this:
Object obj = sh.callSimpleMethod("methodName", new Integer(1));
Same for Doubles and Floats, obviously.
Use dumpMethodList() and setDebugOut() for troubleshooting
If you can connect to a web service but you're having issues with the formats of the calls or responses that are being generated, your best bet for troubleshooting is to call the dumpMethodList
method to figure out what the SoapHelper class thinks it's looking at, and then use setDebugOut(System.err)
to see if anything jumps out at you. And look at the sample code for inspiration.
Dealing with "untyped" responses (common with Microsoft web services)
A common error is when a web service returns an "untyped" response, where the information in the response envelope looks like this:
...<Result>This is the result</Result>...
instead of:
...<Result xsi:type="xsd:string">This is the result</Result>...
Because of this, our SOAP client won't know how to "deserialize" the response, so you'll get a SoapException like:
"No Deserializer found to deserialize a 'Result'"
See the InteropEchoString sample for an example of how to use the addReturnDatatype
method to deal with this situation.
Username/password authentication
While there is functionality to specify username/password pairs for both proxy server authentication and web service authentication, this will probably not work in all cases. There are a few different ways that proxy servers deal with logging in, and right now this code is only addressing one of those ways. Also, while "basic" authentication to a web service should work, session-based authentication probably will not. There is no support for any of the flavors of "standard" web service security that are out there either.
Calls over HTTPS connections
Calls over SSL/HTTPS connections should work, as long as you have Java Secure Socket Extension (jsse) installed and configured properly. While this is included in Java 1.4 and higher, please note that you sometimes have to set up the server's SSL certificates on your client ahead of time for this to work properly.
Storing method information for efficiency
The way this library works is it grabs the WSDL file you give to it, parses it into a bunch of MethodInfo
objects, and then references the methods it finds with any methods you try to call to determine URI's, namespaces, parameters, etc. In a production environment, you probably don't want to read and parse the WSDL file every single time you make a call, because that's pretty inefficient. There are at least two things you can do to help:
MethodInfo
objects somewhere (they are Serializable) and use them each time you want to make a callI'm sure there are other good things you can do too, but those are the first things that come to mind.