So, now that you've got the marketing overview of iControl all figured out, the next question you are likely to have is regarding how iControl works from a technical perspective.  This article will attempt to illustrate the various components of an iControl application.

Before we go any further, I'm going to describe all the technical terms that I'll be using so hopefully when you read further in the article, you understand what I'm talking about.

  • API (Application Programming Interface) - basically a way for one application to talk to another.
  • XML (eXtensible Markup Language) - A text based format with a bunch of less-than, greater-than symbols and text along with a bunch of rules on how they are formatted.
  • SOAP (Simple Object Access Protocol) - is an XML based messaging system most commonly run over the HTTP or HTTPs protocols.
  • Web Services - A Web 2.0 buzzword for a set of SOAP based services.
  • WSDL (Web Service Definition Language) - A XML file format specification that allows for one to fully describe the format of their SOAP methods including requests, responses, parameters, return values, and other transport layer settings.
  • SOAP Toolit - A language dependent set of libraries uses to create and interpret SOAP responses to/from native code.  Some examples are SOAP::Lite for perl, Apache Axis for Java, and the .NET Framework for VB and C#.

So what is iControl?

Some say iControl is an API, some say it's a set of web services, some say it's a frameworks, and even some say it's everything including the kitchen sink.  Well, most of these are correct.  At it's core, iControl consists of a client application (something you would write) and a server component (something we provide on our devices).  On the client side, iControl is distrubuted to the users in the form of a SDK that includes API documentation on the methods as well as a set of WSDL documents describing the services.  On the server side, iControl is a feature on the F5 devices that process the client requests.



The Client Application:

To build a client application, one would look at their development environment and determine which language is best suited for their application.  One could use Perl or PowerShell for a console based application, C# or VB for Windows, Java for web server applications, etc.  Of course most of these languages will work in most of these examples, so it's really up to the user to determine which is best for their needs.

Once the language decision is made, and the associated toolkit is installed and configured, it's time to start implementing the client code.  This can be either done automatically by the tools that support clientside proxy generation from the iControl WSDL files (.NET, Axis, ...) or manually with the ones that are more dynamic in nature (Perl, Ruby, Python, ...).  In this article, I will focus on the languages with native support for WSDL.  In .NET applications, you would use the "wsdl.exe" command line tool to parse the WSDL document and create a set of C# or VB client proxy code that you can use within your programs.  In Java, the WSDL2Java tool included with Apache Axis will accomplish the same goals.  One could go through this effort if one wanted to, but the smart kids out there are all making use of the iControl Assembly for .NET and Java that have been produced by F5.  If you go this route, all you have to do is plug the iControl.dll (or iControl.jar for java) into your project and you are ready to start writing code.  The initialization of the client proxy library is configured with the address of the F5 device, port 443 for the HTTPs connection, the URI of the iControl Portal process (/iControl/iControlPortal.cgi) and the user credentials.  The authentication mechanism is the same that is used for the Management GUI: HTTP Authenticate headers encrypted over SSL.  At this point, one can start making iControl management calls with the generated proxy client code.

The Server Components:

The second part of the iControl communication channel is the server side web services.  These are implemented in a "Portal" process that runs under that administrative management port on the F5 devices.  This Portal, listens for incoming secure and encrypted iControl calls, parses the incoming XML-based SOAP Message into native code, performs the relevant internal operations, and then generates and returns a XML-based SOAP Response to the client application.

Conclusion:

iControl means a lot o things to a lot of people, but ultimately it's about allowing automated remote management of F5 devices.  As a user, all you need to worry about is the client components.  Get the WSDL (or better yet, the iControl assemblies), plug them into your client application, initialize the connection information, and start building your app.

Get the Flash Player to see this player.