Programování

Snadno vyvíjejte konfigurovatelné softwarové aplikace

Vývoj snadno konfigurovatelného softwaru má v dnešním obchodním prostředí zásadní význam. Softwarové aplikace již nejsou posuzovány jednoduše podle množství obchodní logiky, kterou zapouzdřují; hodnotí se také podle toho, jak snadno se udržují. Schopnost měnit chování softwaru prostřednictvím konfigurace tvoří důležitý aspekt tohoto cyklu údržby.

Zatímco jazyk Java poskytuje řadu funkcí, jako jsou soubory vlastností a balíčky prostředků, které usnadňují konfiguraci, chybí jim funkce požadované pro dnešní dynamická obchodní prostředí. Mnoho standardů, nástrojů a kontejnerů Java již využívá pokročilejší a vlastní formáty konfigurace XML.

Obix Framework je open source framework, který poskytuje běžné prostředky a formáty pro ukládání konfiguračních dat v XML a pro přístup k těmto datům prostřednictvím jednoduchých objektů Java. Umožňuje modularizaci konfiguračních dat tím, že umožňuje importovat a navzájem do sebe zahrnout konfigurační soubory a organizovat konfigurační informace do „modulů“.

Kromě toho podporuje „aktuální“ změny konfigurace - prostřednictvím automatické detekce a automatického opětovného načtení změn konfiguračních dat - a také poskytuje podporu pro rozhraní Java Naming and Directory Interface API (JNDI). Kromě toho jej lze integrovat do aplikací Java mnoha způsoby, mimo jiné prostřednictvím Java Management Extensions (JMX) a Java Platform, posluchačů Enterprise Edition, které nevyžadují kódování, a běžných tříd Java, které lze vyvolat přímo. Nakonec rozhraní poskytuje snadno použitelné rozhraní API modulu plug-in, které vývojářům umožňuje rozšířit ho o provádění úkolů souvisejících s inicializací. Toto rozhraní API bylo použito týmem Obix k poskytnutí inicializačních nástrojů pro jiné open source rámce, jako je Apache's log4j, Hibernate a Commons DBCP (fondy připojení k databázi).

V tomto tutoriálu popisuji hypotetický scénář, který vyžaduje konfigurovatelný software a pro který vytváříme skeletové aplikace pomocí Obixu. První příklad poskytuje nejbližší věc konceptu konceptu „Hello World“, zatímco druhý a třetí rozšiřují tuto aplikaci o méně triviální aspekty konfigurace.

Všimněte si, že všechny ukázky kódu v tomto článku jsou zabaleny jako archiv, který lze stáhnout pomocí odkazu uvedeného v Zdrojích.

Problémový scénář

Oceňování finančních aktiv, jako jsou akcie nebo opce, někdy zahrnuje tisíckrát simulaci ceny aktiva a průměr z těchto hodnot - ve víře, že průměr poskytuje nejlepší odhad, pokud jde o „skutečnou“ budoucí hodnotu aktiva. Takové simulace obvykle vyžadují statistický vstup ve formě aktuální ceny aktiva (aktiv), průměrné ceny za dané časové rozpětí a také odchylky od průměru.

Předpokládejme, že vytváříme aplikaci pro oceňování těchto nástrojů. Tato aplikace si proto bude muset stáhnout statistické vstupy prostřednictvím webové služby a podrobnosti - například URL a ověřovací informace - pro připojení k této službě jsou uloženy v konfiguračním dokumentu. Stačí říci, že počet simulací, které mají být provedeny pro daný požadavek na ocenění, by měl být také flexibilní a jako takový bude specifikován prostřednictvím konfigurace.

Příklad 1: Základní konfigurační soubor

V tomto příkladu vytvoříme pro naši aplikaci základní konfigurační soubor, example1-config.xml, který obsahuje podrobnosti pro připojení k webové službě, která poskytuje statistické vstupy do procesu oceňování. Tento konfigurační soubor také uloží počet simulací, které se mají provést pro jakýkoli požadavek na ocenění. Tento soubor (stejně jako konfigurační soubory pro ostatní příklady) je v konfiguračním adresáři stahovatelného archivu přidruženého k tomuto výukovému programu. Obsah konfiguračního souboru je uveden takto:

