Building Enterprise Servers on OS/390 with OrbixWeb

1. Distributed Object Technology & CORBA/Java Solutions Building Enterprise Servers on OS/390 with OrbixWeb by Peter Kanis

2. El proyecto Swisscom Billing (SwiBi) • La facturación actuál es una applicación dinosaurio en COBOL con pantallas 3270… • SwiBi debe sustituir éste con una applicación moderna i inteligente.. • Unfortunately, the new must run in parallel with the old: • Stuck with a legacy database for COBOL with fixed length fields.

3. The SwiBi Requirements (1) • Customer Search. • Customer data overview. • Bill account overview. • Contract overview. • Bill overview. • Bill account modification.

4. The SwiBi Requirements (2) • Detail view of Bill. • Bill recall handling. • Bill double ordering. • Bill correction. • Bill splitting and exception charges. • View of historical data.

5. Windows CORBA C++ Client MFC DB2 Architecture variant 1 AIX MVS CORBA C++ Servant Oracle/DB2 gateway

6. Windows CORBA C++ Client MFC IMS DB2 Architecture variant 2 OS/390 USS MVS Orbix IMS Gateway

7. Windows CORBA or RMI Java Client DB2 Architecture variant 3 OS/390 USS MVS CORBA C++ Servant IIOP CLI IIOP/RMI CORBA or RMI Java Server JDBC

8. Performance considerations • There can be up to 3500 clients connecting to the servant. • One server could never handle this throughput. • Need some kind of session balancing solution. • Require multi-threading.

9. Security considerations • Only specific users, already defined to the RACF security can use the application. • Some users have only read rights, others have update rights. • Require some way to authenticate users on the host system.

10. Windows OrbixWeb Java 2 Client Applet DB2 Final Application Architecture OS/390 USS OS/390 MVS OrbixWeb Session Balancer IIOP JDBC OrbixWeb SwiBi Servants IIOP RRSAF IIOP OrbixWeb RACF Authentication Servant SAF RACF

11. AIX SP2 Node OrbixWeb RACF Authentication Servant Windows OrbixWeb Session Balancer OrbixWeb Java 2 Client Applet OrbixWeb SwiBi Servants RACF JDBC DB2 Client Enabler DB2 Alternate Application Architecture OS/390 USS IIOP IIOP SAF IIOP DRDA MVS

12. Layered design for the Servant • CORBA IDL layer as an interface with no application logic. • Application layer implementing a Factory and controller classes. • Business object layer implementing the business logic and rules. • Access layer wrapping all database access functionality.

13. DB2 SwiBi Servant layering (1) Java CORBA Client CORBA IDL layer com.swisscom.swibi.server.boa Business Object layer com.swisscom.server.bo Application layer com.swisscom.swibi.server.appl Access Object Layer com.swisscom.server.ao

14. DB2 SwiBi Servant layering (2) Java CORBA Client Java RMI Client RMI layer com.swisscom.swibi.server.rmi CORBA IDL layer com.swisscom.swibi.server.boa Business Object layer com.swisscom.server.bo Application layer com.swisscom.swibi.server.appl Access Object Layer com.swisscom.server.ao

15. Advantages of the layered design • The application is decoupled from CORBA, other interfaces can be easily added. • Each layer can be implemented as a Java package by a separate team; easier project management. • The internal structure of the application is clear.

16. The Application Layer • Implements a Factory class that is the unique point of entry into the servant: • Any connection requires a “logon” which is validated using the RACF Authentication servant. • Only after authentication is a SwibiController created for the given client. • The SwibiController class holds a security context for the connection and implements access to Access Layer search methods and to the Business Object layer.

17. SwiBi Servant layering detail Client Server Application CORBA IDL Business atServer startup SwibiFactoryImpl Singleton I n t r a n e t SwibiFactoryAppl Singleton BOAuthorization 1 per SwibiCtrl 2 1 SwibiControllerImpl 1 BOContext 1 per SwibiCtrl remote SwibiControllerAppl 2 4 3 BOBillAccount BillAccountImpl 1 2 BOPaymentMethod PaymentMethodImpl Invoke Connectto Create (Numbers refer to creation sequence) Object Reference

18. Multi-threading in the Servant (1) • To be able to handle varying loads, we used a dynamic thread pool: • A configurable minimum number of threads are started making up a fixed pool. • New threads are started, as required by the load, until a configurable maximum is reached. These threads make up the dynamic pool. • A Monitor thread ensures that any thread in the dynamic pool is stopped when it has been idle for a given time.

19. Multi-threading in the Servant (2) • The Thread filter, worker threads, monitor threads, ORB initialisation and application properties are packaged as a utility which can be re-used. • This package allows a server to be started using a minimum of 3 calls to the Application class.

20. Re-usable dynamic thread pool design 1 Application ORB static getApplication(); connect(); run(); getAppProperty(); 1 1 n 1 1 1 1 RequestQueue WorkerThread MonitorThread Orb Properties App. Properties 1 n 1 1 MessageQueue 1 1 1 OrbixThreadFilter

21. Why JDBC and Not SQLJ? • When we started, there was no SQLJ available. • Tests showed that there wasn’t much difference in performance. • Any changes in the SQL means re-compiling and re-binding. • Any change means a lot of bureaucracy at Swisscom; delays of several days before we could test.

22. The Access Layer • The access layer is, maybe the most complex; some 1200 tables are accessed. • Table and column names are changing as the database is brought up to date: • We store out SQL statements in properties files. • We “have” to use COBOL stored procedures for many of the dB updates.

23. DB2 Multi-threading and other problems • CLI/CAF on OS/390 doesn’t allow a database connection to be shared across threads: • Each “worker” thread must have it’s own connection. • The number of connections is limited by the available resources on USS: • Need a lot of time persuading system administrators to modify the system configuration. • The DB2 DAYS function is out by 2 days compared to Julian Day.

24. Development & Testing Environment (1) • The server side is developed using IBM VisualAge for Java on Windows NT with the repository on AIX. • The client side is developed using Borland JBuilder v3 on Windows NT. The Java files are then imported into the VisualAge repository. • The IDL is compiled into a client and a server package and imported into VisualAge. • For testing, comprehensive Test Engine traces are programmed into the code. The level of tracing is configurable at run time.

25. Development & Testing Environment (2) • Our AIX server has DB2 client enabler installed and is used for unit and module testing during development. • For final testing of a sub-release, the classes are uploaded to OS/390 and the server(s) run from there. • Tests are performed in 2 stages: • Using a Test Engine client running scripts (repeatable tests). • Using the Java 2 client applet.

26. Test Engine Servant Process being traced or tested Trace Repository Control Traces TestEngine class Repository Management Servant Test Engine System Architecture Test Engine Server Host Test Hosts Traces Control Traces Traces from Repository Control Hosts Trace Viewer Hosts Test Engine Front End Test Engine Trace Viewer

27. The SwiBi Client Applet & Java Security • A security profile is kept on primary and secondary intranet web servers in case one of them is not available. • A Swisscom Java security file is distributed with JRE 1.2 and the Java browser plug-in using SMS. This security file contains references to the 2 possible security profiles. • The applet is signed.

29. The development team logo