View
220
Download
2
Category
Tags:
Preview:
Citation preview
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
ay
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
Windows OrbixWeb
SessionBalancer
OrbixWebRACF
AuthenticationServant
OrbixWebSwiBi
Servants
OS/390 USS OS/390 MVS
DB2
RACFSAF
IIOP
IIOP
IIOP
JDBCRRSAF
Alternate Application Architecture
OrbixWebJava 2Client Applet
Windows
OrbixWebRACF
AuthenticationServant
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
Recommended