Mærsk Data Food&Agro præsenterer

1. Mærsk Data Food&Agro præsenterer

3. Ø90 - et Delphi / CORBA / Java projekt Foredragsholder: Torben Møller Christensen Mærsk Data Food & Agro tmc@maerskdata.dk • Uddannet Datamatiker fra Århus Købmandsskole januar 1992 • Ansat hos Datrix A/S fra 1992 - 1995 • Siden 1995 - ansat hos LEC AS, senere opkøbt af Mærsk Data • 1. januar 2003 - tilknyttet Mærsk Data Food & Agro • Nuværende stillingsbetegnelse: IT Arkitekt

4. Ø90 - et Delphi / CORBA / Java projekt • Agenda: • Baggrunden for projektet • Udfordringerne • Fysisk arkitektur • Prototype • Projektets status • Software-arkitektur • Udviklingsværktøjer / miljø • Erfaringer med CORBA • Sammenligning med andre teknologier • Spørgsmål / svar

5. Ø90 - baggrunden for projektet • Regnskabssystem primært for landbruget. Dog også til enkelte andre erhverv (f.eks. damefrisører og maskinstationer) • Udviklet for Landbruget Rådgivningscenter af LEC • Startet helt tilbage i 1972 !! Dengang hed systemet S72 • I 1986 gik man i gang med en teknisk omlægning af systemet • I 1990 var det omlagte system - Ø90 - klar til drift

6. Ø90 - baggrunden for projektet • Ø90 kører som CICS / Cobol løsning på IBM MVS op mod en DB/2 database på samme platform • Systemet anvendes til registrering af bilag vedrørende driften samt til udskrivning af regnskaber til den enkelte landmand • Bruges ikke af den enkelte landmand. Derimod af konsulenter på landbocentre. Landmanden afleverer alle relevante bilag til centeret, hvorefter de står for indberetning og udarbejdning af regnskaberne

7. Ø90 - baggrunden for projektet • Siden 1997 har Landbrugets Rådgivningscenter overvejet at foretage en ny omlægning til en mere moderne løsning • I juli 2000 gik LEC og Landbrugets Rådgivningscenter så i gang med at diskutere mulige løsninger hvad angår teknologi • Der blev både talt om web-løsning og Windows-baseret løsning • Valget faldt dog ret hurtigt på en Windows-baseret klient pga. systemets natur (meget indberetnings-tungt)

8. Ø90 - baggrunden for projektet • DB/2 databasen skal bibeholdes stort set uændret • Vi skulle altså have en Windows klient til at snakke sammen med DB/2 må MVS • Der blev talt om forskellige alternative løsningsmuligheder. Blandt andet en Delphi klient op mod Cobol programmer på MVS • LEC ville dog hellere i retning af en Java server, og argumenterede derfor for en Delphi - CORBA - Java løsning

9. Ø90 - baggrunden for projektet • LEC havde ingen tidligere erfaringer med denne slags løsninger, hvor der er involveret både Delphi og Java • Derfor blev det i marts 2001 besluttet, at der skulle implementeres en vertikal prototype på et bestemt billede fra Ø90 • Prototypen skulle primært laves for at undersøge performance i arkitekturen • Deadline var 22. juni 2001 for prototypen

10. Ø90 - udfordringerne • Nuværende Ø90 er: • et meget stort system • et system uden svartidsproblemer overhovedet! • et system med mange samtidige brugere (der arbejder intensivt med systemet) • et system som brugerne er meget glade for

11. Ø90 - udfordringerne • Hvorfor så overhovedet omlægge systemet?? • For store begrænsninger i print fra systemet (pga. gammel teknologi). • Mulighed for ”wizards”. • Gerne mulighed for tilkobling af slutbrugeren (landmanden) - evt. via web. • Umoderne brugergrænseflade, hvilket gør det svært for nye brugere.

12. Ø90 - udfordringerne • Lidt tal: • 60 landbocentre med ca. 100 kontorer • ca. 2000 brugere, hvoraf ca. 1400 arbejder intensivt med systemet • regnskaber for ca. 47.000 ejendomme • ca. 83.000.000 CICS transaktioner pr. år • ca. 28.000.000 printsider pr. år (centralt) • ca. 8.000.000 printsider pr. år (lokalt) • ca. 11.000 function points • 15,5 GB database • 120 millioner posteringer

