Enterprise-level Form & DB architektúra

Feladat:
- Képernyő-formokon keresztül kell Oracle - később esetleg MSSQL vagy más? - adatbázisokba adatokat rögzíteni (+valamiféle menürendszer)
- Open-Source/Free alapok, elsődleges követelmény. Ettől még egy másik blogposztban át lehet tekinteni a commercial vonalat is. ;)
- Általános - enterprise-szintű - legyen a megoldás, ahogy a blogposzt címe is hangsúlyozza.
- Vendor-független technológia előnyben. Egy Oracle-Apex ebből a szempontból nem egy jó biznisz.
- Jellemzően CRUD(=Create Read Update Delete) a feladat, de azért jó, ha van perspektíva bonyolultabb üzleti logikára, szebb és/vagy jobb felhasználói képernyő-megjelenítésre, customizálásra.
- 100%-ban (erős) Windows7 munkaállomásokból áll a vállalati környezet, miközben a szerverek már nem annyira (kliens-szerver architektúra előnyben?)
- 100%-ban intranetes megoldás kell, bármiféle internetes megspékelési követelmény nélkül
- Ami specialitás (viszonyítási alapként): Legacy-rendszereknél a drága (alapból és rendes doksi+oktatás nélkül 8 millás) illetve kiváltandó kliens-szerveres Uniface helyére kell más.
- Riportálni nem kell tudni (csak képernyő-formot és menüt kezelni), mert a riportálás Oracle BI-alapú.URL-lel persze egy APEX-ből is ki lehet vezetni egy OBIEE-t, de kérdés, hogy ez mennyire elegáns, vet-e fel szakmai kétségeket.
Emiatt a bulettpoint miatt elmondhatom, hogy nem vagyok annyira offtopik - saját blogomban :))  [Zárójelesen megjegyzendő az nem igazán várható el, hogy ne is tudjon riportálni az eszköz/technológia, csak az maximum, hogy ne legyen égbekiáltó a különbség]

