APIs and Frameworks
Strategic APIs and Frameworks are being identified by IBM to assist application developers in producing portable applications that take advantage of existing and new technologies. These APIs and Frameworks are supported by development tools, such as VisualAge C++ and VisualAge.
Our objective is to make it easy for you to determine how to make use of a service in your application. Today, you need to know what components and libraries are installed on the target system IBM platforms (for example, OS/2 and AIX) are being developed so that the APIs for middleware and application enabling are delivered on The Developer Connection for OS/2, AIX, and LAN Systems. Further, applications that use the APIs will execute on OS/2 and other platforms because support of the function is provided as part of the "base" product (A "base" product is the network-enabled version of OS/2 or other similar packages of function that customers buy to meet their application needs.) From the application's perspective, each API call is successful because the system contains the libraries to execute the call or route it to the driver or component that handles it.
Criteria for APIs and Frameworks
Procedural APIs are chosen based on their availability on multiple platforms and their openness or usage popularity. Not all APIs are members of the strategic set; rather, APIs that are of particular interest to solution developers are identified. Since many developers produce products for Windows platforms, the set of functions must address the need for common APIs between Windows and OS/2. The APIs must be suitable for developing desktop and client-based applications as well as server applications.
Object-oriented APIs are also chosen for their cross-platform characteristics Some driving forces behind the standardization of the technology are the ANSI C++ standard, ANSI Smalltalk, and the Object Management Group. From these come object representations of functions needed to build applications. Class libraries that provide support for writing desktop applications significantly improve productivity and portability. The further evolution of these class libraries into frameworks, such as found in Smalltalk and Taligent's CommonPoint, provide complete environments with an increased amount of code reuse.
The selection criteria for procedural APIs and object-oriented (OO) interfaces, class libraries, and frameworks are influenced by both de facto and de jure standards and by the popularity of the API to the solution providers. When predicting future usage, especially in the OO arena, the influence of the Object Management Group (OMG) and other standards and the existence of technology on multiple platforms carry the most weight. The steady movement of development towards object - oriented methods will probably limit the demand for new procedural APIs.
Function and APIs
The APIs listed in this article are examples of what we think application developers use to access or use the service listed. In some cases, a standards group or consortia is still working on the API definition. Some APIs have an object-based definition; some are already used in OO programming. Many APIs are described in documents on The Developer Connection for OS/2 and LAN Systems CD-ROMs (especially look at the API Roadmap section).
I have included this list to see what you think of it. Are these the functions you need? Do you use (or even recognize) the APIs? Let me know via e-mail or letter at the address listed at the end of this article.
In upcoming issues of The Developer Connection News, we will elaborate on APIs that will be available. The Developer Connection will be the way that you will get documentation, SDKs, header files, and other information you need to use them. Some of it exists already.
The basic categorization is taken from the IBM Open Blueprint. The function provided by the APIs can be used on both clients and servers.
- Application Services
- Mail - Message Reliant
- Common Messaging Call API Version 2*1
- Mail - Mail Aware
- Simple CMC, simple MAPI
- Telephony API - TAPI,
versit Telephony Services API - TSAPI*
- Calendar and Scheduling
- Calendaring and Scheduling API - CSA22
- LAKES A33 (used by IBM's Person to Person product)
- Workflow API4*
- Transaction Manager
- Presentation Services
- Compound Document
- OpenDoc API
- Presentation Manager, X-Windows
- :Multimedia PM - MMPM/2
- 3D Graphics
- Data Access Services
- Open Data Base Connectivity - ODBC, and SQL Access Group's SQL Call Level Interface
- Communication Services
- Remote Procedure Call
- DCE RPC
- Common Programming Interface - conversation
- Message Queuing
- Message Queuing Interface - MQI
- Berkeley Sockets
- Distribution Services
- Authentication - Generalized Security Service API
Registry - DCE Registry
Access Control - DCE Access Control
Audit - DCE Audit
- X/Open Federated Naming, Extended Naming Context
- Systems Management Services
- Configuration, Installation, Distribution
- CID Enablement
- License Server API
- Desktop Management Interface
- C and C++ Programming
- XPG4 compliant library
- IBM Open Class Library (for example, Presentation Framework, User Interface, Compound Document Framework, Relational Data Access)
- Object Enablement
- Object Broker
- System Object Model - SOM
- Object Services
- OMG Common Object Services Spec (that is, Naming, Security, Transaction Services, Event Services, Life-cycle, Licensing Framework, Object Externalization Service)
- Common Messaging Call Version 2 is in the approval stage Workflow API and TSAPI are in the definition stage The content of IBM Open Class Library will be enlarged to include frameworks
In the same way as programming languages provide a way to write an application and deliver it on multiple platforms, common APIs and Frameworks aid application development. The specifics of implementation can be hidden from the developer and applications can become more portable.
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation