Defense Information Systems Agency Center for Software Ada 95 Bindings Report DASW01-94-C-0054 Task Order T-S5-306 15 August 1995 Approved for Open Publication 1. INTRODUCTION TO Ada 95 BINDINGS 1.1 PURPOSE 1.2 ORGANIZATION OF THE PAPER 1.3 OBJECTIVES 1.4 AUDIENCE 2. CURRENT STATE OF Ada BINDINGS 2.0.1 Currently Available Ada 83 Bindings 2.0.2 Work in Progress on Ada 95 Bindings 2.0.3 Problems 3. FUTURE BINDINGS REQUIREMENTS 3.1 THE CURRENT SITUATION 3.1.1 Project Experiences 3.2 THE FRAMEWORK IN WHICH A BINDING EXISTS 3.2.1 Specification, Implementation, and Validation 3.2.2 Thick Bindings and Thin 3.3 NEAR-TERM BINDINGS (YEARS 1 & 2) 3.3.1 Criteria for Bindings to be Completed and Productized 3.3.2 Comments on Particular Bindings to be Completed and Productized 3.3.3 Criteria for Bindings Creation 3.3.4 Comments on Particular Bindings to be Created (1-2 Years) 3.4 MID- TO LONG-TERM BINDINGS (YEARS 3-5) 3.4.1 Bindings Requirements for PCs 3.4.1.1 PC Bindings Issues 3.4.2 Bindings Requirements for Workstations 3.4.3 Bindings Requirements for Distributed Systems 4. BINDINGS MANAGEMENT 4.1 PROFILES 4.2 VALIDATION TEST SUITES 4.3 TOOLS, DOCUMENTS & GUIDELINES 4.4 INVESTMENT OPPORTUNITIES APPENDIX A. AVAILABLE Ada 83 BINDINGS Table 1. Current Ada 95 Bindings Development Efforts Table 2. Bindings to be Completed and Productized (1-2 years) Table 3. Bindings to be Created (1-2 years) Table 4. Ada 95 Bindings for PCs (3-5 years) Table 5. Ada 95 Bindings for Workstations (3-5 years) Table 6. Ada 95 Bindings Requirements for Distributed Systems (3-5 years) Table A-1. Current Compiler Vendor Bindings Table A-2. Current Third Party Provided Bindings Table A-3. Current Freely Available Bindings A-3 1. INTRODUCTION TO Ada 95 BINDINGS 1.1 PURPOSE This paper provides a rationale for current and future investments in Ada language bindings that can increase the use of the revised Ada programming language (Ada 95) in both the government and commercial sectors. Information presented in this report was gathered and consolidated by the Institute for Defense Analyses (IDA), under the sponsorship of the Ada Joint Program Office (AJPO), and was based upon a number of sources of information - including surveys, selected project interviews, review of current trade literature, historical files maintained by the AJPO, informal input from working groups of the Association for Computing Machinery's Special Interest Group on Ada (ACM-SIGAda), and informal input from attendees at the 1995 Ada Dual-Use Conference hosted by the Defense Information Systems Agency (DISA). Since every major software system written in Ada uses one or more binding, the availability of Ada 95 bindings is critical to the success of the Ada language itself. Third-party development of bindings is critical in two areas. First, there is a need to develop, distribute, and maintain bindings for high demand environments, such as for distributed computing. The second area is the development of public-domain bindings to high-demand commercial, off-the-shelf (COTS) products used by Ada applications. The availability of such public-domain bindings for third-party reuse reduces the investment necessary for individual companies to upgrade and add to their own product lines. 1.2 ORGANIZATION OF THE PAPER This paper is divided into four sections. Section 1 discusses the current state of Ada bindings, including work in progress on Ada 95 bindings. Section 2 identifies future bindings requirements for the near term, defined as the next one to two years. Section 3 makes projections of the need for bindings to standards developed by standards groups (including consortium groups) three to five years in the future. Section 4 discusses key areas of bindings management. 1.3 OBJECTIVES The objectives of the Ada 95 Bindings Report are to: -facilitate the creation of an Ada programming environment that allows end-user Ada programmers to take advantage of existing software systems without constraints -outline a strategy to create a self-sufficient and self- perpetuating bindings marketplace. -address each major area where the current bindings situations can be improved. 1.4 AUDIENCE The intended audience of this report includes: -implementers of Ada compilers, tools, libraries, and bindings, -experienced Ada software engineers and applications developers,and -other software practitioners interested in the development of tools, libraries, and bindings that will improve Ada's competitiveness in the general software marketplace. 2. CURRENT STATE OF Ada BINDINGS While the DoD ensures that compilers conform to the Ada language standard, vendors are allowed the freedom to develop their own binding specifications. As a consequence, sets of bindings are often incompatible, because binding specifications and implementations often differ from vendor to vendor. In retrospect, development of multiple, incompatible binding specifications has caused portability problems. For some widely used commercial software products, there is no portable way to access them from the Ada language. During the development of the requirements for the revised Ada standard (Ada 95), the need to address the problem of uniformity among specifications became apparent. The DoD responded to this need in several ways. For example, the Ada 95 standard defines interfaces to other languages (i.e., C, COBOL, FORTRAN) as part of the language. Also, the DoD has sponsored the development of some high-use binding specifications and implementations (e.g., POSIX, SQL). Finally, the DoD is taking a more proactive approach to the development of bindings. This is an approach that relies on vendor-user partnerships to develop binding specifications and implementations - reflecting the fact that both the DoD and commercial application developers need bindings that provide easy access to COTS packages and platform services. 2.0.1 Currently Available Ada 83 Bindings There are eight compiler vendors who provide and maintain bindings as part of their product lines. The most common bindings are for X-Windows for Unix based platform services; also, two vendors providing bindings for the Microsoft Disk Operating System (MS-DOS) and embedded SQL bindings for the Database Language SQL. Third-party providers offer bindings to X-Windows for Unix-based platforms, for Microsoft Windows NT and for both embedded and module bindings to SQL. Both compiler vendors and third-party sources offer other bindings that anticipate consortium product standards for the 1990s. Bindings that are freely available are more diverse, but are often incomplete and incompatible with one another. Tables in Appendix A (pages A-1, A-2, and A-3) show the currently available Ada 83 bindings. Much of the information in these tables was adapted from the AJPO's Available Ada Bindings report - which includes both bindings that are available to the application developer and those used internally by the compiler. In this paper, however, care was taken to identify only those bindings that are available to the application developer. 2.0.2 Work in Progress on Ada 95 Bindings Some work is in progress to update Ada 83 bindings to Ada 95 to take advantage of object-oriented and real-time features available in the revised Ada standard. This in-progress work shown in Table 1; these efforts are primarily for PC and workstation platforms used by developers of end-user applications. Table 1. Current Ada 95 Bindings Development Efforts Binding to: Platform Funded By Flex LM Workstation Objective Interface Systems, Inc. Fresco Workstation Objective Interface Systems, Inc. ODBC 2.0 Workstation/PC Objective Interface Systems, Inc. Xlib Workstation/PC Objective Interface Systems, Inc. ASIS\x1195 Workstation/PC Rational; Thomson (Alsys)/AJPO IEEE 488 GPIB PC WPL Laboratories Inc. IEEE 1003.1g (protocol independent communication - sockets) Workstation/PC AJPO IEEE 1003.1b-1993 and 1003.1c-1994 (real-time extensions and threads) Workstation AJPO IEEE 1295.1 (Motif) draft Workstation AJPO Mail Application Programming Interface (MAPI) PC AJPO ODBC 2.0 PC AJPO OLE-2 PC AJPO Win32 PC AJPO Winsock PC AJPO OS2 Presentation Manager PC AJPO MACH kernel API Workstation AJPO DWARF API Workstation AJPO Persistent Object Base Workstation ARPA/AJPO Xt, Xlib (X11R6) Workstation AJPO Several of the application program interfaces (APIs) listed fall into more general categories for which they are more generally known. For example, Microsoft Windows NT is a collection of APIs that includes: Win32, Winsock, Object Linking and Embedding (OLE) 2.0, Open Data Base Connectivity (ODBC), Mail Application Programming Interface (MAPI), and other protocols. The bindings listed in Table 1 are the individual APIs that could be confirmed were being developed. The X-Window System is a collection of Xlib and Xt APIs. Where the specific APIs are known (e.g., Windows NT), they are cited in the tables that follow. Bindings that are intended to be freely available are shaded in the table entries. 2.0.3 Problems While there are successes in the bindings world, the following list of problems are recurring difficulties for Ada application development. -Errors in bindings are difficult to find because of the very nature of a binding and because of the required level of understanding of the application area, Ada interfacing techniques, the language being interfaced to, and the binary representations underlying each. -Bindings necessary for the development of an application in a particular domain are often not compatible. For example, some of the bindings require tasking, while others preclude it; a consistent application cannot be constructed. -Due to developers taking differing approaches to bindings, multiple incompatible binding specifications have been developed for some services defined under the DoD's Technical Architecture Framework for Information Management (TAFIM). These incompatible specifications arose from a demand-side pull for the needed bindings without proper standardization effort. The multiple X Window System bindings are an example. -Program managers and contracting officers have difficulty making enlightened decisions about Ada software systems from a perspective of bindings. The next section discusses requirements to address these problems. Figure 1. Bindings Framework as Related to Client-Server Architecture 3. FUTURE BINDINGS REQUIREMENTS During the next five years, bindings will be required in three areas: 1. application development on workstations configured as clients and servers; 2. the integration of COTS software on PCs for end-users who are not programmers to produce their own applications; and 3. applications running on high performance distributed configurations. To meet such requirements, some freely available bindings that lack uniformity or completeness should be standardized, productized, and maintained by a third party or compiler vendors as part of a product line. Bindings need maintenance support as a product if they are to be useful in multi-language applications of the future. As formal standards are revised and consortia standards evolve, bindings work will go on beyond the next five years. But efforts during these years should focus on an adoption strategy for bindings that will likely increase the Ada 95 user base. The 5-year strategy contemplated in this report is split into two phases: 1-2 years and 3-5 years. The focus during the 1-2 year time frame is on increasing the quality of existing bindings and the completeness of platform-related bindings. The quality of existing bindings is varied and unknown. In order not to lose the existing investment in bindings, these bindings should be updated and made useful. Many programmers become frustrated with bindings because they lack implementation of all interfaces to the underlying services the programmers expect to use. For example, with the exception of the Digital Equipment Corp.'s Ada 83 compiler, no vendor provides a complete set of Unix API bindings. This problem will affect Ada 95 adoption; to address it, sets of bindings (discussed in Sections 3.3 and 3.4) should be completed, and at least partially implemented. 3.1 THE CURRENT SITUATION To put requirements for future bindings in context, it may be useful to look at the bindings situation Ada developers currently face. This report synthesizes information on bindings and their effect on Ada adoption obtained from responses to an e-mail questionnaire, from reviews of the survey results, and from interviews with members of several projects that have been using Ada for many years on large systems. The most in-depth information came from the projects, and a discussion follows. However, while the specifics of the projects were recorded, several respondents expressed concern over the disclosure of information. To address this concern, the information recorded for this report is not attributed. 3.1.1 Project Experiences The projects: The contacts on each project were first line managers in charge of areas where significant bindings were used. A total of seven projects were contacted. Three of the projects used workstations as their target; two of the projects used PCs as their target; and two used embedded-systems hardware. Each of the projects could identify significant efforts with attendant schedule delays related to problems with bindings. However, none of the projects actually tracked the unexpected cost with respect to bindings problems. Bindings availability: For one of the projects, no needed bindings existed at the start of the project. (The project began in 1987.) For the other projects, where bindings did exist, the projects development team took over maintenance of the bindings in order to better control application development. Of the bindings adopted from the public domain, significant work was necessary before the bindings could be used by the application development teams. The most cited examples were with the Xlib and Xt bindings. The public domain versions of the Xlib and Xt bindings did not support the most current version of the X-Window protocols, nor was the binding complete for the version it did support. Of the bindings used, very few were bought from third parties. (Notable exceptions to this were bindings to database products and Motif.) The role of COTS: COTS software was used in each of the projects. Usually Ada was not used as the language for integration, since few of the products provided an Ada interface. Exceptions to this were databases on workstation platforms. (Ingres, Sybase, and Oracle all provide an Ada API to their products.) On the PC and VMS platforms, file formats were the method of integration. To control a tool, a program would read or write data using a file format that was processable by the tool. In one project on Unix platforms, the Tool Command Language Toolkit (TCL/Tk) was used to control integration. Other factors: One of the projects changed hardware and operating systems four years into development in order to conform with an open-systems requirement. (Proprietary products had originally been chosen because complete Ada bindings existed and were supported.) Many of the issues the project faced with open systems were related to available bindings. Problems arose in porting because of the poor quality of bindings in the new environment; lack of consistency of the X-Window System's bindings caused a major rewrite of the user-interface software. Also on this project, upgrades to the database products were required because of bug-fixes. The upgrades to the database products also included updated or improved bindings - which, in turn, caused considerable extra work to accommodate. The difficulty addressing upgrades was particularly acute on projects that used PCs. Many bindings were outdated within a few months after they are acquired. Since most of the proprietary interfaces (e.g., Microsoft Windows) are not controlled by a standards group or consortium committee, the interfaces were in a continual state of flux. This flux made upgrading vendor supplied products with every release impossible. (Often, releases of products were only 6 months apart.) Lastly, having performed significant bindings work, each project expressed concern over not knowing how to get the bindings work they have performed into the appropriate repositories and over not knowing where to look if they need bindings in the future. These project-related experiences may become past history when effort has been applied to make bindings complete and robust as described in the following section. 3.2 THE FRAMEWORK IN WHICH A BINDING EXISTS 3.2.1 Specification, Implementation, and Validation While the definition of a binding is often debated, for the purposes of this report, a binding is defined as an Ada means to interface to an underlying software system. The framework in which a binding exists can be separated into three areas: 1. Specification: the document describing the services that can be provided to another user or program. 2. Implementation: Ada source code that implements such specifications; and 3. Validation of such implementation as actually conforming to the specification. Specification: In order to facilitate the support of a common interface, the binding's specification should be freely available to the public. (An exception to having freely available specifications is when only a single vendor has a vested interest in bindings to a particular COTS product.) However, the specification should be standard as well as freely available. The current Ada bindings to the X-Window System are a good example of the problem here. There are approximately 10 different bindings specifications for Xlib, Xt, and Motif. Portability suffers heavily because of the different specifications. Moving an application between specifications causes a rewrite of the windowing application code. Since X-Windows is written in C, the C community does not suffer from this diversity. A standard X-Window interface is critical to eliminating this problem. Implementation: A binding's implementation can either be freely available or proprietary. The advantage of the freely available implementation is the likelihood of adoption by many compiler vendors of the same implementation. A proprietary implementation has the advantage of being supported by the owner of the implementation. Validation: At the same time a widely adopted binding specification is created, a common approach to validating the bindings should be considered. Included in the binding specification are semantics that cannot be represented in Ada code - such as the expected order of the calls to the binding, and the meaning of the values returned by the binding. A set of tests are needed to ensure that all the semantics are present in every implementation of the specification. Since the nature of the tests is to ensure compliance with a specification, the validation test method itself should be as available as the specification. 3.2.2 Thick Bindings and Thin The appropriate level of abstraction for the bindings specification needs to be considered. A thin binding specification is one that does not deviate from a one-to-one mapping of the underlying software system. A thick or abstract binding specification is one that introduces Ada language features and techniques that represent functionality inherent in the underlying software system. Often this type of binding is not a one-to-one mapping of the underlying software system's data structures and functions. The creation of a thick binding specification is more labor intensive than the creation of a thin binding specification. Several compiler vendors and third-party vendors use thin-binding generators to automatically create thin bindings. A thick binding cannot be created in the same manner. However, tools could support the extraction of design decisions from code in order to facilitate a thick binding specification. In order to support short-term binding needs, efforts should focus on the creation of thin binding specifications with implementations and some means of validation. These thin bindings will allow the immediate use of the underlying software system by Ada applications, and can be the starting basis for the implementation of thick bindings. The development of thin bindings in the near-term is supported by a number of reasons: 1. The timeliness of bindings is critical to the adoption of Ada on projects that are using new technology. Thick bindings, if they are not developed simultaneously as the API in question, are often two or three years behind the state-of-the-art. The POSIX bindings took approximately five years to develop (albeit, the time to develop was drawn-out some by changes in the underlying standard). 2. The development of a thick binding requires much experience with the use of the API in question, since the thick binding's purpose is to facilitate the correct use of the underlying software system using Ada language features (e.g., strong typing). 3. Thin bindings are easier to maintain, since they usually involve less coding than thick bindings. Most commercial products offer thin bindings. Their product line changes quickly, and the development of thick bindings is not justifiable. The problem associated with thin bindings is usually the lack of Ada features that ensure the correct use of the bindings. For example, many Xt bindings use System.Address to specify an X event callback. The binding assumes that the user application will pass in the address of a procedure that implements the callback. The binding also assumes that the procedure address passed will refer to a procedure that is neither dynamically allocated nor uses non-global data that is not allocated in the procedure itself. These assumptions make programming in Ada with these bindings not much better than programming in the native language (i.e., writing X programs in C rather than Ada). Thick bindings include the language features necessary to enforce proper use of the bindings. The proper use of a binding is difficult to define. The definition of proper use includes an understanding of how users commonly misuse interfaces and of why the developers of the underlying software system structured it in particular ways. In the near term, quickly developed thin bindings will allow the immediate use of the underlying software system by Ada applications and can be a starting point for the implementation of thick bindings. Work on thick binding specifications and implementations should be the long-term focus of the bindings efforts. The thick bindings should present to the Ada application programmer a package specification which would be the same as if the package body were implemented entirely in Ada (a pure Ada package). See Figure 1 for the bindings framework in the case of a client-server architecture. The two-level split in implementation (thick implementation based on thin specification and implementation) provides a measure of portability. As the underlying software system evolves, the thin binding is affected directly. Since thick bindings are not directly tied to the exact format of the underlying software system, there is some insulation from minor changes. In addition, the nature of thin a binding prevents general portability, since there are always small changes in the underlying software system to accommodate differences between host platforms (e.g., byte ordering, address bit size). Thick bindings lack most of these portability issues. In terms of general focus areas for bindings, there is a strong relationship of bindings to client-server computing when considering COTS products. A current trend in computing is to separate code into two parts: client and server. Often, the client code manages visual presentation and interaction with a user and executes on low-powered and less-expensive computers. The server manages the coordination and distribution of data to clients and other servers. 3.3 NEAR-TERM BINDINGS (YEARS 1 & 2) Most freely available bindings are incomplete but are useful for a prototype or proof-of-concept. (See Table A-3 for a list of bindings that are currently freely available.) Some of the bindings do not allow an application to access all the underlying functions and data structures. Many of the bindings have errors, memory leaks, or lack documentation. The usefulness of these bindings is not in question, but it is critically necessary to move them to Ada 95 and to production quality. Production quality for a binding includes: that it is qualified to work with all Ada features (e.g., inheritance, tasking); that it manages memory properly for the particular type of application; that it provides documentation on its use that does not require an expert in the binding's underlying language; that it has defined and passed test programs; that it does not conflict with other bindings over global resources; and that it uses a widely accepted or standardized specification. The near-term needs for bindings (i.e., over the next 2 years) should be met in two ways. First, existing bindings which are not getting used need to be updated, corrected, or completed. Second, new bindings need to be created in order to facilitate the adoption of Ada 95. The Unix and workstation market and the Microsoft PC market should be the focus of near-term efforts, since they are the most rapidly growing market share. 3.3.1 Criteria for Bindings to be Completed and Productized Table 2 lists bindings that are needed and can be completed and productized over the next 1-2 years. The criteria for including bindings in this list were: 1. The binding has been identified by a particular category of users as important for success of Ada in their marketplace. For example, the Distributed Interactive Simulation (DIS) protocol has become of increasing importance to simulators used in military construction, and in distributed inventory applications. (DIS is being used for all distributed simulators.) Without a strong Ada presence in the DIS community, the likelihood of Ada being adopted is weakened. 2. The binding specification already exists. 3. The binding itself is not complete, and lacks either an implementation, or validation test. Table 2. Bindings to be Completed and Productized (1-2 years) Binding To: Description Year IEEE 1003.1g Protocol Independent communications (sockets) - V 1 IEEE 1003.b-1993 and 1003.1c-1994 Real-time extensions and Threads - V 1 DCE Distributed Computing Environment - S, I, V 1 Paradox PC database - S, I 1 1533 Bus Avionics bus - V 1 IEEE 1295.1 draft OSF Motif - I, V 2 DIS Distributed Interactive Simulation - V 2 Legend: S=specification; V=validation; I=implementation The bindings in Table 2 have been identified as having no path toward productization because work on them is at a stand-still. Table 2 does not list existing freely available bindings that have been picked up by vendors (e.g., the Graphical Kernel System-GKS) or have had additional funding for Ada 95 work (e.g., Win32). 3.3.2 Comments on Particular Bindings to be Completed and Productized POSIX: In Table 2 there is a strong emphasis on completing and validating existing POSIX and distributed application interface bindings. The survey, and many of the project managers interviewed, indicated that the current availability of POSIX 1003.5 bindings is weak, and the POSIX 1003.5 is not sufficient to write non-OS dependent Ada code. Also, the existing POSIX 1003.5 bindings are poorly tested, which in turn is weakening the resolve of programs to use POSIX. For example, a current commercial POSIX bindings has an error in the read and write return values to the point that the bindings cannot be used in a production system without patches. The commercial vendor has not provided the patch, so the project members must patch the system themselves. Once the COTS product is modified, the new version requires documentation and testing, which tends to invalidate the reason a COTS bindings was chosen. Increasing the number of POSIX standards which have bindings and providing the vendors with a validation suite will help to correct these problems. Similar reasons exist for the other bindings listed in Table 2. DCE and DIS: The Distributed Computing Environment (DCE) and Distributed Interactive Simulation (DIS) currently have one or more implementations which should be finished and validated because of the importance to distributed systems and evolving specifications for distributed simulation applications. A binding effort is currently underway at the Army's Communications-Electronics command (CECOM) at Fort Monmouth, but no determination of the completeness of the binding has been made. Validation for this type of binding, much like the POSIX bindings, is critical to its wide acceptance and use. Similarly, the implementation for the 1553 bus needs a validation test suite. IEEE 1295.1: The Institute of Electrical and Electronics Engineers (IEEE) Motif standardization effort (IEEE 1295.1) has not yet produced a standard interface. However, work is continuing in the area. To avoid difficulties like those affecting the past Ada bindings for X-Window System APIs, an implementation and test suite for the Motif binding should follow quickly after the standard is produced (if not simultaneously). Paradox: Paradox is suggested in Table 2, because of its partial implementation and short-term need for quick business applications. The ODBC products emerging will obsolete the Paradox bindings so quickly that validation is not critical. It should be noted that Table 2 lists only bindings that complement a long-term strategy. For example, it does not list the Unix APIs have been produced, e.g., the Paradise bindings, because they are not focused on standards or evolving Unix APIs. (They could be used, however, to create the Unix bindings included in Table 3.) 3.3.3 Criteria for Bindings Creation The bindings in Table 2 are to be freely available and productized as complete and portable implementations. In the near term, however, other bindings need to be created, and still others need to be completed and/or updated to match the interface specification of the software object being bound. The bindings that need to be created or validated in the near term (1-2 years) are identified in Table 3. Table 3. Bindings to be Created (1-2 years) Binding To: Product Year IEEE 1003.1d (more POSIX real-time extensions) V 1 Existing WWW product Standard S, I, V 1 Sun/HP version of ODBC 2.0 I, V 1 IEEE 1003.1e (POSIX Security extensions) I, V 1 IEEE 1003.1f (POSIX Network extensions S, I, V 1 Simple Mail Transfer Protocol (SMTP) S, I, V 1 Portable Document Format (PDF) reader/writer S, I, V 1 Lotus 123 File format reader/writer S, I, V 1 dBase DBF reader/writer S, I, V 1 Window Meta File reader/writer S, I, V 1 Netware APIs S, I, V 1 Graphical Formats (GIF, TIFF, JPEG, etc.) reader/writer S, I, V 1 Common Operating System Environment (COSE) Spec 1170 S, I,. V 1 COSE Common Desktop Environment (CDE) S, I, V 1 High Level Architecture for Simulation S, I, V 1 SVR4 APIs S, I, V 1 VXI bus S, I, V 2 1553B bus S, I,V 2 OLE-COM V 2 ODBC 3.0 S, I, V 2 SQL 92 - three levels of conformity S 2 CDIF reader/writer S, I, V 2 System Object Model (SOM) S, I, V 2 Legend: S=specification; I=implementation; V=validation The criteria for choosing the bindings to be created are: 1. to cover interfaces that are supported by market leaders; 2. to cover interoperability interfaces; 3. to create a complete set of interfaces. A binding to one interfaces in a set of interfaces is undesirable, since users have no growth path into the set of interfaces. The strategy for improving the availability of quality bindings is to make them freely available in source-code form (e.g., on CD-ROM) so that compiler vendors can adopt a common binding and reduce their overall development time and effort. 3.3.4 Comments on Particular Bindings to be Created (1-2 Years) Unix/POSIX: Table 3 includes two POSIX standards that currently have no bindings efforts associated with them. Unix API have suffered from the lack of vendors providing POSIX-compliant operating systems. POSIX is often a subset of the operating system APIs that are provided. For instance, Solaris is based on Unix System V release 4 (SVR4), which is a collection of interfaces. The Common Operating System Environment (COSE) Spec 1170 combines features of POSIX 1003.1 and SVR4. A binding for Spec 1170 can be combined out of POSIX bindings and SVR4 bindings. There is some effort involved because the POSIX binding is a thick binding, which needs to be coordinated with the SVR4 bindings in order to be used to create a Spec 1170 binding. With bindings to POSIX, SVR4, and Spec 1170, bindings support will be complete for approximately 80 percent of the Unix operating-system APIs on the market. VXI: The VXI bus by National Instruments (an industry leader) currently has no binding effort associated with it. Several known projects that were using Ada switched to C because of a lack of a VXI binding. The VXI binding should be considered an interoperability interface for hardware devices and should have an Ada binding. Other busses with APIs that should have Ada 95 bindings are the military standard 1553B and IEEE-488. (The IEEE-488 is already in progress.) COSE: Since COSE represents a significant majority of the Unix marketplace, the interfaces that are being standardized should have Ada bindings to them. Much of the work in COSE is related to graphical interfaces and other means of using Unix, which are not specific to Unix operating systems. This implies that some of the COSE standards (e.g., Common Desktop Environment) are capable of transcending Unix, and being adopted by other operating systems. WWW: Another area of growth is the World Wide Web (WWW) with several APIs. Ada bindings to these APIs will allow Ada programmers to write applications in Ada for the WWW. Ada bindings for the WWW should be a priority because of the growth and visibility of this area. The introduction of the WWW standards and products has caused a revolution in the means by which information is stored on the Internet. The potential of this area has only begun to be explored. There are many APIs associated with the WWW, and already the WWW community has raised concerns as to reliability. For example, a recent Computer Emergency Response Team (CERT) announcement called out a security hole in a particular WWW server, which was related to C's lack of array-bounds checking. Ada would not have had this security problem. Considering the growth in this area and the need for more reliability as the Web is used for business transactions, Ada bindings to existing and new APIs will allow Ada programming to contribute significantly. Reader/writers: The PC market is more difficult to define and quantify. For the most part, formal standardization is absent, and there are only products which provide a well-defined means for interfacing. Most word processors can import and export a variety of different formats. Many integration efforts on the PC are structured around these different formats. While OLE and other Mircosoft product standards are changing the means of integration, the file format method of integration still dominates. For this reason, a suite of file format readers and writers would be highly desirable. Table 3 lists only the most common product standard file formats have been identified. Managers of projects hosted on a PC identified two dominant formats for databases and spreadsheet, i.e., dBase (.DBF) files and Lotus 1-2-3. While other formats would be useful, most tools can export their internal formats into these. Also, since most of the current databases support ODBC, the bindings to ODBC will allow those products to be integrated. SQL: While work continues on the SQL Ada Module Description Language (SAMeDL) for Ada 95, the majority of database interfaces do not use the SAMeDL approach. Moving the existing SQL bindings supported by database vendors to Ada 95 will ease the adoption of Ada 95 for database applications in the near term. Since most of the database vendors provide Ada products, this is an area where partnership could work successfully. CDIF: Since interoperability of CASE tools is a current trend in computing, support for reading and writing Case Data Interchange Format (CDIF) files should be supported. SMTP: Many applications are now being integrated over large geographical areas via electronic mail, indicating the desirability of an Ada binding for Simple Mail Transfer Protocol (SMTP). Also an Ada binding to MAPI (the PC mail API) is already being worked on (as noted in Table 1). ODBC: A new version of ODBC (version 3.0) is scheduled for release late in 1995 and should quickly have a binding to support multiple databases with a single binding. In addition, ODBC 2.0 has been ported to other than PC platforms, namely Solaris and HP. The existing bindings should be tested on Solaris and other platforms to which it has recently been ported. The strategy for improving the availability of quality bindings is to make them freely available in source code form (e.g. on CD-ROM) so that compiler vendors can adopt a common binding and reduce their overall development time and effort. 3.4 MID- TO LONG-TERM BINDINGS (YEARS 3-5) The bindings that should be available for PCs, workstations, and distributed computing configurations listed in this section do not repeat bindings that should be available during year 2 and in a steady maintenance state by year 3. The criteria for selecting bindings in the 3-5-year time frame is based on consortium trends toward object technology, tool integration, and the need for thick Ada bindings. 3.4.1 Bindings Requirements for PCs For the PC community there are three areas of interest in bindings: products and file formats, Microsoft Windows, and Taligent Common Point. The first area of interest is for immediate interfaces to popular commercial products, such as Lotus 1-2-3, and dBASE IV. Most of these interfaces are file-format layouts. Integration or interfacing with these products is done by writing and reading the format necessary for the tool; therefore, there is a need for readers-writers of these formats. These formats include: Lotus 1-2-3 files, dBASE (.DBF) files, Windows Meta files, and various graphic formats (GIF, TIFF, etc.). Using these formats, PC-integration shops can use prototypes developed using COTS products, interface with them via file formats, and extend the capability using Ada code. In addition, Ada reader-writers of these formats would be portable to many operating systems and therefore would increase interoperability between the PC and workstation markets. There is also a strong interest in using tools to create the application code that uses the Ada APIs. Providing a binding to the interfaces that can be used for and by application generators (4GLs) such as PowerBuilder and JAM would improve Ada's competitiveness with languages like C and C++. The file-format readers and writers are priorities for the near-term (1-2 years), since they are the current method for many types of integrations and interoperation. The trend for integration and interoperability is via the Object Linking and Embedding (OLE). Currently, OLE is replacing the Visual Basic Controls (VBX) in Microsoft's 32-bit operating systems, and will be the predominant means for providing language-independent components in a Microsoft environment. The OLE bindings currently being developed is part of a complete set of bindings for Windows-NT. OLE, however, should be separated out and tested for specific interoperability with the Component Object Model (COM), which is Mircosoft's component-interoperability specification. In addition, the validation of the binding should check that the DCE binding produce by other efforts is interoperable with the DCE remote procedure calls (RPCs) supported by COM. Since COM is an emerging standard, the 3-5-year timeframe is appropriate for full support. However, the current work on OLE should take into account that the end goal of OLE is COM. The System Object Model (SOM) and Distributed SOM (DSOM) are implementations of the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) that have gained acceptance by IBM, HP, and Apple Computer. The current CORBA implementation by OC Systems will support SOM on IBM platforms but will not support HP or Apple's version. The SOM and DSOM implementations of CORBA are important to support, since those implementations of CORBA are explicitly called out by the Component Integration Laboratories (CI Labs) for the consortia's OpenDoc standard. These CORBA implementations perform the same function as COM, there are several differences which indicate that both should be supported because Microsoft supports COM. Other large organizations support CORBA, SOM, and DSOM, there is already a practical case for Ada-binding support for both. Independent of support, however, there are several differences between COM and CORBA that indicate that Ada developers will benefit from bindings to both. The COM approach simplifies the construction of applications out of components by enforcing a binary standard, which limits COM applicability outside of Microsoft's environment. CORBA on the other hand allows application builders to use inheritance to construct applications. This requires that the source code of the objects support an inheritance model in the Interface Definition Language (IDL) compiler. Since there are drawbacks and advantages to each approach, both will probably be heavily used and modified in the 5 year period of this report. Also, because they will be heavily used, and are currently innovative approaches to software, many changes can be expected in the product standards. These changes should be tracked and the bindings updated as they occur. There are many APIs associated with Microsoft products. Most of the Windows NT APIs are being addressed by existing bindings efforts. However, two upcoming Microsoft product will probably have different APIs than NT. These are: Windows95 (a complete rewrite of the Windows operating system), which is planned for delivery in 1995; and Cairo (an object-oriented operating system), which is planned for 1996-97. In order to allow Ada a continuing role on the PC, all of these APIs must be addressed in a timely fashion. In addition, the networking software, e.g., NetWare, has APIs that need Ada bindings. The Taligent Common Point framework is the definition of an object oriented operating system that is analogous to the POSIX standards in diversity and completeness. Included in the framework are multimedia APIs, network communication APIs, distributed objects interfaces, etc. While this work shares some similarities with OMG's IDL, many extensions exist for operating system features (greater than 1000 APIs). While today it is still unclear whether Taligent will succeed with Common Point, it will be clear within two years. Deliveries of some of the product are planned for 1995. 3.4.1.1 PC Bindings Issues The PC market place presents additional challenges to bindings development. Most of the PC's APIs and file formats are not controlled by a standards organization, and are subject to change. While a thin binding for these APIs can be generated automatically, the generation of bindings validation tests cannot be. This lack of validation capability makes creating quality bindings problematic. For example, there are ambiguities in the Microsoft APIs that allow for many different choices in a thin binding. In addition, the large number of functions in the APIs increases the potential for problems. Without validation tests, it is difficult to determine the quality of the binding. Therefore, any planning for bindings in the PC market should include a method for addressing these issues. Because of the growing number of C++ class libraries, bindings to these classes is important for reuse. However, current C++ compiler use differing implementation strategies for inheritance and calling conventions - which makes creating an Ada binding to C++ problematic. The binding is a function of the particular Ada compiler, C++ compilers, and the libraries being bound. This is similar to the situation Ada faced in 1983 with respect to C libraries. Over the next five years implementation strategies for binding to these libraries will emerge. The current trend is through CORBA-like interfaces that avoid the inter-language issues. However, other more preferable and tighter integration methods should also arise. One possible implementation being explored by teams from Silicon Graphics, Inc., and the GNU Ada 95 Translator (GNAT) effort. Such integration methods should be studied and documented in order to develop a standard method to integrate to C++ libraries across many different Ada and C++ compilers. Table 4 shows mid-long term the bindings requirements for PCs. Table 4. Ada 95 Bindings for PCs (3-5 years) Binding to: Product Portable C++ class hierarch interface for PC Ada and C++ compilers S, I, V Thick bindings for Windows NT APIs S, I, V Microsoft Cairo S, I, V New OLE extensions S, I, V Distributed OLE S, I, V Windows 95 S, I, V New Microsoft APIs S, I, V COTS application builders S, I, V Talegent Common Point S, I, V New POSIX standards S, I, V Legend: S=specification; I=implementation; V=validation 3.4.2 Bindings Requirements for Workstations Table 5 lists the bindings and classes of bindings that should be created for workstations in the 3-5-year timeframe. Table 5. Ada\x1195 Bindings for Workstations (3-5 years) Binding To: Product COSE/OMG OpenStep S, I, V IEEE 1003.15 (POSIX supercomputer extensions) S, I, V New micro-kernel APIs S, I, V New COSE product standards S, I, V New POSIX standards S, I, V New OSF standard S, I, V Script-X multi-media interfaces S, I, V The bindings available for the workstation market have been very successful. For example, major windowing systems are fully supported and database vendors provide Ada interfaces with their products. Nevertheless, more bindings are necessary to compete with C and C++ languages. Commercial companies are moving to object oriented technology. Many large financial organization are investing heavily in distributed object technology such as OMG's CORBA. Much of the DoD's simulation work is also predicated on technology similar to CORBA being available. Recent submissions to OMG - such as Open Step (an object oriented application builder), OpenDoc, and repository services, require extensions to OMG's IDL. In fact, it is clear that IDL will be evolving heavily over time; keeping an Ada mapping up to date will require a focused effort. Current efforts on an IDL mapping to Ada 95 have been slow to complete. Since a mapping of IDL to Ada 95 can be used to provide many bindings, it is critical that the Ada 95 mapping be adopted by OMG, and that the mapping be maintained over time. 3.4.3 Bindings Requirements for Distributed Systems Distributed systems is a current trend in the software industry, both in Federal Government and in the commercial sector. Existing component industries trends are to use distributed object technology in both the definition and the use of software components. The bindings necessary to support these trends include support for the various groups developing standards in this area. The COSE environment currently defines remote messaging capability that is related to Sun's Tooltalk and HP's Message Object Services. More important in the 3-5-year period is to create bindings for the new and improved component standards that are produced. Besides normal standards organization, such as the IEEE and the International Standardization Organization (ISO), bindings should be considered to support the efforts of consortia such as COSE, OMG, and Open Systems Foundation (OSF). It is likely that consortia will produce commercially accepted distributed standards before the more formal standard organizations do so. The IEEE DIS standard group has expanded the use of DIS outside of the original intent, and it can now be considered a standard for communication of any federated group of complex systems. Advancements in distributed database technology, and distributed reuse repository services are expected - along with a growth in user demand for distributed applications that are loosely linked as federations of systems. For example, in DoD the demand for multi- language bindings in distributed computing environments will increase significantly as the benefits of cooperative simulations are demonstrated. Interface protocols will evolve to form sets of integrated specifications for bindings to Ada 95. Table 6. Ada 95 Bindings Requirements for Distributed Systems (3-5 years) Binding to: Product COSE tooltalk S, I, V COSE message object services S, I, V New OMG standards S, I, V New protocols for distributed simulation applications S, I, V New component interoperability Standards S, I, V Extensions to IDL S, I, V New distributed repository services S, I, V New distributed database standards S, I, V 4. BINDINGS MANAGEMENT 4.1 PROFILES Ada developers would benefit from a well-maintained, commonly available list of bindings profiles, i.e., profiles of existing bindings for application classes that have been qualified to be used together and with other application products. Of particular interest are: embedded systems/weapons profiles, C3I profiles, and Business/IS profiles. Validation suites should test for interoperability. An obvious approach is to extract the collection of bindings used in existing applications. For example, the Navy's BSY-2 project is a large successful Ada project which contained many COTS interfaces and Ada bindings. A software archeologist could extract the bindings and COTS interfaces used on BSY-2 and produce a profile for embedded weapon systems. The same approach could be taken on the Joint Computer-aided Acquisition and Logistics Support (JCALS) program to produce a CALS profile. 4.2 VALIDATION TEST SUITES Validation suites for bindings can be broken down into three broad categories: syntax, semantics, and interoperability. The syntax of a binding is related to its specification. The package specification or mapping strategy can be tested for conformance by having a test suite that makes reference to all visible names. The references should test the type of object of the name. This mechanism can be used to ensure that compiler will properly occur with the bindings, and could be automated by a tool. This method of checking can be an aid when evaluating whether a new Ada compiler and platform will support the application in question. This method assumes that the semantics of the calls produces the effects desired. Since this is not necessarily an accurate assumption, a second kind of test would exercise the objects and operations of a binding to ensure correct operation. This approach centers on the effects of calls to subprograms in the proper order, checking the results for correctness. This type of test is more difficult to produce, because it requires a deeper understanding of the binding in question. Automation of this test is not generally possible. One possible implementation strategy is to assert pre and post conditions on operations that define the operational semantics. The third type of test is the interaction of several bindings operating in the same application. The approach is to interleave calls to the bindings checking the results for correctness. This will test the implementation of the binding to uncover unwanted interactions that are not part of the interface. This type of testing is related to application profiles, and such tests are usually developed by an end user to qualify their choices for bindings and standards. It is important that at least two of these types of test are developed for a binding. If the binding is oriented around a vertical market, then a syntax and semantics test will suffice. If the binding is expected to be horizontally reused, then an interoperability test should be developed. Since the semantic and interoperability tests focus on how an application will use a binding, and may not necessarily reference every visible name, an automatic syntax check should be performed. 4.3 TOOLS, DOCUMENTS & GUIDELINES In addition to addressing needed bindings, it is necessary to solicit documented methods and styles for creating bindings. This should culminate in an Ada Bindings Style Guide and language specific style guides for C, C++, FORTRAN, COBOL, etc. Obviously, the development of language specific Ada bindings should create portable bindings across most implementations of that language. There is also a need for special tools to ease the creation of bindings. One such tool is a thick bindings development tool that would extract design information from the underlying software system and a thin binding to produce recommendations for a thick binding. A general Bindings Development Toolkit would include information about memory management, tasking/threads management, and compiler specific interface packages. A bindings style-guide checker should also be part of this toolkit. To encourage the development of Ada bindings for COTS tools, partnership agreements may be possible between projects and COTS tool developers willing to offer an Ada API for their tool. The focus on these COTS tools should be the PC marketplace, particularly in the 4 GL market. Particularly desirable would be tools that use the Ada version of TCL and CORBA interfaces. 4.4 INVESTMENT OPPORTUNITIES This report is primarily focused on obtaining implementable bindings, evaluation of these products, and obtaining production quality bindings. There are at least five areas where investments can stimulate high-quality specifications and implementations of Ada bindings. 1. It would be desirable for production-quality binding implementations to be distributed and maintained as part of commercial product lines. Solicitation of comparable efforts is possible under such Federal-government programs as the Advanced Technology Program (ATP) at the National Institute of Standards and Technology (NIST). Such an effort in the Ada arena could take advantage of projects that are developing bindings as part of a larger effort. It could encourage and possibly fund part or all of their development with the goal of making these bindings widely used and available. 2. The acquisition process can encourage DoD purchases of products with Ada bindings. A strategy aimed at that effect would depend upon obtaining the cooperation of the procurement officers for hardware, support software, and application software acquisitions. Contracting/ procurement officers, or more senior acquisition or policy officials could publish a rule that purchases of COTS software should have Ada bindings. When evaluating bids for COTS products offered without bindings, the offerer could be "taxed" up to the cost of development and support of interface bindings implementations. 3. Bindings efforts should focus on new emerging component standards, which will allow a large class of software system to interface with Ada programs via a single interface. Investment here is the only way to obtain the objective of a self-perpetuating binding marketplace. This report has focused heavily on such areas: OMG's CORBA (SOM and DSOM), and Microsoft's COM (using OLE) and ODBC. 4. Considerable value can be gained from participation in standards working groups that actively work on the publication of formal (de jure) or product (de facto) standards. Development projects find it difficult to support standardization work, since the time period to develop a standard is longer than most software development cycles; therefore, other organizations with a longer-term view should support these activities augmented by software project personnel who represent real operating needs. The standardization process for bindings can be accelerated by development of important product binding implementations as a mechanism for producing a baseline specification. Binding implementation(s) serve as a proof of utility. (Standards groups prefer to start with a commercially-accepted base document.) It is much easier to obtain agreement on a specification when it has been proven to be implementable and behaves as desired. Most bindings users are less concerned with whether or not the binding has been "blessed" by a standards group than they are about the quality of the binding implementation and the portability of the binding specification - neither of which require a "blessed" standard. 5. Successful software-development contracts may already have products available that can contribute to development of binding implementations. 6. Projects can pursue partnership arrangements where some modest investment in project-unique bindings will remove a barrier to the use of Ada. APPENDIX A. AVAILABLE Ada 83 BINDINGS Bindings for Ada 83 are those that are available to the application developer. Table A-1. Current Compiler Vendor Bindings Vendors ASIS CICS GKS MS-Windows POSIX 1003.5 PHIGS SQL Unix X-Windows OTHERS AETECH, Inc. Xlib, Xt, Motif, Open Look Alsys, Inc. E NI X-based UIMS DOS, Multi-language Debugger (IEEE 695) Digital Equipment Corporation NC* Xlib, Xt, Motif (DECWindows) SMTP, VMS and ULTRIX APIs Irvine Compiler Corporation Xlib, XT, Motif C2Ada bindings generator OC Systems XGSL, GL, Xlib, Xt DB2, IMS, National Language Support (NLS) character sets, IDL translator Rational NI XView, Xlib, Xt, Motif Sun Microsystems Corporation NI DEVGuide, XView, Xlib, Xt, Motif Legend: NC = non-standard, NI = non-standard and incomplete E = Embedded SQL, M= module =SAMeDL * Table A-2. Current Third Party Provided Bindings\x11 Third Party Provider GKS PHIGS SQL Windows NT XWindows OTHERS Accelor8 Unix implementation of VMS/RMS Advanced Technology Center Xlib, Xt, Motif Competence Center Informatik GmbH M EVB Software Engineering, Inc. X-based UIMS Gallium Software, Inc. Ingres Corporation E Integrated Computer Solutions, Inc. X-based UIMS Intermetrics, Inc. M LabTek Corporation Objective Interface Systems, Inc. X-based UIMS, Xlib Fresco Oracle Corporation E SQL pre-processor Silicon Graphics, Inc. Open GL SL Corporation X-based UIMS Software Technology, Inc. Sunrise Software International Xlib, Xt, Motif PEX (full implementation in Ada) Systems Engineering Research Corporation Xlib, Xt, Motif Top Graph'X X-based UIMS WPL Laboratories, Inc. IEEE-488 (AdaGPIB) Legend: E = Embedded SQL, M = module SQL = SAMeDL Table A-3. Current Freely Available Bindings\x11 Bindings To: Description Status Ada/OSI Ada Operating System Interface NS, I AFM Adobe Font Metrics NS, I CICS Customer Information Control System NS,C CMW Compartmentalized Mode Workstation NS, I DCE Distributed Computing Environment NS,I DIS Distributed Interactive Simulation S, I GKS Graphical Kernel System S,C OSF/Motif Motif NS, I IEEE-695 Multi-Language Debugger S,I IRDS Information Resource Dictionary System N,C Mil-Std-1553 Avionics bus NS, C ODBC Ada Sage NS, C Paradox PC database NS, I PCTE Portable Common Interface Specification S, C PHIGS Programmer's Hierarchical Interactive Graphics System S, I IEEE 1003.5 Ada bindings to POSIX 1003.1-1990 S,I SAMeDL SQL Ada Module Description Language S89, I (one of three levels) TCP/IP Transmission Control Protocol / Internet Protocol S, I UATL Universal Ada Test Language NS, I Unix UNIX kernel APIs NS, I Xlib, Xt GNU NS, C XVT Unique COTS product NS, I Legend: NS=non-standard; S=Standard; C=complete (Ada implementation); I= incomplete (Specifications only)