Kiegészítő (jellemzően saját) szempontok:
- Legkisebb „lábnyomú” (footprint), pehelysúlyú (lightweight) legyen: gyors indulású futtató-alkalmazás, kis méretű natív exe előnyben.
- Üzleti logika text-alapon kereshetően, átláthatóan legyen 100%-ban. Egy Oracle Forms .fmb-i kerülendők tehát. ;)
- Atomgyors (hogy növelje a felhasználói élményt)
- Flexibilis legyen a végtelenségig
- 3rdparty library-k integrálása teoretice is, valós gyakorlati életben is.
- Minél könnyebb legyen benne fejleszteni: Java Swing és/vagy SWT-nél és/vagy QT-nél egyszerűbben.
- Minél teljesebb felhasználói élményt adjon rögzítői oldalon.Nálam maximális alázattal - saját egoista szempontjaimról lemondva - az elsődleges fókusz a felhasználón van, aki használná az általam fejlesztett formokat. Inkább én mint fejlesztő és/vagy üzemeltető dolgozzak kicsit többet, mert az én munkám sokkal kevesebb lenne így is összességében.
- Szép legyen a form. Nálam a „szép form” legszebben a régi Delphis 3rdparty bővítményes eszkökészlettel volt implementálható.
- Billentyűzet-támogatás elegáns legyen (ne egerészni kelljen a rögzítőnek).
- Könnyű legyen módosítani a formokat, bővíteni formokkal/alkalmazásokkal a vállat informatikai eszköztárát.
- Könnyű legyen fejleszteni. Egy Java horizontálisan(API-k) és vertikálisan(mélység) a legkomplexebb nyelv. Kérdés, hogy egy .NET és C# mennyivel egyszerűbb. Illetve ahogy a programozási nyelveknél van 3GL/4GL (magasabb szintű programozás nyelvi struktúrák), úgy a formoknál is van magasabb szintű form-használat (kódírási minimalizálással).
- Meglévő vállalati készségek minél jobb újrahasznosítása, minél kevesebb "új" tanulásával.
- Minél kevesebb és/vagy kisebb hibázási lehetőség,
- Minél jobb és gyorsabb debug- meg hibajavítási lehetőségek.
- Könnyű legyen üzemeltetni. Nálam a könnyű egy régi exe lecserélése egy újra például ;) És nem alkalmazás-szerver leállítása, újraindítása, hibák kezelése stb.
- Ad absurdum, a fejlesztő környezet installja is legyen egyszerű: kicsi cuccként, még akár .zip-ből is valamilyen alkönyvtárba kicsomagolhatóan.
- 64-bites natív támogatás (esetleg), kliens-szerver architektúra esetén.
- A fejlesztő környezet minél kevésbé legyen „egzotikus”, abbahagyott fejlesztésű, kevéssé dokumentált stb (esetleg).
- Minél tömegesebben legyen oktatva, elterjedtség szempontjából. Ha már egyszer nem Uniface.
- Legyen magyar szakirodalom. Nem azért, mert a fejlesztők nem tudnak angol szakirodalmat olvasni, hanem, mert magyar szakirodalom megjelenése, kritikus tömegű magyar felhasználói tömeget érint, amelyre a szakkönyvkiadó érdemesnek lát szakkönyvet megjelentetni cost-benefit alapokon.
- Legyen "mainstream" a megoldás. ha már egy drága egyedi Uniface kerül lecserélésre. Az nem jó trend, ha csak egy valaki ért hozzá a vállalatnál, majd ő is elmegy a nagy fluktuáció közepette. De ez csak egy elv: a megoldás szakmaisága, elvszerűsége előrébbvaló ebben a blogposztban.
- "Faltól-falig" számolt költségek minimalitása. Hiába ingyenes egy APEX akár egy Oracle XE-vel is. Ez csak licence költség. Gondoljunk bele MSSQL-nél külön fenn kell tartani egy Oracle adatbázist vassal (ad absurdum négy hardver réteggel: MSSQL,Oracle,Web,Kliens-böngésző). Meg üzemeltetéssel, karbantartással, mainstreamből kilógó szaktudásigénnyel (nem triviális CRUD esetén), munkaidővel, stb.. Amit nem ellensúlyoz eléggé másik oldalon a felhasználói élmény. Nem véletlen, hogy ingyen adja az Oracle annak aki beugrik neki. ;)
- Repository-használat üldözendő technológia, amitől még az APEX sem tudott szabadulni, pedig az Oracle Forms, Reports, Designer is belebukott korábban (illetve némileg párhuzamosan). Egy Oracle BI Suite már nem is Oracle adatbázist használ repository információk alá. ;)
- Bármilyen ActiveX üldözendő technológia
- Opcionálisan érintőképernyő-lehetőség
- Opcionálisan Android-lehetőség

A blogposzt célja:
- a tárgybeli intellektuális szakmai kihívást,
- minél szélesebb körűen és tárgyilagosan, 100%-ban szakmai alapokon végiggondolni a témát,
- perdöntően a magam számára illetve nem "igehirdetés" céllal,
- előnyök-hátrányok vonatkozásában,
- a meglévő információk alapján,
- a tévedés jogát fenntartva,
- a minél maximálisabb tisztánlátás érdekében.
Azaz egész egyszerűen magamnak tartozom avval, hogy leírom a konklúziómat és megosztom.

Elöljáróban:
- Gondolatmenetemben a mi „NEM” irányából közelítek a mi „IGEN” irányába, vagyis ami legkevesebb kompromisszum mellett a legtöbb értéket tudhatja nyújtani az én értelmezésemben.
- Az informatikában – az én tapasztalatom szerint nem nagyon szokott lenni „fekete-fehér” szituáció. Minden előny mellé vaskos hátrányok szoktak párosodni.
- Nagyon ritkán van olyan, mint kivételesen szerencsésen ebben az esetben, hogy ultimate megoldást tudok találni (minden szempontból legjobbat), jelentősebb hátrány nélkül, úgy hogy még súlymátrixot csinálni is feleslegesnek tűnik.