13. Ø90 - fysisk arkitektur • Vi valgte at opbygge systemet som en fysisk three-tier løsning: • database på MVS • forretningslogik i Java på Unix-maskiner • Windows klienter kodet i Delphi • Til at binde klient og forretningsserver sammen valgte vi Borland VisiBroker (bruger i forvejen Delphi fra Borland) • Load-balancering på middletier

14. Delphi (ROAD Delphi) • VisiBroker klient Windows klienter IIOP Sun Solaris maskiner LDir • VisiBroker • Java (ROAD Java) MQ Series JDBC MVS DB/2 BSB / CICS Ø90 - fysisk arkitektur

15. Ø90 - prototype • Der blev udviklet en stress-klient, der kunne simulere et større antal samtidige brugere • Med hensyn til performance, fik vi hver Unix maskine til at trække ca. 38 posteringer pr. sekund, og det skalerede lineært op til de to maskiner • Hele februar måned 2001 (mest travle måned) blev der i det eksisterende system født ca. 7 manuelle posteringer pr. sekund, når man deler ud på en 7 timers arbejdsdag • Der skal så dog også være ”plads” til den øvrige trafik på systemet, men idet vi regner med at starte produktion på 3 Unix-servere skulle der være ”plads” nok

16. Ø90 - prototype • Der blev foretaget 2 ”field-tests”, hvor vi tog ud på to forskellige landbocentre i hhv. Ry og Odder • Her prøvede vi dels at foretage manuelle posteringer, og vi prøvede at køre stress-klienten, så den simulerede det antal brugere, der var på pågældende center • Begge dele kørte upåklageligt - endda samtidig med at medarbejderne på centrene kørte den øvrige kommunikation • Kundens (Landbrugets Rådgivningscenter) eneste kommentar var: ”Sådan skal det også bare køre i produktion”!

17. Ø90 - projektets status • Resultatet af prototypen blev at kunden sagde GO! • 15.10.2001 gik vi så småt i gang • Det er et projekt, der er vurderet til 50.000+ timer ! • 29. september 2003 gik første del af systemet i produktion • Der har været 20 - 25 mand på projektet i det meste af forløbet • Vi er pt. i gang med en tuningsrunde (primært med henblik på at nedbringe CPU-forbrug på mainframe) • Udfordringer med garbage collection i Java-laget

18. Delphi (ROAD Delphi) • VisiBroker klient Windows klienter IIOP Sun Solaris maskiner LDir • VisiBroker • Java (ROAD Java) MQ Series JDBC MVS DB/2 BSB / CICS Ø90 - software-arkitektur

19. Ø90 - software-arkitektur • Ø90 server-applikationen er udviklet i Java (jdk version 1.3.1) • Den anvendte ORB er VisiBroker fra Borland • Serveren er udviklet under et LEC udviklet Java framework kaldet ROAD Java (ROAD = Rapid Objectoriented Application Development) • ROAD Java blev påbegyndt i 1999 og er løbende blevet videreudviklet • ROAD Java understøtter stand-alone løsninger, RMI server-applikationer, EJB server-applikationer samt CORBA server-applikationer og har indtil nu været anvendt i 6 forskellige projekter

20. CORBA-kald Facade X CM Facade X Controller C1 A -Home Domæne A B -Home Domæne B C -Home Domæne C JDBC JDBC Ø90 - software-arkitektur

21. CORBA-kald Facade X CM Facade X Impl Controller C1 Impl A -Home Domæne A B -Home Domæne B C -Home Domæne C C -Home Impl JDBC JDBC Domæne C Impl Ø90 - software-arkitektur Facade X Impl Body Controller C1 Impl Body

22. Klient Sub-system Kontoplan Sub-system Kasseregistrering FacadeCM Afsender FacadeCM Anvender Facade dk.lec.o90.kontoplan.server KontoController Landskonto Kredskonto Ejendomskonto dk.lec.o90.kontoplan.serverinterface Ø90 - software-arkitektur • Opdeling af systemet i sub-systemer:

23. Delphi (ROAD Delphi) • VisiBroker klient Windows klienter IIOP Sun Solaris maskiner LDir • VisiBroker • Java (ROAD Java) MQ Series JDBC MVS DB/2 BSB / CICS Ø90 - software-arkitektur

