PRG: architektura: vstup a výstup
Osobní poznámka: sám jsem z nutnosti zaměřením spíše administrátor než programátor (bohužel).
Proto mě zajímají konkrétní problémy, které jsou zatím možná trochu předčasné:
- jak se to bude instalovat
- jak se budou přidávat/ubírat moduly
- jak se budou přidávat uživatelé
- může jeden uživatel používat různé klienty (Linux/Windows, cmdline/gui)
- zůstane mu pak jeho nastavení = pohledy, ...
- kam se přidají tiskárna(y) a jak se na ni(ně) bude tisknout
...
To je i není o programování účetnictví ale o programování celého systému ano.
Plus další věc: jak se to bude reálně ladit.
Dohodli jsme se na takovéhle architektuře:
[SQL server] <--TCP/IP--> [Aplikační server] <--TCP/IP--> [klienti]
Přemýšlím ale, kam do systému patří tisk.
Příklad jednoduchého scénáře interakce se systémem:
Sedím u stroje, z příkazové řádky zadám právě došlou
fakturu za telefon (podle vzoru, který jsem si už
někdy dříve vyrobil) a rovnou chci vygenerovat příkaz
k zaplacení. To by mohla zvládnout jedna řádka stylu:
ucto zaplat telefon 19.7.2001 27.7.2001 623.50 1234567890
Vypadnout by mohlo číslo dokladu, které opíšu na tu fakturu,
a z tiskárny vyjede převodní příkaz, který podepíšu, rozstřihnu
a odnesu do banky. Má-li někdo internet banking, může to
místo tisku připravit někam správná data pro jeho systém
a on je v tom systému pak přebere, potvrdí a pošle.
Z tohoto scénáře mi vypadává pár návrhů na architekturu:
1. AS (= aplikační server)
- měl by mít možnost zadávání vzorů na opakující se akce
=> ukládací prostor na SQL serveru (-> datový model)
=> globální a uživatelské, které by mělo přednost
- měl by podporovat výstupní (! ne tiskové) fronty,
do nichž může zadávat výstupní joby (vše čisté,
předem dobře definované XML)
- měl by mít možnost nechat různé klienty (= klientské
programy) i uživatele (= skutečné osoby) ukládat
si data na SQL server, aby VŮBEC NIC nemuselo být
uloženo na stanicích
2. specializovaní klienti
- tiskový klient:
- umí si AS říci o konkrétní frontu,
dozví se, které jsou v ní joby, možná i nějak
filtrovaně
- umí vyzvednout konkrétní job (?práva) a AS
říci, že si ho převzal k tisku
- následně může požádát AS o svoje vlastní pomocná
nastavení
- umí job zformátovat (TeX, Word, ...?) a poslat na výstupní
zařízení
- po potvrzeném úspěšném tisku to oznámí AS, který
to může ještě chvíli nechat viset s příznakem "vytištěno"
a pak třeba zaarchivovat nebo smáznout
- obecný výstupní klient: tiskový je vlastně speciálním
případem tohoto obecného, protože to posílá na tiskárnu
Otázka je, zda výstupní (= hlavně tiskový) systém má být součástí
AS nebo to má být speciální klient.
Bude-li to klient, měl by pravidelně pollovat AS a cucat si joby.
Bude-li součástí AS, navrhuji, aby to byl "Výstupní Server",
tj. aby seděl na TCP/IP portu na nějaké mašině a aby ho AS mohl
oslovit a joby mu rovnou šoupat. V takovém případě by výstupní
fronty nemusely být uvnitř AS.
Tím by se Výstupní Server oddělil od AS a mohl by být implementován
nezávisle, v jiném (= vhodnějším) programovacím prostředí.
Totéž platí pro případný "Vstupní Server", který by mohl sloužit
pro vstupy z nezávislých zdrojů:
- specializovaný klient umí číst výstup z nějakého účetního
pořizovacího programu, NEPŘEKLÁDÁ ho do XML a posílá do AS
- AS ho rovnou předá (s nějakám sériovám číslem) jako
binární data "Vstupnímu Serveru", který se pokusí o převod
do námi definovaného XML
- toto může být učiněno off-line, může to i trvat, ...
- časem bude ve frontě připaven vyřízený vstupní job (úspěšně
nebo neúspěšně), který si AS bude moci převzít
- celý ten proces bude kontrolovatelený uživatelem
pře jeho klientský program
Výhoda: opět to může být implementováno nezávisle, v jiném prostředí, ...
Vstupní a Výstupní Servery pak postupně mohou být rozšiřovány
podle potřeby (a našich možností) o další moduly (=filtry).
ivo
--
E-mail: Ivo.Panacek@regionet.cz, Ivo.Panacek@jlabs.cz
WWW: http://ivop.regionet.cz
Mobile: +420 602 337776
-------------------------- ucto-dev-l@pinknet.cz ------------------------
Konference o vyvoji ucetnictvi http://ucto.linux.cz/
Partial thread listing: