Application Programming Interface

From Hill2dot0
(Redirected from API)
Jump to: navigation, search
Application Programming Interface

The converged application environment, by definition, brings programs together to do work. Where programs come together there must be a defined interface by which the programs talk to one another. This is what is known as the Application Programming Interface (API).

The role of the API is critical. An operating system has an API that applications running under that operating system use to request such things as memory allocation, access to devices (e.g., the mouse, the display), and access to storage (e.g., hard disks, CD drives). When Sony introduced the PlayStation 2, it made its API available only to licensed developers. This meant that only those who paid Sony could create games compatible with the PlayStation API. Sony’s perspective was that it was making and selling the PlayStation at a loss, so it needed to make up the loss and make a profit on the games. Sony did that by creating some of its own, but also by harvesting license fees from the developers. The PlayStation 2 API was both closed and proprietary.

Microsoft, on the other hand, published the API for the MS Windows operating system for anyone to access and use. Its perspective was that the more applications that were written for MS Windows, the more people would buy computers with the Windows OS and the more copies it would sell. Once MS Windows was deeply embedded, Microsoft would be in an excellent position to begin leveraging its own applications, and driving the software market. Microsoft’s API was proprietary but open.

In the distributed, converged application environment, closed APIs are essentially useless. It becomes almost impossible to broadly interwork applications when the APIs are unknown. Open APIs that are proprietary are better, but again they introduce significant limits. As soon as an attempt is made to interwork different application environments, the proprietary nature of the APIs, and the existence of multiple APIs, becomes an obstacle.

Standards-based API are, by definition, open. They are commonly agreed upon, so they cut across multiple application environments and companies. They are the ideal kind of API to be used in building distributed service-oriented application environments.

APIs in the Real World

The reality of APIs today is messy. There is more and more movement away from closed, proprietary APIs, and that is the good news. There is also more and more of a tendency for major companies to begin working together or to participate in public forums to create APIs that are more broadly accepted in the industry. The Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) is a good example of this kind of API. The Distributed Component Object Model (DCOM) has something of this flavor, although it is primarily championed by Microsoft.

Sun Microsystems (the originator of Java) and IBM have worked together to create APIs associated with Java. The Java Database Connector (JBDC) was created to interconnect Web-based applications with database systems. The Java 2 Enterprise Edition (J2EE) Connector Architecture (JCA) expanded on that concept to include forging connections with legacy application environments as well.

Today, all eyes are on the Web Services world and the Web Services Description Language (WSDL). WSDL is an XML-based API for describing services and specifying how access to the services is provided. It could be thought of as a metaAPI, making it possible to forge connections between applications with very different API structures.

The reality today, however, is that APIs tend to be all over the map. Each service and software provider define one for their service, and each tends to think they do it best. A converged application might need to interwork with multiple different APIs. Applications that have no exposed APIs whatsoever create a unique challenge in that they offer virtually no way to interwork with them. Those with exposed APIs do not necessarily consistently implement the API, and there is no universal authority for defining and policing them. The market rules.

Finally, new APIs are constantly emerging. For example, a new API was released by the Eclipse Foundation, and lauded by IBM. It is based on the VoiceXML language and will speed interworking of VoiceXML applications (primarily voice recognition systems) for a variety of devices.