Helposti konfiguroitavien ohjelmistojen kehittäminen on ensiarvoisen tärkeää nykypäivän liiketoimintaympäristössä. Ohjelmistosovelluksia ei enää arvioida pelkästään niiden sisältämän liiketoimintalogiikan perusteella; heitä arvioidaan myös sen perusteella, kuinka helppoa niitä on ylläpitää. Kyky muuttaa ohjelmistokäyttäytymistä konfiguroinnin avulla on tärkeä osa ylläpitosykliä.
Vaikka Java-kielellä on useita ominaisuuksia, kuten ominaisuus- ja resurssipaketit, konfiguroinnin helpottamiseksi, niiltä puuttuu nykypäivän dynaamisissa liiketoimintaympäristöissä vaaditut ominaisuudet. Monet Java-standardit, työkalut ja säilöt käyttävät jo edistyneempiä ja mukautettuja XML-kokoonpanomuotoja.
Obix Framework on avoimen lähdekoodin kehys, joka tarjoaa yleiset keinot ja muodot määritystietojen tallentamiseksi XML: ään ja näiden tietojen käyttämiseen yksinkertaisten Java-objektien kautta. Se mahdollistaa kokoonpanotietojen modulaation sallimalla kokoonpanotiedostojen tuonnin ja sisällyttämisen toisiinsa sekä järjestämällä määritystiedot "moduuleiksi".
Lisäksi se tukee "kuumia" kokoonpanomuutoksia - määritystietojen muutosten automaattisen havaitsemisen ja automaattisen lataamisen avulla - ja tukee myös Java Naming and Directory Interface -sovellusliittymää (JNDI). Lisäksi se voidaan integroida Java-sovelluksiin monin tavoin, mukaan lukien Java Management Extensions (JMX) ja Java Platform, Enterprise Edition -kuuntelijat, jotka eivät vaadi koodausta, sekä tavalliset Java-luokat, joihin voidaan suoraan vedota. Lopuksi kehys tarjoaa helppokäyttöisen laajennussovellusliittymän, jonka avulla kehittäjät voivat laajentaa sitä suorittamaan alustamiseen liittyviä tehtäviä. Obix-tiimi on käyttänyt tätä sovellusliittymää alustustyökalujen tarjoamiseen muille avoimen lähdekoodin kehyksille, kuten Apachen log4j, horrostila ja Commons DBCP (tietokantayhteyspoolit).
Tässä opetusohjelmassa kuvaan hypoteettisen skenaarion, joka vaatii konfiguroitavan ohjelmiston ja jolle luomme luurankosovelluksia Obixin avulla. Ensimmäinen esimerkki on lähinnä "Hello World" -tyyppistä konseptitodistusta, kun taas toinen ja kolmas laajentavat sovellusta esittelemään vähemmän triviaalia kokoonpanonäkökohtia.
Huomaa, että kaikki tämän artikkelin koodinäytteet on pakattu arkistoksi, jonka voi ladata Resursseissa olevan linkin kautta.
Ongelmaskenaario
Rahoitusvarojen, kuten osakkeiden tai optioiden, arvostamiseen sisältyy joskus omaisuuden hinnan simulointi tuhansia kertoja ja näiden arvojen keskiarvon ottaminen - uskossa, että keskiarvo antaa parhaan arvoituksen omaisuuden "todellisesta" tulevasta arvosta. Tällaiset simulaatiot edellyttävät tyypillisesti tilastollista panosta omaisuuserän (varojen) nykyisen hinnan, keskimääräisen hinnan tietyllä aikavälillä sekä poikkeaman keskiarvosta.
Oletetaan, että olemme luomassa sovelluksen tällaisten instrumenttien arvostamiseen. Sellaisenaan tämän sovelluksen on ladattava tilastotiedot verkkopalvelun kautta, ja yksityiskohdat, kuten URL-osoite ja todennustiedot, yhteyden muodostamiseksi palveluun tallennetaan määritysasiakirjaan. Riittää sanoa, että tietylle arvostuspyynnölle suoritettavien simulaatioiden lukumäärän tulisi myös olla joustava ja sellaisenaan määriteltävä kokoonpanon kautta.
Esimerkki 1: Peruskokoonpanotiedosto
Tässä esimerkissä luomme sovelluksellemme peruskokoonpanotiedoston esimerkki1-config.xml, joka sisältää tiedot yhteyden muodostamiseksi verkkopalveluun, joka tarjoaa tilastolliset syötteet arvostusprosessiin. Tämä kokoonpanotiedosto tallentaa myös arviointipyynnön yhteydessä suoritettavien simulaatioiden määrän. Tämä tiedosto (samoin kuin muiden esimerkkien määritystiedostot) on tähän opetusohjelmaan liittyvän ladattavan arkiston määrityshakemistossa. Kokoonpanotiedoston sisältö on lueteltu seuraavasti:
//www.some-exchange.com/marketdata
trading_app_dbo
nopassword
10000
Jos tutkimme tiedostoa tarkemmin, huomaa, että se alkaa juurisolmusta ; tämä merkitsee Obix-määritysasiakirjan alkua. Niitä on neljä solmut, joista kukin kapseloi kokoonpanomerkinnän. Kolme ensimmäistä pitävät URL-osoitetta, käyttäjätunnusta ja salasanaa yhteyden muodostamiseksi tulopalveluun; lopullinen merkintä sisältää jokaiselle arviointipyynnölle suoritettavien simulaatioiden määrän. Huomaa, että jokaisella merkinnällä on yksilöllinen avain entryKey määritteen ja että kunkin merkinnän arvo on kapseloitu a solmu.
Seuraavaksi luomme arvostussovelluksemme luuranko, ja mikä tärkeintä, osoitamme, kuinka määritysasiakirja luetaan ajon aikana. Kiinnostavaa luokkaa kutsutaan Esimerkki1.java ja se löytyy tähän opetusohjelmaan liittyvästä ladattavan arkiston src-kansiosta. Luokan määritelmä on seuraava:
tuo org.obix.configuration.Configuration; tuo org.obix.configuration.ConfigurationAdapter; tuo org.obix.configuration.ConfigurationAdapterFactory;
public class Esimerkki1 {public static void main (String [] argumentit) {ConfigurationAdapterFactory adapterFactory = ConfigurationAdapterFactory.newAdapterFactory ();
ConfigurationAdapter-sovitin = adapterFactory.create (null);
adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); printMarketDataInfo (); }
private static void printMarketDataInfo () {Kokoonpano globalConfig = Configuration.getConfiguration ();
System.out.println ("Data Service URL: \ t \ t" + globalConfig.getValue ("market.data.service.url"));
System.out.println ("Data Service User-ID: \ t \ t" + globalConfig.getValue ("market.data.service.uid"));
System.out.println ("Datapalvelun salasana: \ t \ t" + globalConfig.getValue ("market.data.service.password"));
System.out.println ("Simulaatioiden määrä: \ t \ t" + globalConfig.getValue ("Valu.simulaatioiden lukumäärä")); }}
Tämän ja seuraavien esimerkkien suorittamiseksi sinun on ladattava Obix Frameworkin binääritiedostot luokkaan, johon pääset luokkatietäsi pitkin. Luokkatietäsi on viitattava Obix-kirjastoon, obix-framework.jar, joka löytyy kehyksen juurihakemiston lib-kansiosta. Tarvitset myös seuraavat kolmannen osapuolen avoimen lähdekoodin kirjastot: dom.jar, jaxen-full.jar, sax.jar, saxpath.jarja xercesImpl.jar, joka löytyy kehyksen juurihakemiston lib / thirdParty-kansiosta.
Tämän luokan suorittamisen pitäisi tuottaa seuraava tulos:
Data Service URL: //www.some-exchange.com/marketdata Data Service User-ID: trading_app_dbo Data Service Password: nopassword Simulaatioluku: 10000 Tämän luokan leikkaamiseksi aloitamme päämenetelmällä. Tämän menetelmän ensimmäinen rivi luo luokan esiintymän org.obix.configuration.ConfigurationAdapterFactory, joka vastaa määrityssovittimen (luokan ilmentymä) luomisesta org.obix.configuration.ConfigurationAdapter). Sovitin puolestaan on vastuussa kokoonpanodokumentin lukemisesta tietystä sijainnista (määritetty tiedostopoluksi tai URL-osoitteeksi).
Seuraava kooditiedosto lukee määritystiedostomme sisällön globaaliksi / staattiseksi kokoonpanoksi, kutsumalla sovitinmenetelmää adaptConfiguration ()ja välittämällä viittaus yleiseen instanssiin - saatu puhelusta Configuration.getConfiguration ()—Ja polku määritystiedostoon config / example1-config.xml:
adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); Huomaa, että on mahdollista luoda uusi kokoonpanotiedosto kokoonpanotietojemme tallentamiseksi sen sijaan, että käytettäisiin staattista (yleistä) esiintymää, mutta yksinkertaisuuden (ja lyhyyden) vuoksi käytämme tässä esimerkissä staattista esiintymää.
Seuraavaksi tarkastelemme menetelmää lyhyesti printMarketDataInfo (), joka yksinkertaisesti lukee kokoonpanomerkinnät (ts XML-solmut) ja tulostaa arvot (eli niiden lapsisolmut). Huomaa, että kunkin merkinnän arvo saadaan kutsumalla menetelmä getValue (...) liittyvästä Kokoonpano esimerkiksi syöttämällä merkinnän nimen / avaimen - kuten syötesolmuille on määritetty entryKey määritteen. Huomaa, että merkinnällä voi olla useita arvoja, jotka osoitetaan myöhemmin tässä opetusohjelmassa.
Esimerkki 2: Kokoonpanotietojen modulointi
Tämänkaltaiset sovellukset luovat tyypillisesti raportin, jossa yksityiskohtaisesti esitetään pyynnön tulokset jonkinlaisessa muodossa. Hypoteettinen sovelluksemme ei ole erilainen; se pystyy tuottamaan arvostusraportteja eri muodoissa. Lisäksi tietyssä sovellusajossa käytettävät raportointimuodot sanelevat määritysmerkinnät, ja kaikki luodut raportit lähetetään sähköpostitse organisaatiossamme olevalle vastaanottajaluettelolle - missä vastaanottajat määritetään myös kokoonpanojoukossa.
Loogisesti raportointi on erillinen toiminnallisuus - verrattuna arvostukseen - vaikka molemmat liittyvät toisiinsa; joten olisi järkevää sisällyttää "raportoinnin" määritystiedot. Tämä paitsi antaa kokoonpanodatan puhtaammin erilleen, mutta tekee myös aloittelijalle yksinkertaisemman visualisoida sovelluksen toiminnallisuuden rajaamisen.
Kapseloimme tämän esimerkin raportointikokoonpanon luomalla konfigurointimoduulin raportointia varten, joka on juurimoduulimme alataso. Muokataan viimeisen esimerkin määritystiedostoa liittämällä alla esitetty solmu sen solmujen luetteloon; tuloksena olevan tiedoston nimi on esimerkki2-config.xml ja se löytyy lähdearkiston konfigurointihakemistosta.
.................... .................... .......... ......... [email protected]
laskentataulukko tekstitiedosto pdf
Kaksi asiaa erottuu välittömästi tässä kokoonpanotiedostossa: ensimmäinen on tietysti moduulimääritelmä , jota seuraa moduulin toinen syöttösolmu . Aloitetaan moduulin määrittelystä. Obix-määritysasiakirja voi sisältää minkä tahansa määrän alimoduuleja. Kahden elementin estäminen - joita ei ole käsitelty tässä opetusohjelmassa - moduulit tukevat samaa solmujoukkoa kuin juurimoduuli. Toisin sanoen moduuleissa on merkintöjä ja ne voivat sisältää muita moduuleja; siten moduuleja voidaan tehokkaasti käyttää puurakenteen toistamiseen.
Muistathan, että viimeisessä esimerkissä mainitsin, että kokoonpanomerkinnällä voi olla useita arvoja. Tämä toiminnallisuus näkyy konfigurointimerkinnällä raportointimuotojen pitämiseksi, ts. . Kuten näette, tämä eroaa muista merkinnöistä siinä, että sillä on kolme arvoa - määritetään kolme muotoa, joissa raportit tulisi luoda.
Tarkastelemme nyt Java-koodia raporttien määritysmoduulin merkintöjen lukemiseen. Muokataan Java-lähdettä edelliseen esimerkkiin lisäämällä seuraava menetelmä; muokattu lähdetiedosto (luokka) nimetään uudelleen Esimerkki2.java, ja se löytyy tähän opetusohjelmaan liittyvän arkiston src-kansiosta:
private static void printReportingConfig () {Configuration globalConfig = Configuration.getConfiguration ();
Kokoonpanon reportConig = globalConfig.getModule ("report.parameters");
System.out.println ("Raporttien kohde: \ t \ t" + reportConig.getValue ("reports.destination.email"));
System.out.println ("Raportointimuodot: \ t \ t" + reportConig.getValues ("report_formats")); }
Suoritettaessa tätä luokkaa sen pitäisi tuottaa tulos:
Data Service URL: //www.some-exchange.com/marketdata Data Service User-ID: trading_app_dbo Data Service Password: nopassword Simulaatioluku: 10000
Reporting Config Parameters = Reports Destination: [email protected] Reporting Formats: [laskentataulukko, tekstitiedosto, pdf]
Tarkastellessamme lisämenetelmää yksityiskohtaisesti huomaamme, että se saa ensin viittauksen globaaliin Kokoonpano ilmentymä; sitten se etenee saamaan viitteen konfigurointimoduulille, jolla on raportoinnin kokoonpanotiedot. Menetelmä saavuttaa nämä tehtävät menetelmällä getModule (...) syöttämällä ylätason moduuliin vastaanotettavan moduulin tunnus. Huomaa, että tämä syntakse on yleinen siinä mielessä, että minkä tahansa moduulin alatason hankkiminen - vaikka ei juurimoduuli - saavutetaan kutsumalla getModule (...) annetulla moduulilla.
