https://sourceforge.net/p/odcleanstore/wiki/Zero%2520Result/Recent changes to Zero ResultenMon, 09 Jan 2012 12:02:23 -0000https://sourceforge.net/p/odcleanstore/wiki/Zero%2520Result/<pre>--- v1 +++ v2 @@ -6,7 +6,7 @@ **Základní myšlenky** -* Nainstalovaná Java, Virtuoso (DB instance, administrátorský přístupový účet, přístup přes JDBC) a případná dostupnost internetu budou softwarové požadavky, žádný instalátor pro tohle nebudem dělat, poskytneme jen know-how, případně přiložíme instalační soubory na CD +* Nainstalovaná Java, Virtuoso (DB instance, administrátorský přístupový účet, přístup přes JDBC) a případná dostupnost internetu budou softwarové požadavky, žádný instalátor pro tohle nebudem dělat, poskytneme jen know-how, případně přiložíme instalační soubory na CD. Přidáme kuchařku popisující typickou instalaci a konfiguraci (resp. odkážeme na stávající kuchařky). <br/><br/> * Vše ostatní bude v Javě (nebo z ní ovladatelné) v jednom adresáři aplikace na CD, uživatel si to nakopíruje na lokál <br/><br/> </pre>Tomas KnapMon, 09 Jan 2012 12:02:23 -0000https://sourceforge.netdd39693333fc1f4c8a16d55870d55fc9797322b2https://sourceforge.net/p/odcleanstore/wiki/Zero%2520Result/Nultý návrh podoby výsledného produktu (zero stupid) =================================================== *prosím přečíst nejprve celé, než přistoupíte k poznámkám a detailům* **Základní myšlenky** * Nainstalovaná Java, Virtuoso (DB instance, administrátorský přístupový účet, přístup přes JDBC) a případná dostupnost internetu budou softwarové požadavky, žádný instalátor pro tohle nebudem dělat, poskytneme jen know-how, případně přiložíme instalační soubory na CD <br/><br/> * Vše ostatní bude v Javě (nebo z ní ovladatelné) v jednom adresáři aplikace na CD, uživatel si to nakopíruje na lokál <br/><br/> * Baťák pro Windows, script pro Linux spustí první aplikaci v Javě, jak je obvyklé (v zadání zatím žádné info o multiplatformitě) <br/><br/> * Tato první aplikace představuje kontrolní, monitorovací a spouštěcí proces, který bude ovládat vše ostatní, prvořadá je robustnost <br/><br/> * Tento supermonitor bude spouštět unifikované kontainery našich komponent, kontainery mají minimalizovanou vzájemnou komunikací od začátku designovanou jako meziprocesovou (jen pro diagnostiku stavu nebo progressu nějaké činnosti a základní signály (zprávy mezi procesy), naše komponenty budou primárně komunikovat přes permanentní úložiště DB, bez ní je náš SW k ničemu <br/><br/> * Kromě kontainerů lze kód ještě spouštět v rámci WS a WebServeru na našem aplikačním serveru <br/><br/> * Aplikační server běží opět v rámci našeho kontaineru <br/><br/> * Komponenty z našich diagramů mající mezi sebou interface v Javě, které je nutí komunikovat v Javě napřímo budou v jednom kontaineru, jinak komunikují přes permanentní úĺožiště a jednoduché signálování, tento design kontainerů ponechává možnost to spouštět ve více procesech(může se podařit to pustit i jen v jednom procesu), je k tomu jednotný háv <br/><br/> * cross-technologie typu logování použijeme robustním způsobem: využijí DB, pokud nepude, pak zapisují do souborů atd., jsou nám v opačném případě přínosem? *o žádném vhodném frameworku, který by to dělal nevím, všechno to je jednoduché, vděčné na UML apod., není nebezpečí, že se budeme trápit s externím frameworkem a takto investovaný čas nemusí být efektivní* **Konkrétně** * Baťák pro Windows, script pro Linux spustí první aplikaci - supermonitor v Javě <br/><br/> * Ta pustí první komponentu, která zkontroluje sw podmínky, zda-li je nainstalováno, případně nainstaluje co je potřeba a co umí konfigurovat (DB, WS apod.) <br/><br/> * Pustí se pak kontainer s aplikačním serverem ve kterém je serverová část GUI a WS, vše maximálně předkonfigurováno (u WS bude možná nutno měnit cfg soubory před spuštěním konkrétní instalace) <br/><br/> * Pustí se náš čistící engine nebo bude supermonitor čistícím enginem sám (to není dobrý nápad) <br/><br/> **Přídavky** * Možnost spouštět sw jako službu (NT Service u Windows, daemon v Linuxu) <br/><br/> * Pro vybrané platformy přidělat spouštěč jiný než bat a skript <br/><br/> * Umožnit instalaci na externí aplikační server? - ten náš supermonitor by byl pak war na aplikáči, příliš práce, když to uděláme předchozím způsobem to není, spíše jde o testování na konkrétních aplikáčích <br/><br/> * Instalátor, případně některé další komponenty, by mohli mít nějaké primitivní Java GUI těžkého klienta (pokud možno platformově nezávislé) **Otázky** * SILK engine lze spouštět v rámci nějakého kontaineru, předpřipravit mu konf. data z DB, u integrace GUI už je to horší, otázkou je též způsob jakým přistupuje k DB (SPARQL endpoint) <br/><br/> * Jak dalece půjde SPARQL endpoint Virtuosa konfigurovat z Javy? V případě že ne, tak tu máme onen kýžený pádný důvod proč na lowlevel dotazování dělat též WS. Pokud budem umět nakonfigurovat DB z Javy a konfigurace SPARQL endpointů bude též v naší režii, pak budem možná schopni udělat celou instalaci i s Virtuosem, každopádně nebudeme uživatele příliš nutit umět konfigurovat Virtuoso, stačí když si ho nainstaluje. Existuje pro SPARQL endpoint nějaký standard? (do zadání bych napsal, že bude umožněno data dotazovat dostupným standardem, z formulace by nemělo vyplývat jak to uděláme, jestli jen to nezablokujem Virtuosu nebo budem dělat WS) **Navrhovaný další postup** * Naše analýza již poskytuje asi dost podkladů, abychom z ní byli schopni navrhnout takovýto podobný základní model výsledné aplikace, hlavně celkový soupis možností, které použijem a které budem měnit již jen vyjímečně <br/><br/> * Do něj pak napasujem naše krabičky diagramy atd. <br/><br/> * Ověříme celkovou funkčnost a zbylá bílá místa - a tím bych prototyp považoval za vyřízený, víc stejně nestihnem <br/><br/> * S našimi znalostmi sw inženýrství, architektur atd. jistě takto vymyslíme kvalitní produkt, držel bych se u tohoto postupu zásad ze SCRUMU apod., že pokud něco nevymyslíme v určitém termínu (např. že jsme se utopili v detailech) tak to necháme jednodušší, i když to není dokonalý <br/><br/> * K tomu to chce celkový plán, navrhuju dotvořit to tímto způsobem, projít to od návrhu výsledku odzadu až k vizím a pak zpět (výsledek pak může být odlišný) **Poznámka** Pro předvádění sw komisi bych navrhoval toto * použít VirtualBox s celými nainstalovanými systémy (dá se zazálohovat i kopírovat mezi PC) <br/><br/> * až se z nějaké zálohy podaří 10..x perfektní předvedení, tak ji použijem <br/><br/> * předvádění může být víc (více platforem, více možných předvádění - instalace, předvedení GUI, předvedení vyčištěné DB apod.) Petr JermanSun, 08 Jan 2012 13:25:27 -0000https://sourceforge.netb06bf6b1223c164ad340d44152e9cb7d30b3a36a