|
Advanced
Application Programming Interface (API) is an older technology that
facilitates exchanging messages or data between two or more different software
applications. API is the virtual interface between two interworking software
functions, such as a word processor and a spreadsheet. This technology has
been expanded from simple subroutine calls to include features that provide
for
interoperability and system
modifiability in support of
the requirement for
data sharing between multiple applications. An API is the
software that is used to support system-level
integration of multiple
commercial-off-the-shelf (COTS) software products or newly-developed software
into existing or new applications. APIs are also a type of
Middleware that provide for
data sharing across different platforms; this is an important feature when
developing new or upgrading existing distributed systems. This technology is a
way to achieve the total cross-platform consistency that is a goal of
open systems (see COTS and Open Systems-An
Overview) and standards
[Krechmer 92].
An API is a set of rules for writing function or subroutine calls that access
functions in a library. Programs that use these rules or functions in their
API calls can communicate with any others that use the API, regardless of the
others' specifics
[Hines 96]. APIs work with a wide spectrum of application dialogues (i.e., interprogram communication schemes) to facilitate information exchange. These include database access, client/server, peer-to-peer, real-time, event-driven, store and forward, and transaction processing. APIs combine error recovery, data translation, security, queuing, and naming with an easy-to-learn interface that comprises simple but powerful actions/commands (verbs). To invoke an API, a program calls a SEND-type function, specifying parameters for destination name, pointers to the data, and return confirmation options. The API takes the data and does all the communications-specific work transparent to the application.
There are four types of APIs that are enablers of data sharing between different software applications on single or distributed platforms:
Using RPCs, programs communicate via procedures (or tasks) that act on shared data buffers. SQL is a non-procedural data access language that allows data sharing between applications by access into a common database. File transfer allows for data sharing by sending formatted files between applications. Message delivery provides data sharing by direct interprogram communications via small formatted messages between loosely- or tightly-coupled applications. Current standards that apply to APIs include the ANSI standard SQL API. There are ongoing efforts to define standards for the other types.
APIs can be developed for all computing platforms and operating systems or
purchased for most platforms and operating systems. All four API types can be
used both on homogeneous and multi-platform applications. However, because of
the added complexity required to share data across multiple platforms, RPC,
SQL or file transfer APIs are better used to facilitate communication between
different applications on homogenous platform systems. These APIs communicate
data in different formats (e.g., shared data buffers, database structures, and
file constructs). Each data format requires different
network commands and parameters to communicate the data properly and can cause many different types of errors. Therefore, in addition to the knowledge required to perform the data sharing tasks, these types of APIs must account for hundreds of network parameters and hundreds of possible error conditions that each application must understand if it is to deliver robust interprogram communications. A message delivery API, in contrast, will offer a smaller subset of commands, network parameters, and error conditions because this API deals with only one format (messages). Because of this reduced complexity, message delivery APIs are a better choice when applications require data sharing across multiple platforms.
Many examples of data sharing between different applications have been successfully implemented:
- Covia Technologies, in early 1983, supplied the Communication Integrator
(CI), which was the enabler technology for the Apollo airline reservation
system used by a consortium of United, British Air, Lufthansa, and other
international airlines
[King 95].
- DECMessageQ is part of the DECnet infrastructure and has been available since the early 1980s.
- Creative Systems Interface's (CSI) Application to Application Interface (AAI) is a full featured API that is suitable for both client-server and peer-to-peer applications.
- Horizon Strategies' Message Express was initially developed for LU6.2 (IBM generic System Network Architecture protocol) host and VAX/VMS communications. In a typical Message Express manufacturing application, remote plants with VAX, DOS/VSE, and AS/400 machines conduct work-order scheduling and inventory assessments via peer-to-peer messaging.
APIs may "exist" in many forms; the potential user should comprehend the implications of each. APIs may be
- a bundled part of commercial software packages
- separately-licensed COTS software package(s) (license costs)
- uniquely-developed by a project using the internal capabilities/features of the applications that must communicate
In the last case, which should generally be the exception, the development staff will incur analysis and engineering costs to understand the internal features of the software applications, in addition to the cost to develop and maintain the unique API. In all cases, there are training costs associated with learning how to use the APIs as part of the development and maintenance activity. Additional costs are associated with developing and using APIs to communicate across multiple platforms. As already described, network communications add complexity to the development or use of the APIs. The kinds of costs associated with network applications include additional programming costs, training costs, and licenses for each platform.
APIs can be used in conjunction with the Common Object Request Broker Architecture, Component Object Model (COM), DCOM, and Related
Capabilities, Distributed
Computing Environment, Two
Tier Software Architectures, and Three Tier Software Architectures.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
Name of technology
|
Application Programming Interface
|
|
Application category
|
Application Program Interfaces (AP.2.7)
|
|
Quality measures category
|
Maintainability (QM.3.1)
Interoperability (QM.4.1)
|
| Computing reviews category |
Distributed Systems (C.2.4)
Software Engineering Tools and Techniques (D.2.2)
Database Management Languages (H.2.3) |
|
[Bernstein 96]
|
Bernstein, Philip A. "Middleware: A Model for Distributed Services."
Communications of the ACM 39, 2 (February 1996): 86-97.
|
|
[Hines 96]
|
Hines, John R. "Software Engineering." IEEE Spectrum (January 1996):
60-64.
|
|
[King 95]
|
King, Steven S. "Message Delivery APIs: The Message is the Medium." Data
Communications 21, 6 (April 1995): 85-90.
|
|
[Krechmer 92]
|
Krechmer, K. "Interface APIs for Wide Area Networks." Business
Communications Review 22, 11 (November 1992): 72-4.
|
Mike Bray, Lockheed-Martin Ground Systems
(michael.w.bray@den.mmc.com)
Paul Clements, SEI
John Kereschen, Lockheed Martin Command and Control Systems
10 Jan 97 (original)
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/api_body.html
Last Modified: 11 January 2007
|
