From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fe9e900c40b08b36 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-01 13:14:49 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!news.dfn.de!Germany.EU.net!EU.net!uunet!ois!beckwb From: beckwb@ois.com (R. William Beckwith) Subject: Re: 9X Distributed Annex? CORBA? Message-ID: Organization: Objective Interface Systems, Inc. X-Newsreader: TIN version 1.2 PL2 References: Distribution: comp Date: Sat, 1 Oct 1994 18:07:37 GMT Date: 1994-10-01T18:07:37+00:00 List-Id: WOODRUFF@ec2226.addvax.llnl.gov wrote: : I'm seeking information and relevant advice about planning and building : a distributed application using Ada94. The application is an integrated : control system that will deploy about 200 workstation-class computers in : a local area net to control the next-generation high-power fusion laser. I like your choice of languages :-) : I have studied the RM's Distributed Annex, and I recognize that the : language standard will allow me to build the system I need. However I : am not aware of any implementation of the Annex. I have not seen any : claim by the GNAT team that they are planning an Annex implementation. : Validation of commercial compilers is likely to be higher priority to : compiler businesses than building Annexes. Therefore my first question : is "where and when am I likely to obtain an implementation of : Distributed Annex?" Nobody has a dist annex yet. Dr. Volz at TAMU has been looking for funding to build a research dist annex. I think you are right that the compiler companies have other higher priorities. : The other standard that appears relevant to my intention is CORBA. I'm : pretty uninformed about implementations of CORBA, so I'd welcome advice : about what I should do to prepare for eventual use of these products. : How will Ada interface to CORBA tools? The earliest CORBA efforts with Ada were based on trying to bind Ada to C code generated by an IDL to C translator. IDL is the CORBA Interface Definition Language. IDL allows the definition of an interface that is distributable. There are approved IDL mappings for C. C++ and Smalltalk mappings are about to be approved. We have been working with MITRE to produce an IDL to Ada 9X mapping. This IDL to Ada 9X mapping committee has endeavored to produce a cleaner, more elegant mapping than the lastest C++ mapping. This is not hard given the multiple variants of C++ and the existing C++ CORBA products the C++ mapping must retain compatibly with. The resulting Ada 9X mapping will allow vendors to produce compatible Ada 9X CORBA products. When the next revision of the mapping is complete, we will distribute it around the net. If the feedback is consistently positive then we will be submitting this mapping to OMG. : Will CORBA implementations let me mix my application parts with : components in other languages, or even with COTS software? Yes. Transparent, interlingual interoperability is a primary benefit of CORBA. You even can let developers in other languages benefit from your Ada 9X software. I like to think that IDL will eventually replace the /usr/include C header files as language independent interface definitions. Maybe the POSIX committees will take note. : What is the relationship of CORBA to the distributed annex? We have put a lot of effort into determining how the dist annex works in relation to CORBA (thanks to Anthony Gargaro and Tucker Taft). The dist annex is a very flexible, innovative piece of work. In its v5.0 form, the dist annex could not meet the requirements of CORBA. However, Tuck has submitted a proposal to modify the dist annex that I believe will allow a implementation of a dist annex that uses an ORB for communication. Distributing object oriented software causes certain difficult choices. You need to present an abstract interface to the clients of a service. The implementations of this interface are separately defined. The big decision is whether have the implementations (say Vehicle_Impl and Car_Impl) inherit from the abstract interfaces (Vehicle and Car). If you have Vehicle_Impl inherit directly from Vehicle, then since Car_Impl inherits from the abstract Car, Car_Impl doesn't inherit the data and operation implementations in Vehicle_Impl. This is usually called the BOA approach. Most of the current C++ products take this approach. The result is that you must put a Car_Impl object in Vehicle_Impl (to get the data). Then you must write (or generate) pass-through operations in Car_Impl for each of the operations implemented in Vehicle_Impl. I didn't like this approach at all. So we came up with another approach with two parallel inheritance trees. Car inherits from Vehicle. Car_Impl inherits from Vehicle_Impl. The code generator takes care of the details connecting the two. The _Impl's are much cleaner. We found out later that this approach is the similar to IONA's newer `tie' approach. The latest C++ mapping accommodates both the older BOA and the newer tie approach. The Ada mapping allows only the tie approach. O.K., back to the dist annex. The dist annex doesn't solve this problem or interfere with a solution. In fact Tucker sent me an elegant version of the tie approach using the modified dist annex. The problem is that the use of the dist annex for CORBA only saves the code generator the generation of one piece of code per interface. We felt that requiring the dist annex as a prerequisite for a CORBA product was too limiting. In addition, the use of the dist annex thwarts the implementation of automatic memory management. If the Ada 9X reviewers don't object to Tucker's change and believe that it is possible and reasonable to develop a compiler/dist annex tool with the change, then we may produce a second mapping especially for the dist annex at some point in the future. I suspect that some projects will still want to use the dist annex because the CORBA model doesn't fit their need. : If the two are complementary strategies, then what will I need to buy : and what do I need to learn so I can plan my application? You'll need to buy a CORBA Ada product consisting of an IDL to Ada translator and ORB binding product. A CORBA Ada product will allow you to both use IDL to access services provided by other products and to write IDL, generate the Ada framework, and write the service implementations in Ada 9X. OIS will demonstrate an IDL to Ada 9X translator at TRI-Ada in a month. We should also be able to announce our ORB marketing plans by then also. : On the other hand if they are two competing paradigms, how can I : choose between them, and how bad will be my punishment if I choose : the wrong one? Well, I like to think that you would find both paths rewarding. The CORBA path leads to language independent interfaces and interoperability with future standards. The dist annex path leads to a flexible Ada based distributed interface capability. A distributed real-time system running in satellite or airplane will probably chose the dist annex for greater control of the response times. A distributed MIS or C4I application will probably want to use CORBA to gain and offer service access to other software. : John : (woodruff1@llnl.gov) : Lawrence Livermore National Lab Thanks for the interest. ... Bill -- e-mail: Bill.Beckwith@ois.com | Team Ada Objective Interface Systems, Inc. | dist, full O-O 1895 Preston White Drive, Suite 250 | multithreading Reston, VA 22091-5448 U.S.A. | built in