[Editor's Note: In our May 18 issue, UniNews reported on the Deploy project, an effort to build a framework for UNIX software test tools sponsored by the European commission, X/Open, the Open Software Foundation (OSF) and other organizations. Deploy is based largely on the Architecture Neutral Distribution Format (ANDF) technology developed by the UK's Defense Research Agency. To explore ANDF more deeply and learn about its other applications, UniNews interviewed Steve Johnson, senior technical consultant with the OSF Research Institute.]
UniNews: What was the original idea behind ANDF?
Johnson: One of its principle functions was to try to find a way to shrink-wrap applications so that you could get the same kind of distribution vehicles in the open systems marketplace that you could for PCs-so you could pick up the software off the shelf and run it on UNIX without having to also qualify that you're running OSF/1 or SVR4 or SunOS or HP-UX or any different version out there. That was its initial objective.
UniNews: How did ANDF get started?
Johnson: Originally with a request for technology issued by OSF for ANDF in April 1989. There were a number of people who responded to that with a wide range of technologies. There were something like 24 submissions that had come in, none of which claimed to be solutions to the ANDF problem. But they proposed that those could be engineered into solutions to the problem. So unlike some of the other RFTs for OSF, where there was an existing technology that could pretty much be brought to market with some engineering work on it. The ANDF problem was going to require more effort than that.
Following an initial round of qualification, a number of the people dropped out for a variety of reasons, so we ended with 15 bona fide submissions. Of those submissions we then selected a short list of four that went into a prototyping stage so that we could actually determine that indeed, the ANDF problem, as we had stated it, was solvable. Out of this prototype stage, we ended up selecting the technology proposed by the DRA, then known as the Royal Signals and Radar Establishment, in the UK.
Of the four submissions, they all actually demonstrated that there was a potential solution to the ANDF problem as we had stated it. One of the submissions was kind of held together with bailing wire. Two of them had some engineering problems. The DRA technology essentially satisfied the performance requirement, and in addition, it was quite compact in its representation. It met all of the other qualification levels that we had put into our initial set of goals. So that selection was made in June 1991.
UniNews: How did you go about developing the technology?
Johnson: We went into a program with DRA. We got about a year into that when the program moved into the research institute. That happened principally because of the fact that while this was still a technology that fell into a category that OSF should be working with, it was not clear how ANDF was going to contribute to OSF's bottom line. Lots of people stood to make money from it, but it was not clear that OSF was one of them. So it went through a transition from being part of the commercial offerings into being a research project, and that's where we've been for the last couple of years.
UniNews: Has there been a problem spreading the use of ANDF?
Johnson: What's happened in the meantime is that there was a period of time when there were some commercial companies who were looking into utilizing ANDF. One of them was USL. We had an active contract with them because they were looking to have SVR4 run on a variety of different platforms and ANDF seemed like a suitable vehicle. That program was ongoing until USL was bought by Novell. Novell is very much Intel-focused, and so while ANDF is still of interest to them, it's essentially [a low priority] in terms of funding because they've got so many things on their plate right now.
UniNews: What ANDF programs are going on now?
Johnson: There are three major funding efforts for ANDF right now. One of them is a research project that we're involved in, looking at the ANDF and how it can apply to portability within the high-performance arena. That's under U.S. Defense Advanced Research Projects Agency funding in Cambridge, Mass. The other efforts are in Europe. The on-line Open Microprocessor Systems Initiative/Global Language Support and Uniform Environment (OMI/GLUE) project, which actually precedes the Deploy project, is strictly focused on ANDF. It started in June 1992 with a three-year run on it. The purpose of the GLUE project was to try to determine if ANDF was suitable both for additional architectures and for additional languages.
There are a number of different deliverables, some which have already come out of that. One that OSF was a key player in was an ANDF validation suite which actually provides a way of validating components in an ANDF system. If you are going to use ANDF as a distribution vehicle, then you are dependent on the ANDF producer, the ANDF installer to properly install it, and the target runtime system on the target platform to behave in accordance with the API specifications. The only one of those where existing test suites existed was for the last one, where you have things like the X/Open validation suite for exercising the various application programming interfaces. OSF is essentially working on developing a validation suite for the other two key components in the ANDF chain-one of them for validating installers and the other one for validating producers. The installer validation suite is completed and available to the partners now. And the producer validation suite is now under development and will be delivered sometime toward the middle of next year. There's actually a prototype of that running.
The Deploy project is fairly new and oriented more toward education on what ANDF is all about, as well as trying to further the work that's being done in the validation and test area. And it involves a number of partners such as X/Open, which may well end up promoting ANDF as a standard vehicle. One of the things that X/Open does is maintain de facto standards like the X/Open Portability Guide. They will also be taking over the specifications for things like the the Common Open Software Environment (COSE). ANDF is a logical adjunct to that because ANDF is the technology that can make COSE a reality. We have an environment already that will support Spec 1170, so you can actually develop applications against that 1170 specification and get diagnostics out, if your programs exceed the bounds of that specification. So you would have ways of checking portability against that frame of reference already.
UniNews: If you have to have an installer on the machine, is that a limiting factor in the spread of ANDF?
Johnson: Early on we wanted to show that the ANDF technology was not a black-box technology that necessarily required expertise, with the DRA technology. We built an installer family that has a bridge that goes between the ANDF external representation and the GCC back end.
UniNews: Wait. What's a GCC?
Johnson: GCC is the Gnu C Compiler. That's the C compiler that's available from the Free Software Foundation (FSF). You can freely pick it up if you have the network or you can get it by just ordering it from FSF. Virtually every UNIX platform has GCC running on it. It's not sold by any of the system vendors but there's a GCC running on all these platforms because it's a full ANSI-compliant C compiler, which the compilers of many of the system vendors are not. So if you get ANSI C applications and you need to compile them, as frequently is the case, then the Gnu C compiler is your only method for doing that.
UniNews: Okay, then what does the bridge do?
Johnson: As a result of having this bridge, anyplace where you have a Gnu C compiler, you have an ANDF installer. And there's a GCC nearby for just about any platform that you can think of. So that's not a limiting factor. We have installers running on [DEC] Alphas, we have them running on [IBM] RS/6000s, on the HP boxes, and on Intel chips. The real limiting factor has largely been the acceptance in the marketplace, the fact that it's yet another technology. And in some cases there has been resistance from system vendors, largely because they have in-house compiler groups and the in-house compiler groups don't view ANDF as their friend.
UniNews: Because ANDF would supplant them?
Johnson: It has the potential of doing that. The experiment we did with the Gnu compiler basically says that if you can do this with GCC, which has certain known properties, you can do the same thing with an existing vendor's compiler. So that if you have poured in 15 or 20 staff years of worth of work on your global optimizer, you don't have to lose all that work by picking up ANDF because you can build a bridge technology, just like we did with GCC. We showed that you can not only do that but you can do it trivially. A number of vendors have looked at this and said that to build a similar interface to their proprietary back end is basically a no-brainer. So that's not really an issue either. It's definitely more of a political or marketing issue at this point than anything else. We even did a port of this technology to [a Microsoft Windows] NT system. Microsoft looked at it and said that we solved the problem we said we were going to solve. Their issue is simply what they consider the cutoff point as to how effectively they can utilize the ANDF technology. The cutoff is when they have reached a critical mass in the number of platforms they feel they have to support with NT. Their guess on that number was something like six or seven and right now there are only about three or maybe four platforms that currently have active NT ports going on. Until that number gets larger, they can't justify further expenditures on ANDF.
UniNews: What is the best possibility for use of ANDF now?
Johnson: There are two things. The Deploy project itself is trying to promote the proliferation of the ANDF technology. They are trying to get some case studies through some application vendors to actually do some porting of applications into ANDF. We've had some experience doing that here ourselves. We did a port of key components of Oracle including the database manager itself into ANDF, and then ran them on a variety of platforms. So we know that there's a fairly straightforward approach you can take to doing this. But we don't want to be in the business of continually doing application ports, so we're trying to encapsulate this knowledge base and get the ISVs themselves to investigate what it takes to do this, and what the derived benefits can be. Rather than having to do a whole bunch of customized ports of their application every time a new platform comes out or a new version of an operating system comes out, if the API is the same between the two versions, with ANDF you can simply reinstall your application on the new system and you're back on the air again. When you deal with somebody like Oracle, which has something like 120 identified UNIX ports of their database software, this is a big win for them. It considerably lowers your maintenance cost if you don't have that many different variants of the same product that you have to maintain. It usually takes about half an engineer for each one of those ports just to maintain it.
The Deploy project clearly is geared toward there being a commercial acceptance of ANDF. We just started on a project where we will be serving as a distribution channel of the ANDF technology for the research and academic marketplace. We have funding to do that. We're going to make this bridge technology that we have built, plus other components of the DRA technology, available in that arena so that there can be a proliferation of experience with ANDF beyond just OSF and the people that are out there immediately associated with OSF. Then we get a much larger spread of experience with ANDF and I think that with that experience, especially if it's a positive experience, will come further proliferation.