Crear un servidor moderno con OrbixWeb para OS/390 USS por Peter Kanis Distributed Object Technology & CORBA/Java Solutions

Crear un servidor moderno con OrbixWeb para OS/390 USS

porPeter Kanis

Distributed Object Technology & CORBA/Java Solutions

Contenido• El proyecto SwiBi.• Restricciones y limitaciones.• Arquitectura.• Diseño.• Herramientas y productos.• Modelo de “multi-threading” dinámico.• Equilibrado de sessiones.• Seguridad con RACF.• Configuración del OS/390 USS.


El proyecto Swisscom Billing (SwiBi)

• La facturación actuál es una aplicación dinosaurio en COBOL con pantallas 3270…

• SwiBi debe sustituir éste con una aplicación moderna i inteligente.

• SwiBi debe coexistir con la antiquedad durante un cierto tiemo:– La base de datos esta hech para COBOL con

CHAR(n), ningún VARCHAR.


Los requisitos SwiBi

• Busquedad de cuentas por– Varios identificadores de cliente,– N° de telefono,– Dirección,– N° de cuenta y/o N° de factura.

• Vista, creación y modificación de cuentas• Vista, creación y modificación de contatos.• Vista y modificación de facturas.• Vista historica de cuentas y contratos.


Restricciones y limitaciones (1)

• Pueden haber hasta 3500 clientes CORBA que conectan con el/los servidor(es):– Con un servidor CORBA, este rendimiento no es

possible.

– Hace falta alguna forma de equilibrado de sessiones entre los servidores..

– Necesitamos ejecutar transacciones en paralelo (RRSAF).


Restricciones y limitaciones (2)• La base de datos es un classico embrollio

“legacy” con cerca de 1500 tabelas:– Los nombres de tabelas y columnas cambian

mientras renuevan la base de datos.– Tenemos que utilizar “stored procedures” en

COBOL (DB2 5.1 no comprende Java).

• Los utilizadores estan definidos en RACF:– Hay que autentificar los utilizadores con RACF.


CORBAC++

ServantO

racle/DB

2gatew

ay

CORBAC++ Client

MFC

Windows AIX OS/390/MVS

DB2

Arquitectura variante 1


CORBAC++ Client

MFC

Windows

OrbixIMS

GatewayIMS DB2

OS/390 USS MVS



CORBAor RMI

Java Client

Windows

DB2

MVSOS/390 USS

CORBAC++

Servant

CORBA orRMI Java

Server

IIOP

IIOP/RMI

CLI

JDBC



Arquitectura Final

OrbixWebJava 2Client Applet

Windows OrbixWeb

SessionBalancer

OrbixWebRACF

AuthenticationServant

OrbixWebSwiBi

Servants

OS/390 USS OS/390 MVS

DB2

RACFSAF

IIOP

IIOP

IIOP

JDBCRRSAF


Arquitectura Alternativa

OrbixWebJava 2Client Applet

Windows

OrbixWebRACF


OS/390 USS

OS/390 MVS

DB2

RACF

SAF

IIOP

IIOP

IIOP

DRDA

OrbixWebSessionBalancer

OrbixWebSwiBi

Servants

JDBC

DB2 ClientEnabler

AIX SP2 Node


El Diseño• Diseño vertical

– Cada “Business object” esta desarrolado en un “package” desde el IDL hasta el JDBC.

– Los programadores tienen que conocer todas la technologias utilizadas.

• Diseño horizontal:– Cada technologia esta desarrollado en capas

independientes:– Los programadores pueden estar repartidos

según sus conocimientos.


Ventajas del diseño horizontal

• La logica comercial está decoplada del CORBA, y resulta facil añadir otros interfazes, por ejemplo RMI.

• Equipos independientes pueden desarollar cada capa.

• La estructura interna de la aplicación es clara.


El diseño horizontal

• Una capa CORBA BOA conteniendo el interfaz sin logica (pass-through).

• Una capa “Application” implementando las clases “Factory” y “Controlador”.

• Una capa “Business” implementando la logica y las reglas comerciales.

• Una capa de “Access” implementando la funcionalidad de acceso a DB2 con JDBC.


Capas del servidor SwiBi (1)

CORBA IDL layercom.swisscom.swibi.server.boa

Business Object layercom.swisscom.swibi.server.bo

Access Object Layercom.swisscom.swibi.server.ao

Application layercom.swisscom.swibi.server.appl

Java CORBA Client

DB2


Capas del servidor SwiBi (2)

CORBA IDL layercom.swisscom.swibi.server.boa

Java CORBA Client

RMI layercom.swisscom.swibi.server.rmi

Java RMI Client

Business Object layercom.swisscom.swibi.server.bo

Access Object Layercom.swisscom.swibi.server.ao

Application layercom.swisscom.swibi.server.appl

DB2


Herramientas y productos (1)

• VisualAge for Java v2.0– Desarollo de servidor.– Clientes Windows NT.– Repositorio en AIX 4.3.

• JBuilder v3– Desarollo del Applet Java 2.

• Test Engine v4.3 for Java– Trazado para pruebas y “logging” en producción.– Calculo de estatisticas de rendimiento.


Arquitectura del Test Engine

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


Herramientas y productos (2)

• OrbixWeb v3.2– Desarollo de servidor/cliente en Windows NT.– Instalación ínicial en AIX.– Instalación final en OS/390.

• JDBC + DB2 CAE (AIX/NT)– Para accesso al DB2 (NT, AIX y OS/390).