24. Ø90 - software-arkitektur • Ø90 klient-applikation er udviklet i Delphi version 6 fra Borland • Klient ORB'en er ligeledes VisiBroker • Klienten er udviklet under et LEC udviklet Delphi framework kaldet ROAD Delphi (ROAD = Rapid Objectoriented Application Development) • ROAD Delphi blev påbegyndt i 1996 og er løbende blevet videreudviklet • ROAD Delphi understøtter stand-alone løsninger, two-tier client / server løsninger samt klient til three-tier løsninger (Cobol eller Java server) • ROAD Delphi har indtil nu været anvendt i 12 forskellige projekter

25. TLECCorbaObject TLECCorbaFacade TKontoStateCO TKontoplanFacadeCO CORBA kald state retur Ø90 - software-arkitektur Skærmbillede

26. Delphi (ROAD Delphi) • VisiBroker klient Windows klienter IIOP Sun Solaris maskiner LDir • VisiBroker • Java (ROAD Java) MQ Series JDBC MVS DB/2 BSB / CICS Ø90 - software-arkitektur

27. Windows klient. Delphi 3. IOR retur Visibroker klient Middletier (unix maskine) 2.Bed om IOR(HTTP) 7. Referenceretur Web-server (Apache) 11. Kald metoder 8. Opret facadeobjekt 5.Opret Session 4. Connect til SessionBrokervia CORBA (udfra funden IOR). sessionBroker.ior fil 10. Referenceretur. 1. Ved server-opstart skrives IORi fil. SessionBroker (singleton) Facade X 9. Opret Session 6. Opret A -Home Domæne A B -Home Controller C1 Domæne B C -Home Domæne C JDBC JDBC

28. En sådan struct kan stamme fra et vilkårligt antal domæne- objekter på serveren. Den resulterer i ét ”domæne” objekt på klienten. Ø90 - software-arkitektur • Eksempel på IDL:struct KontoState • { • string id; • char ejerNiveau; • long kontoplanNummer; • . . . . • }; • typedefsequence<KontoState> KontoStateArray; • struct ListKontiSoegeParamState • { • string id; • . . . . • }; • interface KontoplanFacade • { • KontoStateArray listKonti(in ListKontiSoegeParamState parm); • };

29. Ø90 - udviklingsværktøjer / miljø • Ø90 klient-applikation er udviklet i Delphi version 6 fra Borland • Ø90 server-applikationen udvikles ved hjælp af IntelliJ IDEA - et Java IDE • Til bygning bruges Jakarta ANT • Når først hele udviklingsmiljøet er sat op, kan alt hentes fra versionsstyringsværktøjet og bygges i én kommando • Oversætter både klient, server samt JavaDoc • Der opbygges unit-test til al server-logik. Dette gøres vha. Junit test framework, og sikrer bl.a.: • at server-programmørerne kan færdiggøre en opgave uden en ”klient-mand” • når ”klient-manden” begynder at bruge et stykke server-logik har det en høj kvalitet - det er jo allerede testet!

30. Klient Sub-system Kontoplan Sub-system Kasseregistrering FacadeCM Afsender FacadeCM Anvender Facade dk.lec.o90.kontoplan.server Test-stub KontoController Landskonto Kredskonto Ejendomskonto dk.lec.o90.kontoplan.serverinterface Ø90 - udviklingsværktøjer / miljø

31. Ø90 - udviklingsværktøjer / miljø • Unit-tests kan optionelt afvikles på en lokal PostgreSQL database: • der foretages automatisk kloning af tabellerne fra DB2 på mainframe til den lokale PostgreSQL database (struktur) • herefter opretter testen selv sine data • den fortsatte afvikling køres nu lokalt • efter endt test stilles automatisk tilbage til DB2 (aht. næste test i en evt. rækkefølge) • testen kører på denne måde ca. 6 gange så hurtigt, man undgår konflikter med andre unittests, der afvikles samtidig, og mængden af data er meget mere overskuelig

32. Ø90 - udviklingsværktøjer / miljø • Hver nat bliver hele Ø90 projektet automatisk trukket ud af PVCS, oversat, unittestet og der bliver genereret JavaDoc • Principper omkring PVCS: • Alt i PVCS skal kunne oversætte • Ydermere skal det fungere i en udstrækning, så det ikke generer andre udviklere • Der må ikke være hints eller warnings (hverken ifm. oversættelse af programmer eller JavaDoc). • De natlige bygninger har givet en utrolig høj grad af desciplin omkring disse principper !!