1.    LEGKEVÉSBÉ AJÁNLOTT ARCHITEKTÚRA: háromréteges architektúrába ágyazott: Webserver / J2EE-alkalmazásszerver / Portál-motor

Előny:
* Szakmai mainstream ajánlja
* Magyarországon is van rá tapasztalat
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.
* Free/Open Source
* Enterprise-szintű megoldás

Hátrány:
* Szakmai filozófiám szerint; alapvetően téves koncepció esetünkben. A tágabb internetes világban működő architektúrát egy szűkebb másképpen is viselkedő intranetes világba besuvasztani, annak specialitásainak figyelmenkívül hagyásával nem igazán szerencsés.
* Ráadásul intranetes világban erős túllövés/felüllövés ilyet használni.
* Csípőből kell egy alkalmazásszerver a középső rétegbe (költség), vagy egy meglévőt tovább terhelni.
* Szerver-oldali a terhelés, nem pedig kliens-oldali.
* Fenti miatt: nem a legoptimálisabban skálázható fefelé a megoldás.
* Alkalmazás-frissítés a legnehézkesebb, legköltségesebb: időigénye, potenciális problémái miatt. Ne feledjük külön szakma a deployment, nagyobb cégeknél csak evvel foglalkozó kollégával.
* Javánál szerintem nincs is nehezebb cucc (nyelv+API). Olyan kiterjedtségű és komplexitású.
* Minden szinten óriási overhead tehát
* Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) itt a leginkább fékezett habzású
* Ha újat kell tanulni, nem érdemes a legnagyobbat markolni, ha gyorsaságon és sikerességen van a fő fókusz. Arról már nem is beszélve, hogy a profi Java-tudáshoz évek és/vagy felsőoktatási tapasztalatok kellenek.
* Nem tud előny lenni, hogy Linux-ra is működőképes
* Úgy a legdrágább (beruházás+fejlesztés+üzemeltetés), hogy gyakorlatilag semmi kézzelfogható előnye nincs, hátránya viszont nemkevés.

2.    MINIMUM EGY FOKKAL JOBB ARCHITEKTÚRA: .NET és C#, Free Visual Studio Express Edition-nel vagy C++ és QT

Azt az egy specialitást külön kiemelve, hogy QT-nál van QML az üzleti logikának, ami szimpatikusan vonzó feature lehet.

Pythonnal kombinálva a QT-t már meg lehet gondolni.A kombinációnak van valós hozzáadott értéke esetünkben. Nekem legalábbis tetszik. :)
* Mainstreambe illeszkedik még akár Magyarországom is.
* Gyors-egyszerű
* 3rdparty libek és következményei.
* Jellemző hátrány nélkül.
* STB.

A tárgybeli két cucc érzékelésemben egyformán jó vagy nem jó, azt leszámítva, hogy az előbbi
* elterjedtebb
* egybe összerakott (nem összevadászandó)
* könnyebben tanulható/használható.
* mindez releváns hátrány nélkül a másikhoz képest.

Így a továbbiakban csak NET és C#-t tárgyalom.

Előny:
* Szakmai mainstream másik „best” ajánlata
* Magyarországon is van rá tapasztalat, hogy aktuálisan ezt választják.
* Free és részlegesen Open Source
* Enterprise-szintű megoldás
* 32&64 bit architektúra egyaránt szépen támogatott régóta.
* Van benne data-aware komponenes, más szóval data binding (vizuális kontroll és adat könnyű összerendelhetősége)
* Kliens-oldali terhelést ad, szimpatikusan kétrétegű kliens-szerver architektúrában.
* Tökéletes a skálázás: új felhasználó egyszerűen csak egy új desktop.
* Egyszerű alkalmazásfrissítés: exe-csere
* Elérhető Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) teljesnek mondható
* Ami a tárgyhoz kell, azt messzemenőkig tudja szépen és jól.
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.

