Distributed Object Technology & CORBA/Java Solutions
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

Building Enterprise Servers on OS/390 with OrbixWeb PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

Distributed Object Technology & CORBA/Java Solutions. Building Enterprise Servers on OS/390 with OrbixWeb. by Peter Kanis. El proyecto Swisscom Billing (SwiBi). La facturación actuál es una applicación dinosaurio en COBOL con pantallas 3270…

Download Presentation

Building Enterprise Servers on OS/390 with OrbixWeb

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Building enterprise servers on os 390 with orbixweb

Distributed Object Technology & CORBA/Java Solutions

Building Enterprise Servers on

OS/390 with OrbixWeb

by

Peter Kanis


El proyecto swisscom billing swibi

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

The SwiBi Requirements (1)

  • Customer Search.

  • Customer data overview.

  • Bill account overview.

  • Contract overview.

  • Bill overview.

  • Bill account modification.


Building enterprise servers on os 390 with orbixweb

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.


Architecture variant 1

Windows

CORBA

C++ Client

MFC

DB2

Architecture variant 1

AIX

MVS

CORBA

C++

Servant

Oracle/DB2

gateway


Architecture variant 2

Windows

CORBA

C++ Client

MFC

IMS

DB2

Architecture variant 2

OS/390 USS

MVS

Orbix

IMS

Gateway


Architecture variant 3

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


Performance considerations

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

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

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


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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.


Building enterprise servers on os 390 with orbixweb

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


Building enterprise servers on os 390 with orbixweb

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

The development team logo


  • Login