Razvoj enostavno nastavljive programske opreme je v današnjem poslovnem okolju izrednega pomena. Programskih aplikacij ne ocenjujemo več samo po količini poslovne logike, ki jo vsebujejo; sodijo tudi po tem, kako enostavno jih je vzdrževati. Sposobnost spreminjanja vedenja programske opreme s pomočjo konfiguracije je pomemben vidik tega vzdrževalnega cikla.
Medtem ko jezik Java za pomoč pri konfiguraciji ponuja številne funkcije, kot so datoteke z lastnostmi in svežnji virov, te nimajo funkcij, potrebnih za današnje dinamično poslovno okolje. Številni standardi, orodja in vsebniki Java že uporabljajo naprednejše in po meri konfiguracijske formate XML.
Obix Framework je odprtokodni okvir, ki ponuja skupna sredstva in formate za shranjevanje konfiguracijskih podatkov v XML in za dostop do teh podatkov prek preprostih predmetov Java. Omogoča modularizacijo konfiguracijskih podatkov tako, da omogoča uvoz in vključitev konfiguracijskih datotek ter organiziranje informacij o konfiguraciji v "module".
Poleg tega podpira "vroče" spremembe konfiguracije - s samodejnim zaznavanjem in samodejnim ponovnim nalaganjem sprememb konfiguracijskih podatkov -, poleg tega pa nudi podporo za API za poimenovanje Java in vmesnik imenika (JNDI). Poleg tega ga je mogoče v programe Java integrirati na številne načine, tudi prek razširitev Java Management Extensions (JMX) in Java Platform, poslušalcev Enterprise Edition, ki ne zahtevajo kodiranja, pa tudi navadne razrede Java, ki jih je mogoče neposredno priklicati. Končno, ogrodje ponuja enostaven za uporabo vtični API, ki razvijalcem omogoča, da ga razširijo za izvajanje nalog v zvezi z inicializacijo. Ta API je ekipa Obix uporabljala za zagotavljanje pripomočkov za inicializacijo za druge odprtokodne okvire, kot so Apachejev log4j, Hibernate in Commons DBCP (področja povezave z bazo podatkov).
V tej vadnici opisujem hipotetični scenarij, ki zahteva nastavljivo programsko opremo in za katerega z Obixom ustvarjamo skeletne aplikacije. Prvi primer je najbližji dokaz koncepta v slogu "Hello World", drugi in tretji pa to aplikacijo razširita tako, da prikazuje manj nepomembne vidike konfiguracije.
Upoštevajte, da so vsi vzorci kode v tem članku zapakirani v arhiv, ki ga lahko prenesete s povezave v virih.
Težavni scenarij
Vrednotenje finančnih sredstev, kot so delnice ali opcije, včasih vključuje simulacijo cene sredstva tisočkrat in upoštevanje povprečja teh vrednosti - v prepričanju, da povprečje najbolje ugiba o "resnični" prihodnji vrednosti sredstva. Takšne simulacije običajno zahtevajo vnos statističnih podatkov v obliki trenutne cene sredstva, povprečne cene v določenem časovnem obdobju in odstopanja od povprečja.
Recimo, da ustvarjamo aplikacijo za vrednotenje takšnih instrumentov. Kot taka bo morala ta aplikacija prenesti statistične vnose prek spletne storitve, podrobnosti - kot so URL in podatki za preverjanje pristnosti - za povezavo s to storitvijo pa so shranjene v konfiguracijskem dokumentu. Dovolj je reči, da mora biti tudi število simulacij, ki jih je treba izvesti za določeno zahtevo za oceno vrednosti, prilagodljivo in bo kot takšno določeno s konfiguracijo.
Primer 1: Osnovna konfiguracijska datoteka
V tem primeru za našo aplikacijo ustvarimo osnovno konfiguracijsko datoteko example1-config.xml, ki vsebuje podrobnosti za povezavo s spletno storitvijo, ki zagotavlja statistične vnose v postopek vrednotenja. Ta konfiguracijska datoteka bo shranila tudi število simulacij, ki jih je treba izvesti za katero koli zahtevo za vrednotenje. Ta datoteka (kot tudi konfiguracijske datoteke za druge primere) je v imeniku config prenosnega arhiva, povezanega s to vadnico. Vsebina konfiguracijske datoteke je navedena na naslednji način:
//www.some-exchange.com/marketdata
trading_app_dbo
nopassword
10000
Če datoteko podrobneje preučimo, opazimo, da se začne s korenskim vozliščem ; to pomeni začetek dokumenta o konfiguraciji Obix. Obstajajo štirje vozlišč, od katerih vsaka vsebuje vnos konfiguracije. Prvi trije vsebujejo URL, ID uporabnika in geslo za povezavo z vhodno storitvijo; zadnji vnos vsebuje število simulacij, ki jih je treba izvesti za vsako zahtevo za vrednotenje. Upoštevajte, da ima vsak vnos unikatni ključ, kot določa entryKey atribut in da je vrednost v vsakem vnosu inkapsulirana z vozlišče.
Nato izdelamo ogrodje naše aplikacije za vrednotenje in, kar je še pomembneje, predstavimo, kako se konfiguracijski dokument bere med izvajanjem. Razred zanimanja se imenuje Primer1.java in ga lahko najdete v mapi src prenosljivega arhiva, povezanega s to vadnico. Definicija razreda je naslednja:
import org.obix.configuration.Configuration; import org.obix.configuration.ConfigurationAdapter; import org.obix.configuration.ConfigurationAdapterFactory;
javni razred Primer1 {public static void main (String [] args) {ConfigurationAdapterFactory adapterFactory = ConfigurationAdapterFactory.newAdapterFactory ();
ConfigurationAdapter adapter = adapterFactory.create (null);
adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); printMarketDataInfo (); }
zasebna statična praznina printMarketDataInfo () {Configuration globalConfig = Configuration.getConfiguration ();
System.out.println ("URL podatkovne storitve: \ t \ t" + globalConfig.getValue ("market.data.service.url"));
System.out.println ("ID uporabniške podatkovne storitve: \ t \ t" + globalConfig.getValue ("market.data.service.uid"));
System.out.println ("Geslo za podatkovno storitev: \ t \ t" + globalConfig.getValue ("market.data.service.password"));
System.out.println ("Število simulacij: \ t \ t" + globalConfig.getValue ("number.of.valuation.simulations")); }}
Če želite zagnati ta in nadaljnje primere, morate prenesti dvojiške datoteke Obix Framework na mesto, dostopno prek vaše učilnice. Vaša učna pot se mora sklicevati na knjižnico Obix, obix-framework.jar, ki ga najdete v mapi lib korenskega imenika okolja. Potrebovali boste tudi naslednje neodvisne odprtokodne knjižnice: dom.jar, jaxen-full.jar, sax.jar, saxpath.jar, in xercesImpl.jar, ki ga najdete v mapi lib / thirdParty v korenskem imeniku okolja.
Izvajanje tega razreda bi moralo dati naslednji rezultat:
URL podatkovne storitve: //www.some-exchange.com/marketdata ID storitve uporabnika podatkovne storitve: trading_app_dbo Geslo podatkovne storitve: nopassword Število simulacij: 10000 Za razčlenitev tega razreda začnemo z glavno metodo. Prva vrstica te metode ustvari primerek razreda org.obix.configuration.ConfigurationAdapterFactory, ki je odgovoren za izdelavo konfiguracijskega vmesnika (primerek razreda org.obix.configuration.ConfigurationAdapter). Adapter je odgovoren za dejansko branje konfiguracijskega dokumenta z določenega mesta (določeno kot pot datoteke ali URL).
Naslednji izvleček kode prebere vsebino naše konfiguracijske datoteke v primerek globalne / statične konfiguracije s klicem metode vmesnika adaptConfiguration ()in s posredovanjem sklica na globalni primerek - kot je bil pridobljen iz klica Configuration.getConfiguration ()—In pot do naše konfiguracijske datoteke config / example1-config.xml:
adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); Upoštevajte, da je mogoče ustvariti nov primerek konfiguracije za shranjevanje naših podatkov o konfiguraciji, namesto da bi uporabili statični (globalni) primerek, vendar zaradi enostavnosti (in kratkosti) za ta primer uporabimo statični primerek.
Nato na kratko preučimo metodo printMarketDataInfo (), ki preprosto bere vnose v konfiguracijo (tj. Vozlišča XML) in natisne njihove vrednosti (tj. Njihove podrejena vozlišča). Upoštevajte, da je vrednost vsakega vnosa pridobljena s klicanjem metode getValue (...) na pripadajoči Konfiguracija primerek, podajanje imena / ključa vnosa - kot je določeno za vozlišče vnosa entryKey atribut. Poleg tega upoštevajte, da ima lahko vnos več vrednosti, kar bo prikazano kasneje v tej vadnici.
Primer 2: Modularizacija konfiguracijskih podatkov
Tovrstne aplikacije običajno ustvarijo poročilo, ki podrobno prikazuje rezultate zahteve v neki obliki. Naša hipotetična aplikacija se ne razlikuje; lahko pripravi poročila o vrednotenju v različnih oblikah. Poleg tega oblike poročanja, ki se uporabljajo v danem zagonu aplikacije, narekuje vnos konfiguracije, vsa ustvarjena poročila pa se pošljejo po e-pošti na seznam prejemnikov v naši organizaciji - kjer so prejemniki navedeni tudi v naboru konfiguracij.
Logično je, da je poročanje ločen del funkcionalnosti - v primerjavi z vrednotenjem -, čeprav sta oba povezana; zato bi bilo povsem smiselno vključiti naše konfiguracijske podatke za "poročanje". To ne zagotavlja samo čistejšega ločevanja konfiguracijskih podatkov, ampak tudi novincem olajša vizualizacijo razmejitve funkcionalnosti znotraj aplikacije.
Konfiguracijo poročanja za ta primer zapišemo tako, da izdelamo konfiguracijski modul za poročanje, ki je podrejen korenskemu modulu. Konfiguracijsko datoteko spremenimo iz zadnjega primera tako, da spodnje vozlišče dodamo na svoj seznam vozlišč; nastala datoteka se imenuje example2-config.xml in jo je mogoče najti v imeniku config izvornega arhiva.
.................... .................... .......... ......... [email protected]
besedilna datoteka preglednice pdf
V tej konfiguracijski datoteki takoj izstopata dve stvari: prva je seveda definicija našega modula , čemur sledi drugo vozlišče modula . Začnemo z definicijo modula. Konfiguracijski dokument Obix lahko vsebuje poljubno število podmodulov. Z izključitvijo dveh elementov, ki v tej vadnici niso obravnavani, moduli podpirajo isto vozlišče, nastavljeno kot korenski modul. Z drugimi besedami, moduli imajo vnose in lahko vsebujejo druge module; zato se moduli lahko učinkovito uporabljajo za kopiranje drevesne strukture.
Spomnimo se, da sem v zadnjem primeru omenil, da ima lahko vnos konfiguracije več vrednosti. Ta funkcionalnost prikazuje vnos konfiguracije za shranjevanje formatov poročanja, tj. . Kot lahko vidite, se ta razlikuje od ostalih vnosov po tem, da ima tri vrednosti - določa tri formate, v katerih naj se generirajo poročila.
Zdaj preučujemo kodo Java za branje vnosov v našem konfiguracijskem modulu poročanja. Vir Java spremenimo za prejšnji primer z dodajanjem naslednje metode; spremenjena izvorna datoteka (razred) se preimenuje Primer2.java, in ga lahko najdete v mapi src v arhivu, povezani s to vadnico:
private static void printReportingConfig () {Configuration globalConfig = Configuration.getConfiguration ();
Konfiguracija reportConig = globalConfig.getModule ("report.parameters");
System.out.println ("Cilj poročila: \ t \ t" + reportConig.getValue ("reports.destination.email"));
System.out.println ("Formati poročanja: \ t \ t" + reportConig.getValues ("formati_poročil")); }
Ob izvajanju tega razreda bi moral ustvariti rezultat:
URL podatkovne storitve: //www.some-exchange.com/marketdata ID storitve uporabnika podatkovne storitve: trading_app_dbo Geslo podatkovne storitve: nopassword Število simulacij: 10000
Parametri konfiguracije poročanja = Cilj poročila: [email protected] Oblike poročanja: [preglednica, besedilna datoteka, pdf]
Ob podrobnem preučevanju dodatne metode opazimo, da najprej dobi sklic na globalno Konfiguracija primer; nato nadaljuje s pridobivanjem sklica na konfiguracijski modul, ki vsebuje informacije o konfiguraciji poročanja. Metoda te naloge doseže z uporabo metode getModule (...) na nadrejenem modulu in posreduje ID modula, ki ga je treba sprejeti. Upoštevajte, da je ta sintaksa generična v smislu, da pridobitev podrejenega katerega koli modula - tudi če ne korenskega modula - dosežemo s klicem getModule (...) na danem modulu.
