mærsk data food&agro præsenterer
DESCRIPTION
Mærsk Data Food&Agro præsenterer. Ø90 - et Delphi / CORBA / Java projekt. Foredragsholder: Torben Møller Christensen Mærsk Data Food & Agro [email protected]. Uddannet Datamatiker fra Århus Købmandsskole januar 1992 Ansat hos Datrix A/S fra 1992 - 1995 - PowerPoint PPT PresentationTRANSCRIPT
Mærsk Data Food&Agro præsenterer
Ø90 - et Delphi / CORBA / Java projekt
Foredragsholder:
Torben Møller ChristensenMærsk Data Food & [email protected]
• 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
Ø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
Ø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
Ø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
Ø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)
Ø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
Ø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
Ø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
Ø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.
Ø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
Ø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
Ø90 - fysisk arkitektur
Windows klienterIIOP
• Delphi (ROAD Delphi)• VisiBroker klient
DB/2MVS
BSB / CICS
MQ Series
Sun Solaris maskiner
LDir
• VisiBroker• Java (ROAD Java)
JDBC
Ø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
Ø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”!
Ø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
Ø90 - software-arkitektur
Windows klienterIIOP
• Delphi (ROAD Delphi)• VisiBroker klient
DB/2MVS
BSB / CICS
Sun Solaris maskiner
LDir
• VisiBroker• Java (ROAD Java)
JDBC MQ Series
Ø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
Ø90 - software-arkitektur
Facade X
Facade X CMCORBA-kald
Controller C1
Domæne A
A -Home
Domæne B
B -Home
Domæne C
C -Home
JDBCJDBC
Ø90 - software-arkitektur
Facade X Impl
Facade X CMCORBA-kald
Controller C1 Impl
JDBCJDBC
Facade X Impl Body
Controller C1 Impl Body
Domæne A
A -Home
Domæne B
B -Home
Domæne C
C -Home
Domæne C Impl
C -Home Impl
Ø90 - software-arkitektur
FacadeCM
Klient
Landskonto Kredskonto Ejendomskonto
KontoController
Sub-system Kontoplan
Sub-system Kasseregistrering
FacadeCM
• Opdeling af systemet i sub-systemer:
Afsender
Anvender Facadedk.lec.o90.kontoplan.server
dk.lec.o90.kontoplan.serverinterface
Ø90 - software-arkitektur
Windows klienterIIOP
• Delphi (ROAD Delphi)• VisiBroker klient
DB/2MVS
BSB / CICS
Sun Solaris maskiner
LDir
• VisiBroker• Java (ROAD Java)
JDBC MQ Series
Ø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
Ø90 - software-arkitektur
Skærmbillede
TKontoplanFacadeCO
CORBA kald
TKontoStateCO
state retur
TLECCorbaObject
TLECCorbaFacade
Ø90 - software-arkitektur
Windows klienterIIOP
• Delphi (ROAD Delphi)• VisiBroker klient
DB/2MVS
BSB / CICS
Sun Solaris maskiner
LDir
• VisiBroker• Java (ROAD Java)
JDBC MQ Series
Middletier (unix maskine)
Windows klient.Delphi
Visibroker klient
Web-server (Apache)
3. IOR retur
2. Bed om IOR(HTTP)
SessionBroker(singleton)
sessionBroker.ior fil
1. Ved server-opstart skrives IORi fil.
4. Connect til SessionBrokervia CORBA (udfra funden IOR).
5. Opret Session
Session6. Opret
7. Referenceretur
8. Opret facadeobjekt
10. Referenceretur.
11. Kald metoder
9. OpretFacade X
Domæne A
A -Home
Domæne B
B -Home
Domæne C
C -Home
Controller C1
JDBCJDBC
Ø90 - software-arkitektur
• Eksempel på IDL: struct KontoState
{
string id;
char ejerNiveau;
long kontoplanNummer;
. . . .
};
typedef sequence<KontoState> KontoStateArray;
struct ListKontiSoegeParamState {
string id;
. . . .
};
interface KontoplanFacade
{
KontoStateArray listKonti(in ListKontiSoegeParamState parm);
};
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 - 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!
Ø90 - udviklingsværktøjer / miljø
FacadeCM
Klient
Landskonto Kredskonto Ejendomskonto
KontoController
Sub-system Kontoplan
Sub-system Kasseregistrering
FacadeCM Afsender
Anvender Facadedk.lec.o90.kontoplan.server
dk.lec.o90.kontoplan.serverinterface
Test-stub
Ø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
Ø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 !!
Ø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
Qualiware(logisk model)
Qualiware(klient model)
Qualiware(server model)
LEC-properitærtformat
XMI udtræks-format
ROAD Delphigenerator
ROAD Javagenerator
100% genereret Genereret 1. gang 100% manuelt
Facade X
Domæne A A -Home
Controller C1
Facade X impl bodyController C1
impl body
Domæne A impl A -Home implFacade X CM
100% genereret + implementation (kan regenereres)
Facade X Domæne A
IDL filer
Ø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
1000 15 L * * * *
1000 15 Å * L * * 1000 00 Å * * L *
1000 15 Å R Å Å * 1000 00 Å Å Å Å L
1000 15 Å R Å Å *
1000 15 Å * L * *
1000 15 L * * * *
1000 00 Å Å Å Å L
1000 00 Å * * L *
H8921.LKTOPLAN
H8922.KKONTI
H8923.EKONTI
Landskonto
Kredskonto
Ejendomskonto
1000 15 L R L L LKontoState
1000 15 L R L L LTKontoStateCO
databaseJava-objekter
klient
Ø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)
Ø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
Ø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 !!
Ø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
Ø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
Ø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).
Spørgsmål / svar