security of the script

That is the implementation of the sample code which was designed to be isolated stand-alone examples of the use of some of our interfaces and methods. The goal wasn't to provide recommendations for building secure client applications. Obviously it is not recommended to include a username and password in clear text in any production code. Most generally passwords are encrypted and stored in a separate location (most likely a database) and retrieved and decrypted by the calling application before issuing the web service request. In the case of these sample applications it is also possible to remove the credentials from the command line arguments and then prompt for them afterwards and mask the password with asterisks.

 

 

-Joe

Thanks.

 

I think another way is using ssh authorized channel to bigip,just think it a unix box,and input bigpipe command line.

 

I found SOAP is too slow,much slower than using ssh.

I would concede that SOAP is probably slower than a point to point ssh connection. But, using a structured API like iControl provides many benefits over that of issuing "remote commands".

 

 

Backward/Forward Compability

 

The command line syntax for given action can (and does) change from release to release. When features are added (or removed) the command line arguments will change to accomodate that. We avoid this issue with iControl by adding new methods for features that act like property accessors. That is, different features generally have their own methods associated with them and are not tied into a single method that is subject to change.

 

 

Interpretation of Results

 

Just type bigpipe pool show on a large configuration and try to interpret the results from a script. Not only are states and statistic output from the command verbose, but tend to be refactored from release to release. iControl provides a structured way to interpret these results without worrying about which version of software that is installed on the device.

 

 

Application Integration

 

Issuing remote commands from a scripted command-line enviornment is fairly straight forward (on a UNIX system). But during application development I would argue that shelling out system commands and interpreting the results is not the optimial solution.

 

 

Performance

 

I will point out that SOAP over HTTP has it's inheirent performance bottlenecks. There are also issues with client SSL components of the HTTPs handshake that are especially costly (java's ssl random seed generation for one). But the majority of applications that customers are developing with iControl (a while back we were at over 500 in production) performance is not a major criteria. Whether a method executes in 10 ms. or 1 sec. is generally not a factor unless the number of calls needed in a polling cycle is extermely large (but we do have a solution for this in upcoming releases - keep posted for those).

 

 

It all boils down to your specific scenario. If all you need to do is enable a node, you don't have a SOAP toolkit on your client, and sub-second performance differences are critical, then a ssh/bigpipe solution may be right for you. But we believe that the majority of solutions can and do benefit from a structured development environment.

 

 

Thanks for your feedback and continue to post your ideas and thoughts about how iControl can be enhanced!

 

 

-Joe