1 / 32

Building Enterprise Servers for OS/390 with OrbixWeb 

Distributed Object Technology & CORBA/Java Solutions. Building Enterprise Servers for OS/390 with OrbixWeb . by Peter Kanis. Contents. The SwiBi (Swisscom Billing) project. Requirements & Constraints. Architecture. Session Balancing. Security with RACF. Server Framework

abba
Télécharger la présentation

Building Enterprise Servers for 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Contents • The SwiBi (Swisscom Billing) project. • Requirements & Constraints. • Architecture. • Session Balancing. • Security with RACF. • Server Framework • Distributed garbage collection • Multi-threading model. • Logging, monotoring, testing & administration. • Server Design.

  3. The Swisscom Billing (SwiBi) Project • Current billing stream is managed with a dinosaurian host application… • SwiBi should replace this with an intelligent, modern enterprise server. • Unfortunately, the new must run in parallel with the old: • Stuck with a legacy database for COBOL with fixed length fields. • Have to use stored procedures written in COBOL.

  4. Requirements and Constraints (1) • Servers should be deployable on OS/390 USS and AIX. • Clients must be deployable on standardised Windows NT work-stations (Swisscom Workplace 2000). • Servers must support up to 3500 concurrent intranet users with no noticeable performance degradation: • Need multiple parallel servers. • Servers need to be multi-threaded. • Need session balancing.

  5. Requirements and Constraints (2) • Servers should be available from 6:30 to 20:00. • Need a certain amount of fault tolerance. • Need some form of monitoring software. • Need distributed garbage collection. • Users are already defined for the old software and should be authenticated through RACF. • Need an authentication server on OS/390. • Cannot use SSL for internal political reasons. • Should at least have some form of encryption on passwords. • < 1 year from conception to deployment. • Need an efficient RAD environment and language.

  6. DB2 Architecture variant 1 Windows AIX MVS CORBA C++ Client MFC CORBA C++ Servant Oracle/DB2 gateway • Already in use within Swisscom. • Not deployable on OS/390. • No authentication through RACF. • Inadequate throughput to DB. • Long development time with C++. • Poor reliability with MFC.

  7. IMS DB2 Architecture variant 2 Windows OS/390 USS MVS CORBA C++ Client MFC Orbix IMS Gateway • Already in use within Swisscom. • Not deployable on AIX. • Large data blocks cannot be passed through IMS. • Long development time with C++ and COBOL. • Inadequate or inexistent monitoring tools.

  8. DB2 Architecture variant 3 OS/390 USS MVS Windows CORBA C++ Servant IIOP CLI CORBA or RMI Java Client IIOP RMI CORBA or RMI Java Server JDBC • Can be deployed on AIX. • Possible authentication through RACF. • RMI locks us into Java CORBA leaves it open. • Long development time with C++ variant. • Logging and monitoring tools available.

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

  10. OrbixWeb Session Balancer OrbixWeb SwiBi Servants RACF DB2 Architecture OS/390 + AIX OS/390 USS Windows IIOP OrbixWeb Java 2 Client Applet OrbixWeb RACF Authentication IIOP IIOP IIOP SAF MVS JDBC DRDA DB2 Client Enabler AIX Node

  11. Session Balancing (1) • Distributes client sessions between the available servers using a round robin algorithm. • Registered servers uses a “heart-beat” to check in with the balancer. • Supplies an interface for administration • List registered servers. • Stop a server. • Stop a group of servers. • Stop all the servers in a group on a given host. • Integrated into the server framework.

  12. OrbixWeb Session Balancer OrbixWeb SwiBi Servants Session Balancing (2) OrbixWeb Administration Client List Servers etc.. Server Status shutdown Connection info Register check-in OrbixWeb Java 2 Client Applet invocations

  13. Authentication with RACF (1) • The IBM JDK 1.1.8 security classes are not adequate for developing a serious authentication system: • They return erroneous error codes. • There is no way of verifying class/entity rights for a third party. • We wrote our own JNI library for accessing 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);

  14. Authentication with RACF (2) • We couldn’t use SSL: • It would only be necessary for the authentication phase. • The performance loss over the whole application would be too high. • This is an intranet application where SSL would be overkill. • Swisscom has no wish to maintain the necessary certificates. • We created our own password Encryptor: • Uses a mutating cipher with a configurable lifetime. • Random shift expansion algorithm. • An 8 char password results in a 64 byte block.

  15. OrbixWeb RACF Authentication Servant Encryptor OrbixWeb SwiBi Servant Authentication with RACF (3) authenticate() + isMemberOfGroup() encryptPassword() getCipher() getCipher() OrbixWeb Java 2 Client Applet logon()

  16. The Server Framework (1) • All the servers have a common set of requirements: • ORB initialisation. • Application initialisation from properties files. • A multi-threading model. • Distributed garbage collection. • A logging and/or monitoring mechanism. • Possibility of session balancing. • The server framework supplies all this in a re-usable set of Java packages. • Allows fast development of OrbixWeb Servers and clients by simply initialising the Application or Client classes.

  17. ObjectManager ObjectManagerThread The Server Framework (2) BalancerClientThread App. Properties Application ORB static getApplication(); connect(); run(); getAppProperty(); Authenticator Orb Properties WorkerThread RequestQueue OrbixThreadFilter

  18. Client static getClient(); connect(); run(); getAppProperty(); Orb Properties ORB App. Properties The Server Framework (3)

  19. The Server Framework (4) • Default OrbixWeb settings will cause problems with daemon on the server host: • Client connections remain open for 8-10 hours. • Every object is located through the daemon. • After a while the daemon used 1Gigabyte of resources and eventually dies. • The server requires the following settings: • IT_IIOP_USE_LOCATOR=false • IT_IIOP_LISTEN_PORT=0 • The client requires: • IT_KEEP_ALIVE_FORWARDER_CONN=false

  20. Distributed Garbage Collection (1) • Objects connected to the ORB do not get deleted as there is a reference to them in the ORB. • There is no reference counting mechanism implemented in the OMG Java definition for CORBA. • There is no direct access to the ORB object table in OrbixWeb. • Must be automated, we don’t want to have to explicitly call garbage collection methods on the servant objects. • Should run in the finalizer of the client stubs.

  21. Distributed Garbage Collection (2) • Have a standard interface destroyable which declares a destroy method: • The destroy() implementation disconnects the object from the ORB allowing the Java garbage collection to remove it. • All classes except the factory class inherit from this. • We built a post compiler for idl that adds a finalizer to the client classes if they contain the destroy method. • We added an “evictor” thread which disconnects objects after a configurable inactivity time (2 hrs).

  22. Distributed Garbage Collection (3) • The Server Framework maintains a table of objects connected to the ORB. • The table is 2 dimensional, allowing us to parent - child relationship between objects. If a parent is removed, all its children are also.

  23. Logging, monitoring, testing& administration (1) • Debuggers are too invasive to be of any use during testing and leave no permanent record of events. • Require a way of tracing distributed apps for testing. • Require a permanent record of logs. • Traces must be time stamped and contain information on the source of the trace such as Host, Process, Thread, Class, Method and line in the java file. • Require a script driven testing tool for repeatable testing and regression testing.

  24. Logging, monitoring, testing& administration (2) • Require a method of changing the trace level interactively and watching events online without stopping the server. • Need a centralised repository of logs to facilitate administration. • Require the tracing mechanism for testing to be used for logging in production. • Require an tool to easily view and manage trace files in the repository.

  25. Trace Engine Servant Trace Repository Repository Management Servant Khephren 2000 Server Host Test Hosts Process being traced or tested Traces Traces Control TraceEngine class Traces Control Archive, delete etc. Traces from Repository Control Hosts Repository Mgr Hosts Trace Viewer Hosts Khephren Process Monitor Khephren Repository Manager Khephren Trace Viewer

  26. Design (1) • All the servers are based around a singleton factory object that is published to the ORB and is not entered in the object management table. • The factory is the unique entry point into the system and implements any security and administration functionality. • The factory creates the top level objects that implement the application’s business logic. • These top level objects are related 1:1 to the client and are responsible for creating any children needed for the business logic.

  27. Design (2) Server Business Object 3 Client 1 2 Factory 2 1 Client Business Object 3 1 connect, logon and get business object. 2 create business object and add to manager table. 3 invoke operations on business object.

  28. Design (3) • We considered 2 approaches to the design: • A vertical approach where each business object is built from interface to database access as a unit. • A horizontal approach where the application is layered. • We chose the horizontal approach for pragmatic reasons: • It is hard to find programmers who are expert in all the technologies being used. • We had on hand experts in SQL, pure java and CORBA programming. • It is easier to add interfaces to other middleware technologies using a layered approach.

  29. DB2 SwiBi Server 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

  30. 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.swibi.server.bo Application layer com.swisscom.swibi.server.appl Access Object Layer com.swisscom.swibi.server.ao

  31. The SwiBi Team Analysis, Design & Programming Sever: Peter Kanis,Jürgen Fritz, Stefan Fink, Urs Schimming, Urs Badertscher, Markus Streit, Daniel Steiner, Daniel Wildi, Beat Bilang, Bruno Roth Client: Stefan Marty, Felix Boss, Niklaus Rötlisberger, Daniel Wildi Management Hans Brüschweiler, Heinz Bösch

More Related