Hátrány:
* Túl általános célú, túl nagy overheaddel, túl kevés kézzelfogható előnnyel
* Ha van könnyebb, pehelysúlyúbb,célnak jobban megfelelő eszköz, akkor érdemesebb azt használni.
* Gigantikus (tehát nagyrészt felesleges) cucc, mind install-anyagában (teljes verzióban 4GB-os DVD-t tölt meg), mind erőforrás-használatában.
* Isten összes erőforrása kevés neki. 2GB RAM nem éppen baráti neki.
* ActiveX-szel bővíthető leginkább, ami szerintem üldözendő technológia
* A P/Invoke tudhat problémát okozni, ha nem csak hivogatni kell benne, hanem oda-vissza adatcserélgetni is, adott esetben intenzíven.
* A szükséges API sokkal általánosabb célú és ezért sokkal komplexebb és nehézkesebb, sok kódolási overheaddel.
* Az üzleti logika jó ha textes állományokban van (két irányból is módosíthatóan, kereshetően). Ha ez el is érhető, biztos nem triviális ebben az esetben.
* Tanulás szempontjából majdnem(?) olyan nehéz, sok és komplex, mint a Java
* A legvastagabb magyar könyvek is ebben a témában jelennek meg perdöntően, 1000+ oldalas nagyságrendben és hol van még akkor a referencia.
* Ha el is érhető egyetlen exe az nem triviális, nagy méretű és semmiképpen nem natív.
* Ha újat kell tanulni, nem érdemes a legnagyobbat markolni, ha gyorsaság és sikeresség a fő fókusz. Arról nem is beszélve, hogy az itteni profi tudáshoz évek kellenek.


3.    EGY POTENCIÁLIS ÁM OLVASATOMBAN  NEM AJÁNLOTT LEHETŐSÉG: Oracle-APEX

Előny:
* Magyarországon is van rá tapasztalat
* Van korábbi tapasztalat a vállalatban, házon belül van már: nincs is ellenállás irányába (?)
* Free/Ingyenes, ha már van Oracle (de azért nem nulla költségű)
* Korrekt data binding
* Nagyon egyszerű elkezdeni használni: és ha a default-használat elég, az lehet előny.
* Ha újat kell tanulni egy csapatnak, akkor az eddigiekhez képest ez a legkönnyebb, legtöbb sikerélményt adó (kezdetben legalábbis)
* Kétrétegű architektúra (aminek azért van hátránya is), jól illeszkedik vállalatunk architektúrájába.

