Does Java Alone Really “Open” Up Computing?
The demand to develop new business applications using new technologies has never been higher than right now. Business customers all over the planet are asking: “What new development language should we be investing in to help us battle our application backlog?”
Overwhelmingly, the answer to this question has been Java. One of the top features of Java is the purported “openness” of the applications developed with it. This openness comes from strong adherence to Java language standards, combined with a technology allowing specifics of the underlying hardware to be hidden from the programmer though an intermediate code representation and execution engine (the JVM – Java Virtual Machine). Above and beyond this advantage come advantages from object-oriented programming, high levels of investment by key software vendors (e.g. IBM’s Visual Age, WebSphere) and its popularity on campus.
But potential interested businesses should understand that Java as a programming language works in conjunction with an application architecture (a client server model) of the customer’s choosing. This is unlike traditional AS/400 RPG programming, where the RPG language is part of an all-encompassing development system. The result is how “open” your Java application becomes is a matter of your choosing, not a matter of fact.
Most customers developing applications today choose a three-tiered client-server model.
1. The Client Tier
In the three-tiered model, this is the component that executes on the client – typically a web browser. The customer has the choice of fat or thin client. A thin client will provide only a graphical user interface. A fat client however will also include programming logic to be executed on the client. Java is a superb language for the development of this logic (applet) because it makes the client independent of the operating system. Developers adhering to strict Java guidelines will encounter few porting problems at this juncture.
2. The Application Tier
The second tier represents application-specific logic. Here, Java is again a good candidate. Note that Java, in this case, operates to execute server logic (Servlets, JSP) because it will have multiple clients attached to it and thus has different demands and characteristics. Although porting of the Java syntax for the application tier tends to be quite consistent, developers still need to consider differences, not in the programming, but in the systems. For instance, threading can present problems.
Java is multi-threaded and requires a multi-threaded capable job. Threads provide parallelism in execution thus making full use of multi-processor resources efficiently. Most legacy applications do not execute in a multiple threaded environment. The current OS/400 kernel supports threads and also POSIX threads.
Thread control, spooling and security provide flexibility for performance tuning and load balancing, however you must write you own system level functions for the AS/400. When a legacy program calls a Java program, it will create a JVM, which is a Batch Immediate (BCI) job. Thus, a customer may have treading issues when porting multi-threaded Java applications interfacing to other systems.
The AS/400 Toolbox for Java has implements the Data Queue object to facilitate interfaces with legacy systems. Considerations for a thread safe environment can be accomplished through this Data Queue object.
3. The Data Tier
The third tier represents the enterprise server. It typically consists of the database. For an AS/400 there is only one choice. It is DB2/400. For other platforms, there are other choices such as Oracle.
Many people access the relational data, regardless of make, through drivers such as JDBC. However, the porting problems lie beyond the drivers.
One of these problems is trigger and stored procedure handling. An Oracle Trigger or Stored Procedure, written in Oracle’s PL/SQL, can only be ported to other Oracle databases. PL/SQL code, which is not available native on the AS/400, must be re-written.
Furthermore, AS/400 Triggers cannot be written in Java or in SQL procedure language. To write a trigger for DB2/400 you have to use high-level language programs using ILE. Thus, since Java cannot be used for writing triggers, C or C ++ could be used to implement it. Using C or C ++ will enable the control of various buffers and tables and information processing.
There are other syntactic and semantic differences between Oracle and DB2/400. These differences are all a cause of porting concerns. For instance, DB2/400 does not prevent you from dropping a table referenced by a trigger, stored procedure, or program. Due to the dynamic binding of tables to statements, it would not be 100% possible, even for static statements.
Operating System/Performance TuningLast, but not least, the operating system chosen may impact the application. The AS/400 operating system, OS/400, is fundamentally different from Windows NT or Unix. Some of these differences, such as the database being a part of the operating system, or the single level storage management, mean that security, object authority, save, restore, high availability may require different approaches to running the Java application. For instance, an application tuned for maximum performance on Windows NT may not be tuned for AS/400, and vice versa.
In V4R5, Visual Explain was added to the AS/400 Operations Navigator to help make AS/400 query performance analysis much easier and similar to functionality offered by Oracle Explain.The bottom line is that Java opens up two of three tiers in today’s client server model with relative ease. The openness of the third tier, typically the database server, is in the hands of key database vendors such as Oracle and IBM. User beware: it is in the interest of the database vendor to provide customers with specific “hooks” to their database, which they, as a customer, may then advertently or inadvertently use. These hooks will later cause porting problems and costs. Even if you use Java, you are still responsible for the platform independence of the resultant application.
Mark Buchner is president and founder of Astech Solutions Inc. (Aurora, Ontario), which applies technology to the practical needs of the AS/400 market. mbuchner@astech.com
Related Information:
Java Technology Zone (new window)