33. Ø90 - udviklingsværktøjer / miljø • Til at modellere forretningsmodeller anvendes CASE værktøjet Qualiware Lifecycle Manager (QLM) • Der laves først en logisk analysemodel af vores analyse-medarbejdere • Den logiske model brydes om til henholdsvis en klient- og en server-model. Dette gøres af programmøren • Der genereres kode på baggrund af de tekniske modeller

34. LEC-properitært format XMI udtræks- format ROAD Delphi generator Facade X Domæne A Qualiware (klient model) IDL filer Facade X impl body Controller C1 impl body Domæne A A -Home Facade X Controller C1 Qualiware (server model) Facade X CM Domæne A impl A -Home impl ROAD Java generator Qualiware (logisk model) 100% genereret Genereret 1. gang 100% manuelt 100% genereret + implementation (kan regenereres)

35. Ø90 - mapning mellem modeller • Domæne-klasser på serveren svarer stort set 1-til-1 til de bag ved liggende tabeller (én tabel = en domæneklasse). • ”gammel” database • kun teknisk id på nye tabeller • ingen nedarvning indenfor domæneklasser • Der kan være meget stor forskel mellem klientmodel og servermodel

36. TKontoStateCO 1000 15 L R L L L klient KontoState 1000 15 L R L L L Landskonto 1000 15 Å R Å Å * 1000 00 Å Å Å Å L Java-objekter 1000 15 Å * L * * 1000 00 Å * * L * Kredskonto 1000 15 L * * * * Ejendomskonto H8921.LKTOPLAN 1000 15 Å R Å Å * 1000 00 Å Å Å Å L database H8922.KKONTI 1000 15 Å * L * * 1000 00 Å * * L * H8923.EKONTI 1000 15 L * * * *

37. Ø90 - erfaringer med CORBA • Det er svært at komme i gang med! • eksempelvis havde vi store problemer med at kontakte vores server-applikation, da der pludselig kom en firewall ind i mellem vores klient og server • det skyldtes at vi anvendte en del af VisiBroker, der hedder OSAgent til at finde serveren. Denne bruger UDP Broadcast til at finde CORBA objekterne • det viste sig at være umuligt at styre dette, hvorfor vi i stedet nu slår IOR’en op via HTTP (der stort set altid kan gå igemmen en firewall)

38. Ø90 - erfaringer med CORBA • Det kan virke rimeligt ”hard-core” når man kommer helt ned i ”sovsen” • Dette er ikke godt, når man er mange på et projekt (pt. er vi 7 programmører) • Det er derfor en stor fordel med et framework, der hjælpe med at pakke CORBA kompleksiteten ind. Vi understøtter således automatisk ind- og udpakning af de komplekse CORBA typer, der kommunikeres mellem vores klient og server

39. Ø90 - erfaringer med CORBA • Når man så først er kommet i gang, udmærker CORBA (i hvert fald med VisiBroker) sig ved at være utroligt hurtig og utroligt stabilt !!

40. Ø90 - sammenligning med andre teknologier • I forhold til Enterprise Java Beans (EJB), har CORBA følgende fordele / ulemper: • CORBA er mere komplekst at komme i gang med • CORBA er væsenligt billigere i server-licenser i forhold til en kommerciel application server (f.eks. BEA WebLogic) • i CORBA har man langt større frihedsgrader - man kan f.eks. lave multi-trådning, hvad man ikke må i EJB verdenen • færre indbyggede services i CORBA (kan dog tilkøbes). • CORBA er sandsynligvis hurtigere • CORBA er platforms- og sprog-uafhængigt, hvor EJB kun er platforms-uafhængigt • CORBA er en ældre og langt mere velafprøvet teknologi

41. Ø90 - sammenligning med andre teknologier • I forhold til SOAP, har CORBA følgende fordele / ulemper: • CORBA er mere komplekst at komme i gang med • CORBA er dyrere (det er muligt at lave SOAP applikationer med meget få midler) • CORBA er meget hurtigere • CORBA er en ældre og langt mere velafprøvet teknologi, hvor SOAP er meget ung • SOAP udmærker sig ved at kommunikere over HTTP

42. Ø90 - sammenligning med andre teknologier • I forhold til COM, har CORBA følgende fordele / ulemper: • CORBA er platforms-uafhængigt, hvor COM er begrænset til MS platformen (med undtagelse af enkelte wrapper-produkter - f.eks. JIntegra).

43. Spørgsmål / svar