Osvědčená architektura aplikací typu Klient/Server (vycházející z obr.1) zřejmě pochází ještě z dob velkých (zejména rozměry) sálových počítačů. V té době se výpočetní výkon části serverové od výpočetního výkonu části uživatelské v počítačových sítích lišil až několika řády. Běžná přenosová rychlost tehdejších LAN sítí se pohybovala maximálně v tisících bps. Vzhledem k těmto hardwarovým skutečnostem bylo nutné přizpůsobit i tvorbu programového vybavení. Veškerá aplikační logika byla soustředěna na serverové části. Uživatelská část v podstatě představovala prachobyčejný terminál, přes který na jedné straně uživatel předával aplikační logice jednoduché pokyny pro provedení požadovaných operací, na druhé straně pouze zobrazoval výsledky požadovaných operací, které obdržel od aplikační logiky umístněné v serverové části. Přenesením se do jazyka současné doby můžeme mluvit o supertenké klientské části softwarových aplikací. Od té doby (cca 25-let nazpět) se v oblasti výkonu počítačových sítí provedlo mnoho zásadních změn. Vzpomeňme aspoň tyto:
- Radikálně se zvýšil výpočetní výkon jak části serverové, tak i části uživatelské
- O několik řádů se zvýšila propustnost komunikační části
- Poměr výpočetního výkonu části serverové k výpočetnímu výkonu části uživatelské se podstatně zmenšil (mnohokrát v praxi jsou dokonce porovnatelné)
Obr.1: Standardní architektura Klient/Server
Před tím, než jsme započali samotný vývoj naší aplikace účetního systému MRP-K/S, provedli jsme řady měření na současných LAN sítích. Zprvopočátku jsme zvažovali směřovat vývoj k tenkému až supertenkému klientovi. Vzhledem k specifickým problémům účetní problematiky u běžných firem jsme ale dospěli k závěru, že trvání na tenké klientské části nás vzdálí od některých cílů, které jsme si dali jako prioritní. Abychom od těchto našich prioritních cílů nemuseli ustupovat, rozhodli jsme se (vzhledem k výpočetnímu výkonu současných počítačů a rychlostech přenosu dat v sítích LAN) upustit od aplikace Klient/Server schematicky znázorněné na obr.1.
Navrhli jsme proto nové řešení, které schematicky zobrazuje obr.2 a nazvali jsme ho Architektura Klient/Server s technologii DMAL® (Decentralizovanou Multiplexovanou Aplikační Logikou).
Obr.2: Architektura Klient/Server s technologii DMAL® (decentralizovanou
multiplexovanou aplikační logikou)
Proč právě název Decentralizovaná Multiplexovaná Aplikační Logika?
- V standardní aplikaci Klient/Server (vycházející z obr.1) je takřka veškerá aplikační logika soustředěna centralizovaně v serverové části. My jsme tento zažitý standard “porušili” tím způsobem, že jsme tuto logiku decentralizovali na pracovní stanice. Samozřejmě zůstala část aplikační logiky i v serverové části (viz. obr.2). Toto rozdělení jsme udělali následovně:
- Na serverové části jsme nechali umístněnu tu část aplikační logiky, která při své činnosti vyžaduje velké datové toky.
- Na uživatelské části jsme soustředili zejména tu část aplikační logiky, která se vyznačuje zejména vyšší inteligencí.
- Uživatelské programové rozhraní v spolupráci s klientskou aplikační logikou pak rozhoduje, kterou část zadaného úkolu (nebo který úkol) bude řešit aplikační logika v serverové části a kterou část úkolu bude řešit aplikační logika umístněna v uživatelské části. Jelikož činnost logik v serverové a v uživatelské části je deterministicky přepínána (multiplexována), od toho je odvozen pojem multiplexovaná aplikační logika.
Co jsme navíc získali použitím DMAL® technologie oproti standardní aplikaci Klient/Server?
- Radikální zrychlení vývojových prací, což ocení taktéž i naši uživatelé v současných dynamicky se měnících účetních předpisech.
- Rovnoměrnější využití výpočetních výkonů jednotlivých počítačů v sítích LAN.
- Subjektivní rychlost aplikace je porovnatelná s rychlostí nesíťové aplikace.
- Uživatelské rozhraní klientské části je stejně vlídné jako doposud používané rozhraní u našich účetních aplikací, které nebyly typu Klient/Server.
- V neposlední řadě i zásadní snížení ceny pro koncové uživatele (viz ceník MRP). Je běžné, že cena klasických aplikací typu Klient/Server od jiných výrobců bývá až řádově vyšší, jako námi vytvořené řešení.