Instead, the AS/400 uses its single-level store to support persistent SOM objects, with no involvement from the programmer. When you create an instance of a SOM object, you specify whether it is to be a protected, or persistent, object. Protected objects are encapsulated and exist alongside the OS/400 objects we have already discussed. When a protected object is created, it is put into an IFS directory, similar to the way an OS/400 object is created into an AS/400 library. Protected objects have names and can be shared, saved, or restored just like any OS/400 object can using OS/400 commands. At the MI, these objects are implemented as byte space objects. Thus, security for protected objects is through system pointers and the authority component in SLIC. For compatibility reasons, SOM objects also supports unprotected SOM objects.

When we introduced Java and Java objects into the AS/400, we were able to exploit the single-level store’s ability to support persistent objects in a way similar to how it supports SOM objects. The benefit of this persistent object model in an AS/400 is lower overhead when the system is dealing with objects. Other systems must execute additional instructions to maintain object persistence; they must continuously refresh the object on disk to ensure it can be shared among multiple programs. The persistent single-level store of the AS/400 requires no such refreshing, so when it is dealing with objects, the AS/400 executes fewer instructions and fewer disk accesses than other systems do. The AS/400 single-level store also does not have to deal with garbage collection for shared objects, as I explained in Chapter 8. All of this means an AS/400 should be a more scalable Java server, able to support more Java applications and users than other servers of equivalent size.

IBM’s Toronto Development Laboratory is developing tools such as VisualAge for Java to help customers reap the benefits of the cross-platform capability of Java applications. VisualAge for Java provides the integrated development environment for these applications. Other Java development tools are also available from a variety of AS/400 business partners. Customers who want to get an early start using Java on the AS/400 can do so with beta versions of VisualAge for Java. The full Java environment, generally available on the AS/400 in early 1998, includes native threads to greatly enhance the overall performance.

The San Francisco Project (Java Frameworks)

In 1994, a group of AS/400 application developers approached IBM Rochester about the possibility of developing a new application foundation based on object technologies. Sharing this common application base meant application developers could avoid most of the costs and risks associated with starting an OO programming project. The code name for this effort to develop common application frameworks that many application developers can use is San Francisco.

Earlier, I defined a framework as a collection of objects to provide a common solution to a particular problem. In general, application frameworks are also designed to be easily extended, so that application developers can customize the framework to meet the needs of their specific application.

Originally, San Francisco was based on C++ and SOM. Early in 1996, we held an alpha program to train business partners to use C++ and IDL to create SOM objects, and we found that the languages were too difficult for many people. Java turned out to be a much easier, much more productive environment for these people, and at the same time it was rapidly establishing itself as the industry standard, so we switched our focus to Java for the San Francisco project.

San Francisco is a server-based product targeted for application programmers who want to create Java business applications for a variety of server operating systems. The product initially was intended only for OS/400 but was later expanded to include NT, AIX, HP/UX, OS/2, and MVS. The supported clients include Java (NCs and PCs), Windows, and OS/2.

The development team for San Francisco is split between Rochester and Boeblingen, Germany. Rochester is responsible for the low-level structure and fitting the structure to the operating systems. Boeblingen is developing the high-level frameworks.

Figure 11.3 shows the three layers that make up the San Francisco frameworks. The base layer interacts with the operating system through the Java VM. It manages the interfaces to the operating system, other applications, I/O, and the network. This layer performs such functions as keeping track of objects and controlling access to these objects. The base layer also contains object classes from which higher-level objects are created. In short, the base layer hides the complexities of the underlying structure from the application developer.

Figure 11.3  San Francisco Frameworks

The common business objects layer contains a large number of objects that a business application commonly needs, such as time, date, currency exchange, units of measure, and discount schedules. The common business objects are the building blocks a developer can use to create a business application.

The core business processes layer creates the frameworks. Each core business process is built for a specific type of application, such as a general ledger application or an Electronic Data Interchange (EDI) application. A core business process is not a full application, but it does contain the basic functions all applications of this specific type need. A framework links some of the common business objects with the objects in a core business process to create the base for building an application. Thus, the framework itself contains the commonly used functions for a specific type of application, and this framework is easy to extend so the application developer can customize the application.

Many application developers will choose to use only one or two of the bottom layers. They may create their own common business objects or even their own core business processes. IBM also is encouraging them to share these new objects with the many application developers participating in the San Francisco project.

Some large application developers have moved to an object-development environment of their own already and will not use San Francisco. The primary market for San Francisco is the large number of medium- and small-sized developers throughout the world. The biggest interest has been in Europe because of the many medium-sized developers located there. Many of these developers are already members of the San Francisco Advisory Group, which is directing this activity.

In the rest of this section, we look at two other topics that deal with application enabling: The first is the use of the integrated PC servers to provide additional application processors for the AS/400; the second is AS/400 server models.