iControl interfaces were designed with maximum usefulness and portability in mind. Highly granular routines that are purpose-built for controlling your BIG-IP, utilizing a communications mechanism that is industry standard to make them useful to more than just a few developers who happen to use the right language.

In that the libraries are highly successful. We support many languages, and more are being added all the time, and you have a much finer grain of control that you would with most libraries of this type.

But with fine-grained control comes overhead. To split logical processes into their constituent parts adds calls to extra routines - to set up communications, maintain context, etc. We found after many iControl projects that there were certain things we were doing over and over that rarely changed - like setting up communications prior to making an iControl call. Generally speaking you set up communications, make a call, and then make several more. In modularized softare, you set communications, make a call, then set them up again and make another call - because the routine you're calling cannot make assumptions about existing lines of communication.

This type of thinking was the birth of the Java Wrappers. The current version is in its infancy compared to the maturity and richness of the iControl API, but knowing this would be the case when we designed it, we left the ability to call directly into the API from within the Java Wrappers project intact. Thus, unless and until the Wrappers do indeed wrap all possible functionality of the API, you still have access to the underlying interfaces. Meanwhile, all the busy work introduced by the web services communications layer and some of the iControl-specific work (like creating arrays for parameters to methods that most often you only want to send a single element to) are taken care of for you.

Less code for you, more functionality packed into each line. That was the goal. The Wrappers were never intended to replace the iControl API - some people don't want the additional overhead, and some will be doing things that are better suited direct to the API - but if you need a quick solution to a problem, they're there to help. As time goes on we will expand their coverage and give you more options to utilize them.

In short, the design is that you create a local Java object to represent the iControl/Apache Axis interface, and call the local object. It proxies your calls to the BIG-IP you've configured that object to communicate with. This means that you can have four objects, each communicating with a different BIG-IP, all running in the same code. Easy to handle, easy to keep track of what you were doing, and if you inherit from them, easy enough to fill in any functionality you wish was there but we haven't implemented yet.

Our code analysis shows that you need 1/7th the lines of code to complete a task with the Wrappers compared to direct with the API. Most of this is parameter setup and communications link establishment... Things that you often do exactly the same over and over. Some of the Wrapper functionality is aimed at giving you easier to use methods, and some of the functionality simplifies what is complex due to our design choices (which were not bad ones, but everything is a trade-off. If one thing is made easier, chances are some other thing was made harder. The Wrappers try to handle the "harder" part for you so that you can worry about what you need to get done.

Just another weapon in the locker, take it out if you need it, and don't hesitate to let us know what you'd like to see in it in future releases, since we're pretty much always working on it.