//www.some-exchange.com/marketdata

trading_app_dbo

nopassword

10000

Pokud soubor prozkoumáme podrobněji, všimněte si, že začíná kořenovým uzlem ; to označuje začátek konfiguračního dokumentu Obix. Jsou čtyři uzly, každý zapouzdřující položku konfigurace. První tři obsahují adresu URL, ID uživatele a heslo pro připojení ke službě vstupů; poslední položka obsahuje počet simulací, které mají být provedeny pro každou žádost o ocenění. Všimněte si, že každá položka má jedinečný klíč, jak je uvedeno v entryKey atribut a že hodnota v každé položce je zapouzdřena a uzel.

Dále vytvoříme kostru naší oceňovací aplikace a co je důležitější, ukážeme, jak se čte konfigurační dokument za běhu. Třída zájmu se nazývá Příklad1.java a lze je najít ve složce src archivu ke stažení přidruženého k tomuto výukovému programu. Definice třídy je následující:

import org.obix.configuration.Configuration; import org.obix.configuration.ConfigurationAdapter; import org.obix.configuration.ConfigurationAdapterFactory;

veřejná třída Example1 {public static void main (String [] args) {ConfigurationAdapterFactory adapterFactory = ConfigurationAdapterFactory.newAdapterFactory ();

ConfigurationAdapter adapter = adapterFactory.create (null);

adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); printMarketDataInfo (); }

private static void printMarketDataInfo () {Configuration globalConfig = Configuration.getConfiguration ();

System.out.println ("URL datové služby: \ t \ t" + globalConfig.getValue ("market.data.service.url"));

System.out.println ("ID uživatele datové služby: \ t \ t" + globalConfig.getValue ("market.data.service.uid"));

System.out.println ("Heslo datové služby: \ t \ t" + globalConfig.getValue ("market.data.service.password"));

System.out.println ("Počet simulací: \ t \ t" + globalConfig.getValue ("number.of.valuation.simulations")); }}

Chcete-li spustit tento a následující příklady, musíte si stáhnout binární soubory Obix Framework do umístění přístupného prostřednictvím vaší cesty ke třídě. Vaše cesta ke třídě musí odkazovat na knihovnu Obix, obix-framework.jar, kterou najdete ve složce lib kořenového adresáře rozhraní. Budete také potřebovat následující knihovny open source třetích stran: dom.jar, jaxen-full.jar, sax.jar, saxpath.jar, a xercesImpl.jar, kterou najdete ve složce lib / thirdParty v kořenovém adresáři rozhraní.

Provedení této třídy by mělo způsobit následující výsledek:

URL datové služby: //www.some-exchange.com/marketdata ID datové služby ID uživatele: trading_app_dbo Heslo datové služby: nopassword Počet simulací: 10 000 

Abychom tuto třídu rozebrali, začneme hlavní metodou. První řádek této metody vytvoří instanci třídy org.obix.configuration.ConfigurationAdapterFactory, který je zodpovědný za vytvoření konfiguračního adaptéru (instance třídy org.obix.configuration.ConfigurationAdapter). Adaptér je zase zodpovědný za skutečné čtení konfiguračního dokumentu z daného umístění (zadaného jako cesta k souboru nebo URL).

Následující extrakt kódu přečte obsah našeho konfiguračního souboru do instance globální / statické konfigurace vyvoláním metody adaptéru adaptConfiguration ()a předáním odkazu na globální instanci - získanou z volání Configuration.getConfiguration ()—A cesta k našemu konfiguračnímu souboru config / example1-config.xml:

adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); 

Všimněte si, že je možné vytvořit novou instanci konfigurace pro uložení našich konfiguračních dat, namísto použití statické (globální) instance, ale z důvodu jednoduchosti (a stručnosti) použijeme pro tento příklad statickou instanci.

Dále krátce prozkoumáme metodu printMarketDataInfo (), který jednoduše načte konfigurační položky (tj Uzly XML) a vytiskne jejich hodnoty (tj. Jejich podřízené uzly). Všimněte si, že hodnota každé položky se získá voláním metody getValue (...) na přidružené Konfigurace instance, předání názvu / klíče záznamu - jak je uvedeno pro vstupní uzel entryKey atribut. Jako poznámku si všimněte, že položka může mít více hodnot, které budou dále ukázány v tomto kurzu.