• JDK 1.1.8– OS/390 y AIX.


¿Porque JDBC en vez de SQLJ?

• No existía SQLJ cuando hemos empezado el proyecto.

• Las pruebas que hicimos demostraron que no hay ganancia significativa de rendimiento com SQLJ.

• Swisscom esta modificando la base de datos y cada cambio supone una recompilación y instalación.

• La SQL esta contenida en ficheros “property” así podemos modificarlo facilmente.


El processo de desarrollo (1)

• El codigo del servidor se desarolla con IBM VisualAge for Java (Windows NT), El cliente con Borland JBuilder v3 (Windows NT).

• Los ficheros Java del cliente estan importatos en el repositorio del VisualAge.

• Los ficheros IDL estan compilados para el servidor y client y los “package” importatos en el repositorio del VisualAge.

• Los ficheros IDL y properties estan importatos en el repositorio del VisualAge como comentarios de methodos en una “pseudo”clase.


• El codigo contiene trazados Test Engine para las pruebas.

• Las clases estan exportados al AIX y comprobadas.• Las clases estan copiadas al USS y comprobadas.• Las pruebas tienen dos etapas:

– Utilizando un cliente “Test Engine” con scripts (repeatable tests).

– Utilizando el applet Java 2.


El processo de desarrollo (2)

Multi-threading dinámico (1)

• Como la carga varia mucho y los recursos CPU etc. del OS/390 son caros, hemos desarrollado una fuente dinámica de threads:– Lanzamos un numero minimo configurable de

threads formando una fuente fija.– Al incrementar la carga, lanzamos nuevos threads

hasta un maximo configurable. Estos forman la fuente dinámica.

– Un thread monitor assegura que los threads de la fuente dinámica mueren cuando han estado sin trabajo durante un tiempo configurable.


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();

Diseño de la fuente dinámica de threads


Multi-threading dinámico (2)

• Hemos hecho un “package” de estas clases.• Con el, se puede escribir el main de un servidor

OrbixWeb con un minimo de 3 invocaciones de la clase Application.

• Los 5 Servidores OrbixWeb que hemos construido utilizan esta arquitectura :– SwiBi Server.– SwiBi Session Balancer.– RACF Authentication Server (en producción)– Test Engine Server (en producción)– Test Engine Repository Manager (en producción)


Equilibrado de Sessiones (1)

• El equilibrado de carga entre servidores no es razonable.

• En general, cada cliente hace mas o menos el mismo trabajo:– Equilibración de los sessiones entre los sevidores basta.

• Hemos construido un Equilibrador de Sessiones:– Los servidores se registran con el “Balancer”.– El “Balancer” comprueba regularmente la existencia de los

servidores (ping).– El “Balancer” se encarga de parrar los servidores.



OrbixWebJava 2

Client Applet

OrbixWebSessionBalancer

OrbixWebSwiBi

Servants

bind +getServerName()

Implementation Name +Host name

registerServer()shutdown()ping()

bind + invocations

Equilibrado de Sessiones (2)


Seguridad con RACF (1)• Las clases seguridad RACF de IBM JDK 1.1.8 estan muy mal

diseñadas:– Codigos error del sistema erroneos.

– Imposibilidad de verificar los derechos de un “Userid” en una clase de seguridad.

• Creamos nuestro proprio JNI para RACF:– void authenticate( userId, password);

– void changePassword(userId, oldPassword, newPassword);

– boolean isMemberOfGroup( userId, group);

– boolean canRead( userId, securityClass, entityName);

– boolean canUpdate( userId, securityClass, entityName);

– boolean canAlter( userId, securityClass, entityName);

– boolean canControl( userId, securityClass, entityName);


Seguridad con RACF (2)• No pudimos utilizar SSL:

– Solamente hace falta para la autentificación.

– El efecto negativo al rendimiento si la totalidad del sistema utiliza SSL.

– Estos son aplicaciones intranet.

– Swisscom no quiere mantener los certificados necesarios.

• Creamos nuestro proprio Encryptor para los password:– cifra mutable que cambia cada n minutos (configurable).

– “Random shift expansion algorithm”.

– Creamos un bloque de 64 bytes del los 8 caracteres del password.


Seguridad con RACF (3)

OrbixWebJava 2

Client Applet

OrbixWebRACF


getCipher()

Encryptor

OrbixWebSwiBi

Servant

encryptPassword()

logon()

getCipher()authenticate() +isMemberOfGroup()

Configuación del OS/390 (1)

• Problemas con servidores Java:– Requiere mucho tiempo CPU para empezar y el

OS/390 reduce su prioridad hasta el minimo possible.

– Requiere bastantes recursos, threads, memoria, connecciones DB2 etc., hace falta muchos MIPs.

– Los administradores “host” piensan en technología 1970: transacciones cortos. Es muy estraño para ellos de tener un processo que puede durar dias, ver semanas y ademas que los “end users” no connectan al la base de datos.


Configuación del OS/390 (2)

• Soluciones:– Lanzar cada servidor con un user único utilzando

cron y un REXX script con setuid.– Installar 2 periodos de prioridad al user, uno mas

bajo para el lanzamiento, y un segundo mas alto para “run-time”.

– Quitar el control MVS que mata processos cuando utilizan demasiado CPU (SIGXCPU).

– Incrementar los recursos dedicados al Unix System Service.


Nuestro logo


Documents

Crear un servidor moderno con OrbixWeb para OS/390 USS por Peter Kanis Distributed Object Technology & CORBA/Java Solutions