iControl WSDL versions

Hi Andy,

 

 

Yes, use the ones on your BIG-IP. Different releases have minor changes and enhancements to the interface. As you observed, most things are the same, but the differences will trip you up if you try to use a routine that has changed.

 

 

Which two files are you getting the errors on? Perhaps we can help you get them set straight.

 

 

Don.

It's dying on these files:

 

 

LocalLB.ProfileTCP.wsdl

 

 

 Sets the states that if true, delay sending data < MSS in size unless all prior 
 data has been ACKed. This leads to less in-flight small-data, and less chance 
 for drops, but can have poor effects for interactive protocols such as telnet 
 over high latency links.
 
 

 

 

System.ConfigSync.wsdl

 

 

 Deletes the specified file from the device.  If the specified file
 doesn't exist, an exception will be raised.
 NOTE: File names containing the following characters will be 
 considered invalid: ` ~ \ : ; * ? " < > | &
 
 

 

 

It looks like special characters aren't being encoded properly in the description fields (specifically, "<" and ">", though I think "&" might be problematic too). Both files have a couple instances of this problem.

 

 

EDIT: Cause I'm a moron and used the wrong kind of tags for the code segments...

Looks like. I'd simply cut those parts out - assuming it's not 20 instances a file anyway. That gives you a quick-fix at least so you can keep working.

 

 

Don.

I just replaced all <, >, and & with the proper XML encoding in those two files. It seems to have fixed it.

Andy, you should be fine using the SDK versions of the WSDL on previous versions of the product. The only issue you will run into is if you try to use a method that was introduced later than your version. This will be easily determined during your testing as the method request would immediately return a SOAP Fault indicating an unfound method.

 

 

or better yet, I'd suggest you take a look at the iControl Java assembly located in the iControl Assembly Labs page. This fully encloses the client proxy code in a similar fashion to the .Net assembly. If you go this route, you will not need to worry about compiling up the WSDL and loading up custom SSL security providers. Take a look, I guarantee, you'll find it much easeir to use. This is based on the 9.4 SDK but as I said above, it will be fully backward compatible for the methods that are on your version.

 

 

-Joe

What kind of dependencies are there on the JAR file? It looks like it's output from Apache Axis, so I assume it depends on the Axis libs, but I'm not sure. If so, which version of Axis?

 

 

If I've already written a bunch of code against the WSDLs (using Axis's WSDL2Java) how hard will it be to drop in the JAR file? It looks like most of the class names are the same so I'm hoping it will be pretty trivial.

 

 

Thanks!

It is based on Apache Axis (v1.3) and all the stubs were created with WSDL2Java.

 

 

Using the iControl jar is relatively easy. All the interface and method names will be the same, but for the lib you will need to get to those interfaces from the iControl.Interface class. If you do look into replacing your work with the library, I'd be very interested in your feedback.

 

 

-Joe

It looks like we're moving to use Axis 2 for part of our application, and I'd rather not have to keep multiple versions around. I'm probably just going to stick with using the WSDLs. Oh well, thanks anyway!

Agreed that that would not much fun. I'll rebuild the assembly with Axis 2.0 and test it out. If it works then I'll package both versions up.

 

 

It's lame in my book that Axis is not compatible between v 1.3 and v2.0. Have you tested it out and verified this is the case?

 

 

-Joe

I'm actually using Axis 1.4 at the moment. I'm waiting for my coworker to finish adding Axis 2.0 to our main product's build before I migrate over.

 

 

From what he's been saying there are very significant differences between the two, so I assume there will be at least some compatibility problems. I don't have Axis 2 set up yet so I can't really verify it though.