Viegli konfigurējamas programmatūras izstrāde mūsdienu uzņēmējdarbības vidē ir ārkārtīgi svarīga. Programmatūras lietojumprogrammas vairs netiek vērtētas tikai pēc biznesa loģikas apjoma, ko tās iekapsulē; tos vērtē arī pēc tā, cik viegli tos uzturēt. Spēja mainīt programmatūras darbību, izmantojot konfigurāciju, ir svarīgs šī uzturēšanas cikla aspekts.
Lai gan Java valoda nodrošina vairākas funkcijas, piemēram, rekvizītu failus un resursu paketes, kas palīdz konfigurēt, tajās trūkst funkciju, kas nepieciešamas mūsdienu dinamiskai biznesa videi. Daudzi Java standarti, rīki un konteineri jau izmanto modernākus un pielāgotus XML konfigurācijas formātus.
Obix Framework ir atvērtā koda sistēma, kas nodrošina kopīgus līdzekļus un formātus konfigurācijas datu glabāšanai XML un piekļuvei šiem datiem, izmantojot vienkāršus Java objektus. Tas ļauj modulēt konfigurācijas datus, ļaujot konfigurācijas failus importēt un iekļaut savā starpā, kā arī organizējot konfigurācijas informāciju "moduļos".
Turklāt tas atbalsta "karstos" konfigurācijas grozījumus - izmantojot automātisku noteikšanu un konfigurācijas datu izmaiņu automātisku atkārtotu ielādēšanu -, kā arī nodrošina atbalstu Java Naming and Directory Interface API (JNDI). Turklāt to var integrēt Java lietojumprogrammās daudzos veidos, tostarp izmantojot Java Management Extensions (JMX) un Java Platform, Enterprise Edition klausītājus, kuriem nav nepieciešama kodēšana, kā arī vienkāršas Java klases, kuras var tieši izsaukt. Visbeidzot, ietvars nodrošina viegli lietojamu spraudņu API, kas ļauj izstrādātājiem to paplašināt, lai veiktu ar inicializāciju saistītus uzdevumus. Šo API Obix komanda ir izmantojusi, lai nodrošinātu inicializācijas utilītas citiem atvērtā koda ietvariem, piemēram, Apache log4j, hibernācijas un Commons DBCP (datu bāzes savienojumu kopas).
Šajā apmācībā es aprakstīju hipotētisku scenāriju, kuram nepieciešama konfigurējama programmatūra un kuram mēs izveidojam skeleta lietojumprogrammas, izmantojot Obix. Pirmais piemērs ir vistuvāk "Hello World" stila koncepcijas pierādījumam, bet otrais un trešais paplašina šo lietojumprogrammu, lai parādītu mazāk triviālus konfigurācijas aspektus.
Lūdzu, ņemiet vērā, ka visi šajā rakstā ietvertie kodu paraugi ir iepakoti kā arhīvs, kurus var lejupielādēt, izmantojot saiti, kas norādīta resursos.
Problēmas scenārijs
Finanšu aktīvu, piemēram, akciju vai iespēju, novērtēšana dažkārt ietver simtkārtīgas aktīvu cenas simulācijas un šo vērtību vidējās vērtības ņemšanu - uzskatot, ka vidējais rādītājs ļauj vislabāk uzminēt aktīva "patieso" nākotnes vērtību. Šādām simulācijām parasti nepieciešama statistikas ievade aktīva (-u) pašreizējās cenas, vidējās cenas formā noteiktā laika posmā, kā arī novirzes no vidējās vērtības.
Pieņemsim, ka mēs veidojam lietojumprogrammu šādu instrumentu novērtēšanai. Šai lietojumprogrammai būs jālejupielādē statistikas dati, izmantojot tīmekļa pakalpojumu, un detalizēta informācija, piemēram, URL un autentifikācijas informācija, lai izveidotu savienojumu ar šo pakalpojumu, tiek glabāta konfigurācijas dokumentā. Pietiek pateikt, ka simulāciju skaitam, kas jāveic konkrētam vērtēšanas pieprasījumam, arī jābūt elastīgam, un tas tiks noteikts, izmantojot konfigurāciju.
1. piemērs: pamata konfigurācijas fails
Šajā piemērā mēs savai lietojumprogrammai izveidojam pamata konfigurācijas failu example1-config.xml, kurā glabājas detalizēta informācija par savienojumu ar tīmekļa pakalpojumu, kas sniedz statistikas datus vērtēšanas procesam. Šajā konfigurācijas failā tiks saglabāts arī simulāciju skaits, kas jāveic jebkuram vērtēšanas pieprasījumam. Šis fails (kā arī citu piemēru konfigurācijas faili) atrodas ar šo apmācību saistītā lejupielādējamā arhīva konfigurācijas direktorijā. Konfigurācijas faila saturs ir norādīts šādi:
//www.some-exchange.com/marketdata
trading_app_dbo
nopassword
10000
Ja mēs sīkāk pārbaudīsim failu, ievērojiet, ka tas sākas ar saknes mezglu ; tas iezīmē Obix konfigurācijas dokumenta sākumu. Ir četri mezgli, katrs iekapsulējot konfigurācijas ierakstu. Pirmie trīs tur URL, lietotāja ID un paroli, lai izveidotu savienojumu ar ievades pakalpojumu; galīgajā ierakstā ir simulāciju skaits, kas jāveic katram vērtēšanas pieprasījumam. Ievērojiet, ka katram ierakstam ir unikāla atslēga, kā to nosaka entryKey atribūtu un ka katra ieraksta vērtība ir iekapsulēta ar mezgls.
Pēc tam mēs izveidojam mūsu vērtēšanas lietojumprogrammas skeletu un, vēl svarīgāk, mēs parādām, kā konfigurācijas dokuments tiek lasīts izpildlaikā. Tiek saukta interešu klase Piemērs1.java un to var atrast ar šo apmācību saistītā lejupielādējamā arhīva mapē src. Klases definīcija ir šāda:
importēt org.obix.configuration.Configuration; importēt org.obix.configuration.ConfigurationAdapter; importēt org.obix.configuration.ConfigurationAdapterFactory;
public class 1. piemērs {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 ("Datu pakalpojuma URL: \ t \ t" + globalConfig.getValue ("market.data.service.url"));
System.out.println ("Datu pakalpojuma lietotāja ID: \ t \ t" + globalConfig.getValue ("market.data.service.uid"));
System.out.println ("Datu pakalpojuma parole: \ t \ t" + globalConfig.getValue ("market.data.service.password"));
System.out.println ("Simulāciju skaits: \ t \ t" + globalConfig.getValue ("Skaidrs.vērtības.simulācijas")); }}
Lai palaistu šo un nākamos piemērus, lejupielādējiet Obix Framework bināros failus vietā, kas ir pieejama, izmantojot jūsu klases ceļu. Jūsu klases ceļam ir jāatsaucas uz Obix bibliotēku, obix-framework.jar, kuru var atrast ietvara saknes direktorija mapē lib. Jums būs nepieciešamas arī šādas trešo pušu atvērtā pirmkoda bibliotēkas: dom.jar, jaxen-full.jar, sax.jar, saxpath.jar, un xercesImpl.jar, kuru var atrast ietvara saknes direktorija mapē lib / thirdParty.
Izpildot šo klasi, vajadzētu iegūt šādu rezultātu:
Datu pakalpojuma URL: //www.some-exchange.com/marketdata Datu pakalpojuma lietotāja ID: trading_app_dbo Datu pakalpojuma parole: nopassword Simulācijas skaits: 10000 Lai sadalītu šo klasi, mēs sākam ar galveno metodi. Šīs metodes pirmā rinda izveido klases instanci org.obix.configuration.ConfigurationAdapterFactory, kas ir atbildīgs par konfigurācijas adaptera izveidi (klases org.obix.configuration.ConfigurationAdapter). Savukārt adapteris ir atbildīgs par konfigurācijas dokumenta patiesu nolasīšanu no noteiktas vietas (norādīts kā faila ceļš vai URL).
Šis koda izvilkums nolasa mūsu konfigurācijas faila saturu globālajā / statiskajā konfigurācijas instancē, atsaucoties uz adaptera metodi adaptConfiguration ()un nododot atsauci uz globālo instanci, kas iegūta zvana laikā Configuration.getConfiguration ()—Un ceļš uz mūsu konfigurācijas failu config / example1-config.xml:
adapter.adaptConfiguration (Configuration.getConfiguration (), "config / example1-config.xml"); Ņemiet vērā, ka ir iespējams izveidot jaunu konfigurācijas gadījumu, lai saglabātu mūsu konfigurācijas datus, nevis izmantotu statisko (globālo) gadījumu, taču vienkāršības (un īsuma) labad šim piemēram izmantojam statisko gadījumu.
Tālāk mēs īsi pārbaudām metodi printMarketDataInfo (), kas vienkārši nolasa konfigurācijas ierakstus (t.i., XML mezgli) un izdrukā to vērtības (t.i., viņu bērnu mezgli). Ievērojiet, ka katra ieraksta vērtība tiek iegūta, izsaucot metodi getValue (...) par saistīto Konfigurācija piemēram, ievadot ieraksta nosaukumu / atslēgu - kā norādīts ieraksta mezglā entryKey atribūts. Kā malā ņemiet vērā, ka ierakstam var būt vairākas vērtības, kas tiks parādītas vēlāk šajā apmācībā.
2. piemērs: konfigurācijas datu modulēšana
Šāda veida lietojumi parasti ģenerēs ziņojumu, kurā sīki aprakstīti pieprasījuma rezultāti kaut kādā formātā. Mūsu hipotētiskais pielietojums neatšķiras; tā spēj sagatavot vērtēšanas ziņojumus dažādos formātos. Turklāt atskaites formātus, kas tiek izmantoti noteiktā lietojumprogrammas izpildē, nosaka konfigurācijas ieraksts, un visi ģenerētie pārskati tiek nosūtīti pa e-pastu mūsu organizācijas saņēmēju sarakstam, kur adresāti ir norādīti arī konfigurācijas komplektā.
Loģiski, ka ziņošana ir atšķirīga funkcionalitāte, salīdzinot ar vērtēšanu, kaut arī abi ir saistīti; tāpēc būtu diezgan saprātīgi iekapsulēt mūsu "pārskatu" konfigurācijas datus. Tas ne tikai nodrošina tīrāku konfigurācijas datu atdalīšanu, bet arī padara iesācēju vienkāršāku, lai vizualizētu funkcionalitātes robežas lietojumprogrammā.
Šajā piemērā mēs apkopojam pārskatu konfigurāciju, izveidojot konfigurēšanas moduli ziņošanai, kas ir mūsu saknes moduļa pakārtotais elements. Mēs pārveidojam konfigurācijas failu no pēdējā piemēra, pievienojot zemāk redzamo mezglu tā mezglu sarakstam; iegūto failu sauc par example2-config.xml, un to var atrast avota arhīva konfigurācijas direktorijā.
.................... .................... .......... ......... [email protected]
izklājlapas teksta fails pdf
Šajā konfigurācijas failā uzreiz izceļas divas lietas: pirmā, protams, ir mūsu moduļa definīcija , kam seko moduļa otrais ievadīšanas mezgls . Mēs sākam ar moduļa definīciju. Obix konfigurācijas dokumentā var būt jebkurš skaits apakšmoduļu. Divu elementu aizliegšana - kas šajā apmācībā nav apspriesti - moduļi atbalsta to pašu mezglu kopu kā saknes modulis. Citiem vārdiem sakot, moduļiem ir ieraksti un tie var saturēt citus moduļus; tādējādi moduļus var efektīvi izmantot, lai atveidotu koka struktūru.
Atgādināsim, ka pēdējā piemērā es minēju, ka konfigurācijas ierakstam var būt vairākas vērtības. Šo funkcionalitāti parāda konfigurācijas ieraksts pārskatu formātu glabāšanai, t.i., . Kā redzat, tas atšķiras no citiem ierakstiem, jo tam ir trīs vērtības - norādot trīs formātus, kādos jāveido pārskati.
Tagad mēs pārbaudām Java kodu, lai lasītu ierakstus mūsu pārskatu konfigurācijas modulī. Mēs modificējam Java avotu iepriekšējam piemēram, pievienojot šādu metodi; modificētais avota fails (klase) tiek pārdēvēts Piemērs2.java, un to var atrast ar šo apmācību saistītā arhīva mapē src:
private static void printReportingConfig () {Configuration globalConfig = Configuration.getConfiguration ();
Konfigurācija reportConig = globalConfig.getModule ("report.parameters");
System.out.println ("Pārskatu galamērķis: \ t \ t" + reportConig.getValue ("reports.destination.email"));
System.out.println ("Pārskatu formāti: \ t \ t" + reportConig.getValues ("report_formats")); }
Izpildot šo klasi, tai vajadzētu radīt rezultātu:
Datu pakalpojuma URL: //www.some-exchange.com/marketdata Datu pakalpojuma lietotāja ID: trading_app_dbo Datu pakalpojuma parole: nopassword Simulācijas skaits: 10000
Reporting Config Parameters = Reports Destination: [email protected] Reporting Format: [izklājlapa, teksta fails, pdf]
Detalizēti izpētot papildu metodi, mēs pamanām, ka tā vispirms iegūst atsauci uz globālo Konfigurācija instance; pēc tam tā iegūst atsauci uz konfigurācijas moduli, kurā atrodas atskaites konfigurācijas informācija. Metode šos uzdevumus sasniedz, atsaucoties uz metodi getModule (...) vecāku modulī, nododot saņemamā moduļa ID. Ņemiet vērā, ka šī sintakse ir vispārīga tādā nozīmē, ka jebkura moduļa - pat ja ne saknes moduļa - pakārtotā iegūšana tiek panākta, izsaucot getModule (...) uz norādītā moduļa.
