Building Enterprise Servers on OS/390 with OrbixWeb

byPeter Kanis

Distributed Object Technology & CORBA/Java Solutions

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.

The SwiBi Requirements (1)

• Customer Search.

• Customer data overview.

• Bill account overview.

• Contract overview.

• Bill overview.

• Bill account modification.

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.

CORBAC++

ServantO

racle/ DB

2gatew

a y

CORBAC++ Client

MFC

Windows AIX MVS

DB2

Architecture variant 1

Architecture variant 2

CORBAC++ Client

MFC

Windows

OrbixIMS

GatewayIMS DB2

OS/390 USS MVS

Architecture variant 3

CORBAor RMI

Java Client

Windows

DB2

MVSOS/390 USS

CORBAC++

Servant

CORBA orRMI Java

Server

IIOP

IIOP/RMI

CLI

JDBC

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.

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.

Final Application Architecture

OrbixWebJava 2Client Applet

WindowsOrbixWebSessionBalancer

OrbixWebRACF

AuthenticationServant

OrbixWebSwiBi

Servants

OS/390 USS OS/390 MVS

DB2

RACFSAF

IIOP

IIOP

IIOP

JDBCRRSAF

Alternate Application Architecture

OrbixWebJava 2Client Applet

WindowsOrbixWeb

RACFAuthentication

Servant

OS/390 USS

MVS

DB2

RACF

SAF

IIOP

IIOP

IIOP

DRDA

OrbixWebSessionBalancer

OrbixWebSwiBi

Servants

JDBC

DB2 ClientEnabler

AIX SP2 Node

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.

SwiBi Servant layering (1)

CORBA IDL layercom.swisscom.swibi.server.boa

Business Object layercom.swisscom.server.bo

Access Object Layercom.swisscom.server.ao

Application layercom.swisscom.swibi.server.appl

Java CORBA Client

DB2

SwiBi Servant layering (2)

CORBA IDL layercom.swisscom.swibi.server.boa

Java CORBA Client

RMI layercom.swisscom.swibi.server.rmi

Java RMI Client

Business Object layercom.swisscom.server.bo

Access Object Layercom.swisscom.server.ao

Application layercom.swisscom.swibi.server.appl

DB2

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.

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.

remote

Intranet

Client Server

SwibiControllerImpl

SwibiControllerAppl

BillAccountImpl BOBillAccount

BOContext1 per SwibiCtrl

BOAuthorization1 per SwibiCtrl

SwibiFactoryImplSingleton

SwibiFactoryApplSingleton

ApplicationCORBA IDL Business

Invoke

Connect to

Create (Numbers refer to creation sequence)

Object Reference

2

at Serverstartup

11

2

34

PaymentMethodImpl BOPaymentMethod

12

SwiBi Servant layering detail

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.

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.

Application ORB

RequestQueue App. PropertiesOrb PropertiesMonitorThreadWorkerThread

MessageQueue

OrbixThreadFilter

1

1

1

1 n

n 1

1

1

111

1

1

1

static getApplication();connect();run();getAppProperty();

Re-usable dynamic thread pool design

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.

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.

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.

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.

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.

Test Engine System Architecture

Test Hosts

Process being traced or tested

TestEngine class

TracesControl

Test Engine Server Host

TraceRepository

Repository Management

Servant

Test EngineServant

Control Hosts

Test EngineFront End

Traces

Control

Trace ViewerHosts

Test EngineTrace Viewer

Traces fromRepository

Traces

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.

The development team logo