At a November 21st press conference in New York, Marty Sprinzen, the president and chief executive officer of application development software house Forte Software Inc, outlined how his company is planning to modify its 3.5 million-line code-base to tackle the issues introduced by Java and network-oriented computing. The results should appear in Forte Release 4.0. Lem Bingley, Editor of Software Futures, was there.

Forte Software Inc, like almost everyone else in the development tools market, is in the process of moving to a components based approach, and will be using Sun Microsystems Inc’s Java Beans. Its support for Java will come in two broad stages. To begin with, Forte will allow developers to generate Java code (rather than the current C++) so that client-side logic can run within a browser instead of the Forte run-time environment. Thereafter, the plan is to allow developers to program explicitly in Java – instead of the Forte fourth generation language – within the Forte development environment. This will allow the mixing and matching of Forte objects and Java components. This change, which will allow Java code to run at both the client and the server, is due in Forte release 4.0 – a release that’s not expected to ship in its entirety until early 1999. However, Oakland, California-based Forte says that it is adopting a web-style public beta policy that should enable its keener customers to begin experimenting with the technology for some time prior to its official release date.

Supporting all lentils

Although the company is backing the Java Beans component interface, other aspects of the company’s Java plan are less clear. It has yet to specify which version of Java Developers Kit (JDK 1.0 or 1.1) it’s planning to support in the short term. This is a fundamental question – when it comes to actually building applications, the developers kit defines which Java services are available. The question is made doubly pointed by the fact that Microsoft and Sun are currently disputing the process by which the Java service libraries are defined. We have a corporate policy of supporting all lentils, Sprinzen quips in answer. We have, in the past, been led down some garden paths. DCE [the Distributed Computing Environment] is one. Right now, we’re not getting any new DCE users – instead we’re getting IIOP [Internet InterORB Protocol] users, he adds. Clearly Microsoft doesn’t want Java to be a standard, and it’s one of the few companies that’s capable of affecting the outcome. If the split continues to widen, then we will support both varieties of Java libraries. We will hide that problem from the developer. Whatever version of Java is supported, it seems unlikely to be 100% Pure. Despite the hype, no large applications will be built entirely in Java, comments David Taber, Forte’s senior vice president of marketing. Java’s very important to our strategy – but so is C++. Pure Java just isn’t going to be economical. As part of its overall Network-Computing strategy, the company is planning to expand the capabilities of its trade-mark application partitioning facility – a mechanism which lets developers decide how to divide application processes across different tiers at the last moment before deployment. Sprinzen says that a forthcoming edition of Forte, expected to be release 4.0, will provide for asymmetric partitioning. This will involve the partitioning of a single application in a variety of modes, to support different deployment configurations. By maintaining models in the Forte repository for different combinations of physical machines, the new facility will make it possible to co-ordinate a number of partitioning options from a single code-base. Network Computers might require client-side software with a smaller footprint than that intended for a PC, for example. Right now, if you want to cater for that situation, you have to generate two different applications, Sprinzen admits.

Elements of Push

To assist in this area, Sprinzen cagily admits that the company is working on push technology to distribute client-side code, also expected to appear in version 4.0. Currently, Forte applications must be deployed manually, but the addition of push technology would clearly help to cut the costs and increase the ease with which upgrades might be delivered. Sprinzen says that the push elements will be developed in-house, rather than licensed from a specialist vendor such as Novadigm Inc or Marimba Inc. The Forte run-time already does version-checking automatically, to ensure that all components are synchronized, Sprinzen says. However, it’s currently up to the individual developer to decide what to do if a mis-match is detected. The increased focus on deployment flexibility may be the reason for Forte’s decision to re-develop its underlying repository. The current iteration is little more than a collection of flat-files – it was originally built on an object database, but company officials admit that this design was abandoned for performance reasons. In the future, again possibly in the 4.0 release, the repository will be moved to a relational database. The company maintains that it has no plans to adopt the Microsoft Repository specifications, which are similarly designed to use a relational database as the underlying store.