Re: Java questions

Distribution/programming model

------------------------------

As many AS/400 shops we would like to re-use as much as we can of our legacy applications which have been written mainly with RPG/400 and RPG IV for more than 10 years. We haven't yet jumped on ILE for the moment and have not found the time to include this new way of programming. Furthermore, the change management/versioning/deployment tool we are using does not support ILE (does any?). Some of our traditional programs are monolithic some others have correctly been designed, splitting the data logic from the business logic. Most of them access natively DB2/400, few of them have embedded SQL. As I said we want to re-use all the business logic we have been developing for years and smoothly migrate to use native Java applications on the server side. The model we intend to use is split in 5 layers :

. The presentation logic (GUI)/the thin client

. The CORBA/IIOP layer

. The process object (written in Java and/or RPG)

. The business object (written in RPG)

. The data logic (DB2/400)

If many applications have been written on the AS/400 natively with 5250 type screens, we have also these last years developed several Fat Client/Server applications with mainly, Microsoft Development tools like Visual C++ and Visual Basic. These applications use mainly CA/400 ODBC to access either DB2/400 or stored procedures which are RPG programs. We have also used MS SQL Server (at that time the DB2/400 engine was not really sophisticated enough and SQL was not performant!) but intend now to avoid duplicating information between systems in order to have one real-time environment. We also have front-end applications running in other environments like Windows NT and Solaris 2.6. The core system remains the AS/400.

At this stage we don't know if we will deploy Applets or Applications written in Java. What we already know is that we would like to develop thin client applications with Java, eventually adapt the VC and VB existing applications with CORBA in order to use the same process objects and have one and only one logic accessed. The AS/400 Toolbox for Java needs approximately 1 MB of data to be downloaded to a Web browser when an Applet is launched. I'm referring to the "AS/400 Object" which is needed on the client to access the Host servers. The use of CORBA will allow us to :

. facilitate the deployment and integration of applications

. facilitate the migration of departmental applications to enterprise applications then Web applications

. be more reactive in front of business modification

. be more effective-faced re technology evolution

. improve the re-use of business components

. have standard accesses between layers

. access the AS/400 with several type of clients (Java, VB, VC, HTML, browsers)

. make the use of the server services transparent and independent

. avoid the heavy transfer of the Toolbox

. access other existing platforms

. better dispatch the application services in the network

. allow developers to be more specialised on the Java Client and/or the Java/RPG server

. avoid the use of JDBC

. have a scalability(multithreading between ORBs on several servers)

. be more scaleable

. better use the internal resources and focus developers on the right environment

. and last to use an object middleware with open specifications, independent of users and constructors

The AS/400 Toolbox for Java will mainly be used on the server side, on the AS/400. This will allow the process objects to access the existing RPG applications or any type of AS/400 objects. The Toolbox will be used through VA Java 2.0 Enterprise.

EJB is without doubt our long term target and strategy. At this stage we first have to make this pilot project a success before we envisage using an Application Server. Furthermore, BEA-WebLogic Tengah sounds to me a tactic approach and not a long term strategy (maybe I'm wrong!). Websphere is probably the concept which will be deployed amongst IBM platform. At this stage, the pre-release which has recently been posted on one of your websites is not stable if it works (according to newsgroups participants) and is not properly documented. This will probably will be our target once the product is really announced and that the market goes in that direction (Q499?.

RMI is going to be integrated with IIOP, SUN is currently working on his subject. I do not see any advantage at this stage if we use RMI when we use CORBA. Maybe without CORBA we could use RMI but this means we should have pure 100% pure Java applications on the Client and the server...which is not the case by now!

If we want to re-use existing COM applications, we will use a bridge with CORBA. Some ORB providers already offer this facility.

ORBs

----

VisiBroker for Java 3.3 has been chosen for the following reasons :

. Highly recommended by our mentoring consultants

. 100% pure Java (excepted the OsAgent)

. runs on the AS/400 (we have tested it! (OsAgent on NT))

. very performant and stable

Amongst ORB's I know on the market, I guess ORBIX could be a candidate. Component Broker Connector seems to be far away from the AS/400 and is not yet correctly packed.

The CORBA services which are requested are:

.naming (based on LDAP), critical

.events, desirable

.transaction (in our environment, too early to know)

.security, critical

.persistent object, desirable

.concurrency, desirable

To know if ORBs in Java and in C++ should both be available on the AS/400 is difficult to answer. Java no doubt. For C++, this could be useful if we decide to modify the existing two tiers applications and move the business logic to the AS/400. In this the case we should experiment C++ on the AS/400 (not yet been done) and probably use the C++ ORB. VisiBroker for C++ is anyway available.

Legacy access

-------------

As mentioned earlier we definitely have to access non-Java programs (RPG 400, RPG IV, CLP).

We are going to externalise the access with Java wrappers and AS/400 Toolbox.

IDL to RPG would be great if once delivered by IBM! First it would avoid developing Java process objects on the server side for those who want to keep RPG applications as they exist, this would then avoid the various interfaces (Java, Toolbox, RPG) and probably improve response time. This would also allow clients to use CORBA as a standard for distributed components.

We do not think that JNI will be used for the time being, except if we port C++ client components to the AS/400.

Ease-of feature: Smartguides to use IDL beans and more to come (I'll keep you informed).