Glue Code
Glue Code is the executable code most often the source code that serves the purpose of adapting different parts of code that would otherwise be incompatible. Glue code does not contribute any functionality towards meeting any program requirements as such. Instead, it often appears in code that lets the existing libraries or programs to interoperate among themselves, as in language bindings or foreign function interfaces. Glue code may be written in the same language as the code it is gluing together, or in a separate glue language. Glue code is very efficient in rapid prototyping environments where several components are quickly put together into a single language or framework.
JavaScriptTestRunner
Jason Huggins while testing an internal application at ThoughtWorks reduced the time which was required to manually step through the same tests with every change he made developing a Javascript library that could drive the interactions with the webpage which allowed him to automatically rerun tests against multiple browsers. He named this program as the JavaScriptTestRunner. Later, he made JavaScriptTestRunner open source. This library eventually became Selenium Core which underlies all the functionality of Selenium Remote Control (RC) and Selenium IDE.
Unfortunately, to work within the Same Origin Policy, Selenium Core must be placed in the same origin as the Application Under Test (AUT). So another ThoughtWork engineer, Paul Hammant, created a server that would act as an HTTP proxy masking the AUT under a fictional URL, embedding Selenium Core and the set of tests and delivering them as if they were coming from the same origin. This system became known as the Selenium Remote Control (Selenium RC), or Selenium 1.
Why to use HTTP proxy
Again, when web frameworks were becoming more complex and powerful, the restrictions of Web Browsers’ sandboxed Javascript environment were increasingly limiting the effectiveness of Selenium Core. Simon wanted a testing tool that spoke directly to the browser using the "native" method for the browser and operating system, thus avoiding the restrictions of a sandboxed Javascript environment. That was when WebDriver and Selenium RC were merged to form Selenium 2. All implementations of WebDriver that communicate with web browsers started using a common wire protocol. This wire protocol defined the RESTful web service using JSON over HTTP.
Conclusion
In short, the functionality to control the browser was always within the Javascript library that driven the interactions with the webpage which was part of the JavaScriptTestRunner and later Selenium Core.
As per the diagram below with respect to the different classes/interfaces the functionality to control the browser is with the selenium-api