Hátrány:
* Szakmai közvélemény kifejezetten nem ajánlja, legtöbbször üldözi vagy megtűri: részben jogosan, részben nem.
* Magyarországi multiknál is megfigyelhető az üldözése: igaz konkréten esetünkben ez kevéssé érdekes szempont.
* Nem vendor-független technológia, ha már nem általános, enterprise-szintűt keresünk.
* Én elképzelésemben egy Oracle-alkalmazáshoz egy kis APEX form-kezelés lehet jó, míg általános célú, sok felhasználós "enterprise" form-kezeléshez már nem jó architektúra, szerintem.
* Elején említett "faltól-falig számolt" összköltségek meglehetősen magasak.
* Mintha tendencia lenne az MSSQL térnyerése, Oracle mellé (vállalatnál is, másutt is). Az APEX viszont csak Oracle mellett tekinthető értelmes alternatívának (mégha FreeTDS-sel, még akár *nix alól is elérhető, még akár egy MSSQL is, még akár szabványos ODBC-vel is) Lásd hozzá az elején taglalt szempontokban részletesebb kifejtett problémákat.
* Adatbázis-oldalon keletkezik a terhelés, miközben az Oracle-szervereknek éppen elég feladatuk van anélkül is a konkrét esetünkben/vállalatunkban.
* Sok felhasználó mellett előjöhetnek szerver-performanciális gondok, miközben kvázi parlagon maradnak a jó kis Win7-es desktopok.
* Rettenetes a skálázása: nemvéletlen, hogy ingyen beetet vele az Oracle. Nem elég gépet bővíteni/venni pluszba, hanem az Oracle licence és support költségek is ugranak, a processzor alapú licencelés miatt. Azért az igaz, hogy egy Oracle XE-t azért nem olyan könnyű kinőni egy adott szint alatt.
* Még alkalmazás-szerverben is sokkal jobb a skálázás 1:8-hoz, mint Oracle-adatbázisban.
* APEX-ben alkalmazott repository technológia olvasatomban üldözendő.Az OBIEE sokkal kultúráltabb. Nem véletlenül: az APEX Oracle-fejlesztés, míg az OBIEE akvirált cucc.
* Elkezdeni az APEX-ben fejleszteni látványosan triviálisan könnyű. A customizálás nagyon nehéz már, már könyvhegyek vannak hozzá. Meglehet nehezebb, mint a .NET és C#, és akkor már ugye.... ;)
* Windows-specifikus végfelhasználói élmény teljessége itt is erősen kérdéses számomra (vizuális elemek, billentyűzethasználat könnyedsége, stb), akárcsak egy Uniface-hez képest is.
* Van egy előnye, ami konkrétan hátrány esetünkben: látványosan tud riportálni, viszont riportoló eszköz már van ugye (OBIEE), amihez ugyan tud link vezetni, de kérdés mennyire elegánsan. Két helyen semjmiképpen nem kéne riportolni. Illetve elég lenne csak a 100% pure form-kezelés megoldása
* Alkalmazás-frissítésben is el tudok képzelni egyszerűbbet.
* Digitalis footprintben is van kisebb.
* Nem tud előny lenni, hogy Linux-ra is működőképes
* Nincs magyar nyelvű szakirodalom, azaz itthon kevéssé használják talán, hogy érdemes lenne magyarítani valamilyen könyvet hozzá.
* Jó szakember elég drága hozzá.


4.    SZERINTEM LEGJOBB ARCHITEKTÚRA: Lazarus-FreePascal kombó

Előny:
* Free/OpenSource, folyamatosan fejlesztett: ez szerintem nagyon fontos, hogy megvan itt is.
* 32&64 bit architektúra egyaránt szépen támogatott régóta.
* Kliens-oldali terhelést ad, szimpatikusan kétrétegű kliens-szerver architektúrában.
* Tökéletes a skálázás: új felhasználó egyszerűen csak egy új desktop.
* Enterprise-szintű megoldás
* Ami legszélesebb értelemben szükséges a feladathoz azt messzemenőkig és a legelegánsabban adja.
* Elérhető Windows-specifikus végfelhasználói élmény (vizuális elemek, billentyűzethasználat könnyedsége, stb) teljesnek mondható, és ami fő ActiveX nélkül.
* Vele elérhető felhasználói élmény, a kereskedelmi Delphi szintjét is meg tudja akár ütni.
* Data Binding alapból adott benne és korrekten.
* Legkisebb digitális lábnyom, pici natív exe stb.
* Egyszerű alkalmazásfrissítés: exe-csere
* Az üzleti logika is tömören, text-ekben, minimális overheaddel reprezentálódik: nagyon könnyű módosítás, beletanulás.
* Customizálás úgy általános, hogy egyszerűségét és eleganciáját koherensen megtartja.
* Azaz APEX-hez kvázi hasonlóan egyszerű az indulás, de a továbblépés már sokkal könnyebb
* Van magyar nyelvű szakirodalom: ami ott fontos szempont, hogy magyar felhasználói igények kritikus tömegét jelezheti.
* A Pascal a legegyszerűbb, legmagasabb szintű, tömegeknek még mindig (legrégebb óta) legtanítottabb nyelv az átlalános célú programozási nyelvek között.
* Könnyebb benne kevésbé hibás programot írni, a nagy átlagnak.
* Case-elágazások szépen magas szinten programozhatók
  case x of
    'a'..'z','A'..'Z':
      writeln('betu');
    '0'..'9':
      writeln('szam');
    '[',']','(',')':
      writeln('zarojel');
    else
      writeln('egyeb jel');
  end;