Příklad 2: Modularizace konfiguračních dat

Aplikace tohoto druhu obvykle vygenerují zprávu s podrobnostmi o požadavcích v nějakém formátu. Naše hypotetická aplikace se nijak neliší; je schopen vytvářet zprávy o ocenění v různých formátech. Kromě toho jsou formáty hlášení použité v daném běhu aplikace diktovány záznamem o konfiguraci a všechny generované zprávy jsou zasílány e-mailem na seznam příjemců v naší organizaci - kde jsou příjemci také specifikováni v konfigurační sadě.

Logicky je vytváření přehledů zřetelnou součástí funkčnosti - ve srovnání s oceňováním - i když obě spolu souvisejí; takže by bylo celkem rozumné zapouzdřit naše konfigurační údaje „pro hlášení“. To nejen poskytuje čistší oddělení konfiguračních dat, ale také nováčkovi usnadní vizualizaci vymezení funkcí v aplikaci.

Zapouzdřujeme konfiguraci hlášení pro tento příklad vytvořením konfiguračního modulu pro hlášení, který je potomkem našeho kořenového modulu. Upravíme konfigurační soubor z posledního příkladu připojením níže uvedeného uzlu k jeho seznamu uzlů; výsledný soubor se nazývá example2-config.xml a lze jej najít v konfiguračním adresáři zdrojového archivu.

.................... .................... .......... ......... [email protected]

tabulkový textový soubor pdf

V tomto konfiguračním souboru okamžitě vyniknou dvě věci: první je samozřejmě naše definice modulu , následovaný druhým vstupním uzlem modulu . Začneme definicí modulu. Konfigurační dokument Obix může obsahovat libovolný počet submodulů. Blokování dvou prvků - v tomto tutoriálu to není popsáno - moduly podporují stejnou sadu uzlů jako kořenový modul. Jinými slovy, moduly mají položky a mohou obsahovat další moduly; proto lze moduly efektivně použít k replikaci stromové struktury.

Připomeňme, že v posledním příkladu jsem zmínil, že položka konfigurace může mít více hodnot. Tuto funkčnost demonstruje položka konfigurace pro uchovávání formátů hlášení, tj. . Jak vidíte, liší se od ostatních položek tím, že má tři hodnoty - určující tři formáty, ve kterých by se měly generovat sestavy.

Nyní prozkoumáme kód Java pro čtení položek v našem modulu konfigurace hlášení. Zdroj Java upravíme pro předchozí příklad přidáním následující metody; upravený zdrojový soubor (třída) je přejmenován Example2.javaa najdete jej ve složce src archivu přidruženého k tomuto výukovému programu:

private static void printReportingConfig () {Configuration globalConfig = Configuration.getConfiguration ();

Konfigurace reportingConig = globalConfig.getModule ("reporting.parameters");

System.out.println ("Cíl sestav: \ t \ t" + reportingConig.getValue ("reports.destination.email"));

System.out.println ("Formáty hlášení: \ t \ t" + reportingConig.getValues ​​("report_formats")); }

Při provádění této třídy by měl produkovat výstup:

URL datové služby: //www.some-exchange.com/marketdata ID datové služby ID uživatele: trading_app_dbo Heslo datové služby: nopassword Počet simulací: 10 000

Konfigurační parametry hlášení = Místo určení hlášení: [email protected] Formáty hlášení: [tabulka, textový soubor, pdf]

Po podrobném prozkoumání další metody si všimneme, že nejprve získá odkaz na globální Konfigurace instance; pak pokračuje v získávání odkazu na konfigurační modul obsahující informace o konfiguraci hlášení. Metoda dosahuje těchto úkolů vyvoláním metody getModule (...) na nadřazeném modulu a předáním ID modulu, který má být přijat. Všimněte si, že tato syntaxe je obecná v tom smyslu, že získání potomka libovolného modulu - i když ne kořenového - je dosaženo vyvoláním getModule (...) na daném modulu.

$config[zx-auto] not found$config[zx-overlay] not found