According to Wikipedia, late binding is a mechanism in which the method being called upon an object is looked up by name at runtime. This mechanism was useful in Microsoft’s Component Object Model (COM), because compilers wouldn’t have to reference libraries at compile time. Late binding is related to dynamic dispatch, which is the process of selecting which implementation of a polymorphic operation (method or function) to call at runtime.
The rise of Web Services in the early 2000s extended the definition of late binding. In the original vision for Web Services, Service consumers would look up the WSDL file for a desired Service in a UDDI registry, and bind to the resulting Service at runtime based upon the particular WSDL and the instructions the consumer would find inside it.
Only such “dynamic discovery” proved impractical in most situations, and furthermore, UDDI as a standard proved awkward and fundamentally useless. Instead, late binding in the SOA context represented a dynamic lookup of the endpoint location of a Web Service, where the WSDL file was already available for developers when they created or configured the consumer.
While this maturation of Web Services followed a convoluted path, REST cut through the noise with a more direct approach. Dynamic lookups follow the pattern of DNS, where a gateway intermediary can resolve one URI into another. We all know how DNS works, so why complicate matters?
Simply finding the desired Service or resource endpoint, however, is only the price of admission. Even with REST we still have the problem of ensuring the client and resource agree on other metadata associated with the distributed interaction. Such metadata may include data schemas, policies, or richer semantic content related to the interaction. REST addresses this problem via hypermedia: the client and resource interact via repeated following of hyperlinks on the client. Done properly, hypermedia drive the application on the client – but most RESTafarians can’t get this to work, and furthermore, hypermedia don’t address the broader enterprise integration challenge where the client is an arbitrary piece of software and the application isn’t ensconced in the client.
Cut to 2014. We’ve traveled the SOA gauntlet, and we’ve leveraged some aspects of REST (although maybe not the hypermedia bits). Today the story is the API Economy. But what are APIs but static interfaces? Even with the addition of contract metadata (having learned the lessons of Web Services), we still have the late binding challenge: how do two arbitrary endpoints understand all the metadata relevant to their interaction?
We need what I like to call extreme late binding: the ability for distributed computing endpoints to negotiate their interaction at runtime by leveraging all the metadata that apply to that interaction. Without such extreme late binding, even today’s modern APIs are just as inflexible and static as the fixed, early bound APIs of old.