* Hasonlóan magas szintű IF is, például IN-használattal.
* Nincs feleslegesnek tűnő typecast-követelmény.

Hátrány:
* Én egyet tudok felhozni: szakmai mainstream még nem igazn ajánlja, legalábbis az első kettőhöz képest. Mondjuk azt gyanítom, hogy nem szakmai megfontolásból, hanem információhiányból eredően és/vagy marketing-érdekek mentén inkább elsősorban.

Záróbekezdés:

Szakmai Java-levlistán is megfürdettem a témát, nagy szerencsémre és örömömre 86 levelet generálva a közösségben. :o):

Ott az alábbi alternatívák hangzottak legalább egyszer, perdöntően kronológiai sorrendben..
Amiről a fentebbiekben nem beszéltem azokról egy-egy jellemző mondatot is írtam.

(1) APEX (MSSQL-hez Unix ulatt FreeTDS)
(2) Lazarus+FreePascal
(3) .NET (Visual Studio Express-es) és C#
(4) Web/J2EE-alkalmazás
(5) PHP (ma hallottam mástól)
(6) központi helyen egy jar-ban egy swinges app + webstart vagy bat
(7a) "Ha tényleg nem kell üzleti logika, akkor node.js szerveroldalon az adatbáziskapcsolathoz és ezt REST eleressel ext.js megjelenítés megteszi. Kevés Javascript tudással egy jó programozó indulásnak elég... "Nem mellesleg Ext 4-től MVC alapon tudsz fejleszteni vele (sokkal átláthatóbb lesz az
egész")
(7b) "Egyébként nem lesz megkerülhető a jövőben és egyre több próbálkozás van az OO JS verziók kifejlesztésére, többek közt az általam ma már említett Anders Hejlsberg (programozási nyelv fejlesztő zseni) is nekiállt egynek TypeScript (open source): http://www.typescriptlang.org/"
(7c) "ExtJs ->teljesen független a háttértől, tehát kiszolgálhatja jersey, vagy spring, vagy akar .net is, bármi ami json-t tud előállítani" Ez a megoldás óriási vitát váltott ki a levlistán.
(8) GWT vagy IceFace (vagy PrimeFaces az előbbi lassulása miatt)
(9) "Python és QT - tud exe-be fordulni, tanulhatóságot/használhatóságot, elterjedtséget, sebességet illetően a pályán lehet."
(10) "Groovy és Grails: gyors prototipizálással. Paper prototype: JPA-Spring-Vaadin"
(11) "Én is javasolnék egyet ami még nem volt: Vaadin. (http://www.vaadin.com). Érintőképernyős pluszok, Android-kapcsolat"
(12) "Ha csak a CRUD a feladat, szerintem a Spring ROO jó alternativa lehet. https://vaadin.com/springroo"
(13) "Mi nemrég KendoUI-jal raktunk össze egy alkalmazást, de most lehet, hogy twitter bootstrap-et valasztanánk es jQuery. One page app, szerver oldalom meg amit akarsz. Közötte json rest."
+1 Kódgenerálás topik. Csak azért említem így külön, mert ez is vihart kavart a levlistán. ;)

Utóirat:
A topik nem konstruáló agymenés eredményterméke, hanem való élet konkrétan valós problémájából merített.

Egyébként az Oracle-APEX (+ Oracle XE) nyert,  alapvetően rövid átfutású improvizatív alapokon, indoklás nélkül, hatalmi szóval eldöntve.

De ez semmit nem von le abból, hogy élvezettel foglalkoztam a témával. :)