Programmēšana

JNDI pārskats, 1. daļa: Ievads nosaukumu pakalpojumu sniegšanā

Tie no jums, kas esat bijuši bibliotēkā un joprojām varat atcerēties šo pieredzi, var atcerēties bibliotēkas grāmatas atrašanas procesu. Ja jums nav sakaru ar savu antikvariātu, šī situācija šķitīs nepazīstama; bet ik pa laikam es dodas prom uz vietējo bibliotēku, lai meklētu īstu, bezsaistes grāmatu. Bibliotēkas ir piepildītas ar tūkstošiem lietu - tās ir putekļainas, izgatavotas no koksnes masas un govju ādas, taču tās ir savādā veidā aizraujošas. Jebkurā gadījumā, kad rodas piespiešanās atrast konkrētu, es izvairos no naiva kursa, ejot augšup un lejup pa bibliotēkas ejām, meklējot to, un tā vietā vēršos pie karšu kataloga.

TEXTBOX: TEXTBOX_HEAD: JNDI pārskats: Izlasiet visu sēriju!

  • 1. daļa. Ievads nosaukumu pakalpojumu sniegšanā
  • 2. daļa. Izmantojiet JNDI direktoriju pakalpojumus, lai labāk pārvaldītu izplatītās lietojumprogrammas

  • 3. daļa. Izmantojiet JNDI, lai saglabātu izplatītās lietojumprogrammas objektus

  • 4. daļa. Sapulciniet kopā ar JNDI iespējotu lietojumprogrammu: END_TEXTBOX

Kartīšu katalogs nezinātājiem kartē grāmatu nosaukumus līdz to atrašanās vietai bibliotēkā. Vispirms dodoties uz karšu katalogu un uzmeklējot grāmatas atrašanās vietu, es sev ietaupu ievērojamu daudzumu pastaigu. (Starp citu, esmu dzirdējis, ka dažas bibliotēkas patroniem faktiski ļauj karšu kataloga vietā izmantot datorus. Viņiem viss ir labi - tagad, ja viņi vienkārši ievietos grāmatās esošo informāciju tajā datorā, kur tā pieder. ..)

Lai cik pārsteidzoši tas varētu šķist, karšu kataloga jēdziens ir diezgan ērts arī skaitļošanas pasaulē. Skaitļošanā mēs to saucam par vārdu pakalpojums, kas vārdus saista ar pakalpojumu atrašanās vietām un informāciju. Tas nodrošina datorprogrammas ar vienu vietu, kur viņi var atrast nepieciešamos resursus. Savā ziņā programmas netērē laiku, veicot elektronisku ekvivalentu ejot augšup un lejup pa ejām, un neprasa, lai atrašanās vietas tiktu kodētas to loģikā.

Resursu atrašana ir īpaši svarīga liela mēroga uzņēmumu vidēs, kur jūsu izveidotās lietojumprogrammas var būt atkarīgas no pakalpojumiem, ko nodrošina lietojumprogrammas, kuras citas nodaļas raksta citās nodaļās. Labi izveidota nosaukumu infrastruktūra padara šādus projektus iespējamus - un to trūkums padara tos neiespējamus. Patiesībā daudzi biznesa procesu pārveidošanas centieni sākas ar spēcīgas, uzņēmuma mēroga nosaukumu un direktoriju infrastruktūras izstrādi un ieviešanu.

Šajā mēnesī es iepazīstinu ar Java Naming and Directory Interface (JNDI). JNDI nodrošina kopsaucēja saskarni daudziem esošajiem nosaukumu pakalpojumiem. Kā tāds JNDI nebija paredzēts, lai aizstātu esošo tehnoloģiju; tā vietā tas nodrošina kopēju saskarni esošajiem nosaukumu pakalpojumiem. Sāksim apskatīt dažus no šiem pakalpojumiem.

Ievads nosaukumu pakalpojumu sniegšanā

Zemāk redzamajā attēlā ir parādīta vispārēja nosaukšanas pakalpojuma organizācija.

Vārdu piešķiršanas pakalpojums uztur virkni stiprinājumi. Saistīšana saista nosaukumus ar objektiem. Visi nosaukšanas sistēmas objekti tiek nosaukti vienādi (tas ir, viņi abonē to pašu nosaukšanas konvencija). Klienti izmanto nosaukumu pakalpojumu, lai atrastu objektus pēc nosaukuma.

Ir vairāki esošie vārdu nosaukšanas pakalpojumi, no kuriem dažus aprakstīšu tālāk. Katrs no tiem seko iepriekšminētajam paraugam, taču atšķiras detaļās.

  • COS (Common Object Services) nosaukšana: Vārdu piešķiršanas pakalpojums CORBA lietojumprogrammām; ļauj lietojumprogrammām saglabāt un piekļūt atsaucēm uz CORBA objektiem.

  • DNS (domēna vārdu sistēma): Interneta nosaukumu pakalpojums; kartē cilvēkiem draudzīgus vārdus (piemēram, www.etcee.com) datoriem draudzīgās IP (interneta protokola) adresēs ar punktētu četrrindīšu apzīmējumu (207.69.175.36). Interesanti, ka DNS ir a izplatīts nosaukumu pakalpojums, kas nozīmē, ka pakalpojums un tā pamatā esošā datu bāze ir izplatīta daudzos interneta resursdatoros.

  • LDAP (viegls direktorijas piekļuves protokols): Izstrādāja Mičiganas Universitāte; kā norāda tās nosaukums, tā ir viegla DAP (Directory Access Protocol) versija, kas savukārt ir daļa no tīkla direktoriju pakalpojumu standarta X.500. Pašlaik vairāk nekā 40 uzņēmumi atbalsta LDAP.

  • NIS (tīkla informācijas sistēma) un NIS +: Tīkla nosaukšanas pakalpojumi, ko izstrādājusi Sun Microsystems. Abi lietotāji ļauj piekļūt jebkura resursdatora failiem un lietojumprogrammām ar vienu ID un paroli.

Kopīgas iezīmes

Kā jau minēju iepriekš, nosaukšanas sistēmas galvenā funkcija ir saistīt nosaukumus ar objektiem (vai dažos gadījumos ar atsaucēm uz objektiem - vairāk par to vienā mirklī). Lai pakalpojums būtu nosaukšanas pakalpojums, tam vismaz jānodrošina spēja saistīt nosaukumus ar objektiem un meklēt objektus pēc nosaukuma.

Daudzās nosaukumu sistēmās objekti netiek tieši uzglabāti. Tā vietā viņi saglabā atsauces uz objektiem. Kā piemēru ņemiet vērā DNS. Adrese 207.69.175.36 ir atsauce uz datora atrašanās vietu internetā, nevis uz pašu datoru.

JNDI nodrošina saskarni, kas atbalsta visu šo kopīgo funkcionalitāti. Es šo interfeisu iepazīstināšu vēlāk šajā rakstā.

Viņu atšķirības

Ir arī svarīgi saprast, kā esošie nosaukumu pakalpojumi atšķiras, jo JNDI jānodrošina praktiska abstrakcija, kas apiet šīs atšķirības.

Neatkarīgi no funkcionālajām atšķirībām visievērojamākā atšķirība ir veids, kā katram vārdu pakalpojumam ir jānorāda nosaukumi - tā nosaukšanas kārtība. Dažiem piemēriem vajadzētu ilustrēt problēmu.

DNS DNS nosaukumi tiek veidoti no komponentiem, kurus atdala punkti ("."). Viņi lasa no labās uz kreiso. Nosaukumā "www.etcee.com" domēnā "etcee.com" tiek nosaukta mašīna ar nosaukumu "www". Tāpat nosaukums "etcee.com" augstākā līmeņa domēnā "com" nosauc domēnu "etcee".

LDAP situācija ir nedaudz sarežģītāka. Vārdi tiek veidoti no komponentiem, kas atdalīti ar komatiem (","). Tāpat kā DNS nosaukumus, tie lasa no labās uz kreiso. Tomēr LDAP nosaukuma komponenti jānorāda kā nosaukuma / vērtības pāri. Nosaukums "cn = Todd Sundsted, o = ComFrame, c = US" organizācijā "o = ComFrame, c = US" nosauc personu "cn = Todd Sundsted". Tāpat nosaukums "o = ComFrame, c = US" organizāciju nosauc par "o = ComFrame" valstī "c = US".

Kā ilustrē iepriekš minētie piemēri, tikai nosaukšanas pakalpojuma nosaukšanas kārtība var ieviest JNDI ievērojamu daudzumu pamata nosaukuma pakalpojuma garšas. Šī nav funkcija, kurai jābūt no ieviešanas neatkarīgai saskarnei.

JNDI atrisina šo problēmu ar Nosaukums klase un tās apakšklases un palīgu klases. The Nosaukums klase apzīmē vārdu, kas sastāv no sakārtotām apvārdu secībām, un nodrošina metodes darbam ar nosaukumiem, kas nav atkarīgi no pamata nosaukuma pakalpojuma.

Ieskats JNDI nosaukumos

Kā jau minēju iepriekš, ir svarīgi atcerēties, ka JNDI ir interfeiss nevis an ieviešana. Šim faktam ir daži trūkumi - jums ir nepieciešama piekļuve esošam nosaukumu pakalpojumam (piemēram, LDAP pakalpojumam), un jums ir kaut kas jāsaprot par tā darbību, lai spēlētu ar JNDI. No otras puses, tas ļauj JNDI nemanāmi integrēties esošajā skaitļošanas vidē, kur pastāv pastāvīgs izveidots nosaukumu pakalpojums.

JNDI nosaukšana ir saistīta ar nelielu klašu komplektu un nedaudzām operācijām. Apskatīsim tos.

Konteksts un InitialContext

The Konteksts saskarnei ir galvenā loma JNDI. Konteksts apzīmē saistījumu kopu nosaukumpakalpojumā, kuriem visiem ir vienāda nosaukumu piešķiršanas kārtība. A Konteksts objekts nodrošina metodes nosaukumu saistīšanai ar objektiem un vārdu atsaistīšanu no objektiem, objektu pārdēvēšanai un saistījumu uzskaitīšanai.

Daži nosaukumpakalpojumi nodrošina arī apakšteksta funkcionalitāti. Līdzīgi kā direktorijā failu sistēmā, arī apakšteksts ir konteksts kontekstā. Šī hierarhiskā struktūra ļauj labāk organizēt informāciju. Lai nosauktu pakalpojumus, kas atbalsta apakštekstus, Konteksts klase piedāvā arī metodes apakštekstu radīšanai un iznīcināšanai.

JNDI veic visas nosaukšanas darbības attiecībā pret kontekstu. Lai palīdzētu atrast vietu, kur sākt, JNDI specifikācijā ir definēts InitialContext klasē. Šī klase tiek saīsināta ar rekvizītiem, kas nosaka izmantojamā nosaukumpakalpojuma veidu, un, nosaucot pakalpojumus, kas nodrošina drošību, ID un paroli, kas jāizmanto savienojuma izveidē.

Tiem no jums, kas pārzina RMI Nosaukšana klasē, daudzas no metodēm, ko nodrošina Konteksts zemāk aprakstītā saskarne izskatīsies pazīstama. Apskatīsim Kontekstsmetodes:

  • void bind (virknes virknes nosaukums, objekta objekts): Saista objektam nosaukumu. Nosaukums nedrīkst būt saistīts ar citu objektu. Visiem starpposma kontekstiem jau ir jābūt.

  • void rebind (virknes virknes nosaukums, objekta objekts): Saista objektam nosaukumu. Visiem starpposma kontekstiem jau ir jābūt.

  • Objekta meklēšana (virkne stringName): Atgriež norādīto objektu.

  • void unbind (String stringName): Atsauc norādīto objektu.

The Konteksts interfeiss nodrošina arī saites pārdēvēšanas un uzskaitīšanas metodes.

  • void pārdēvēt (virkne stringOldName, virkne stringNewName): Maina nosaukumu, ar kuru objekts ir saistīts.
  • NamingEnumeration listBindings (virknes virkneName): Atgriež uzskaitījumu, kas satur nosaukumus, kas saistīti ar norādīto kontekstu, kopā ar objektiem un ar tiem saistīto objektu klases nosaukumiem.

  • NamingEnumeration saraksts (String stringName): Atgriež uzskaitījumu, kas satur nosaukumus, kas saistīti ar norādīto kontekstu, kopā ar tiem piesaistīto objektu klases nosaukumiem.

Katrai no šīm metodēm ir brālis vai māsa, kas ņem a Nosaukums objekts a vietā Stīga objekts. A Nosaukums objekts apzīmē vispārīgu nosaukumu. The Nosaukums klase ļauj programmai manipulēt ar vārdiem, nezinot tik daudz par konkrēto izmantoto nosaukumu pakalpojumu.

Piemērs

Tālāk sniegtajā piemērā ir parādīts, kā izveidot savienojumu ar nosaukumu pakalpojumu, uzskaitīt visus saistījumus vai norādīt konkrētu saistīšanu. Tas izmanto failu sistēmas pakalpojumu sniedzēju, kas ir viens no atsauces JNDI pakalpojumu sniedzēju ieviešanas veidiem, ko nodrošina Sun. Failu sistēmas pakalpojumu sniedzējs padara failu sistēmu līdzīgu nosaukšanas pakalpojumam (kas daudzējādā ziņā ir arī failu nosaukumi) / foo / bar / baz ir nosaukumi un ir saistīti ar objektiem, piemēram, failiem un direktorijiem). Es to izvēlējos, jo ikvienam ir piekļuve failu sistēmai (atšķirībā no, piemēram, LDAP servera).

importēt javax.naming.Context; importēt javax.naming.InitialContext; importēt javax.naming.Binding; importēt javax.naming.NamingEnumeration; importēt javax.naming.NamingException; importēt java.util.Hashtable; public class Main {public static void main (String [] rgstring) {mēģināt {// Izveidot sākotnējo kontekstu. Vide // informācija norāda JNDI nodrošinātāju, kas jāizmanto //, un sākotnējo URL, kas jāizmanto (mūsu gadījumā // direktorija URL formā - fails: /// ...). Hashtable hashtableEnvironment = new Hashtable (); hashtableEnvironment.put (konteksts.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory"); hashtableEnvironment.put (konteksts.PROVIDER_URL, rgstring [0]); Konteksta konteksts = new InitialContext (hashtableEnvironment); // Ja jūs nenorādāt citus komandrindas argumentus, // uzskaitiet visus nosaukumus norādītajā kontekstā un // objektus, ar kuriem tie ir saistīti. if (rgstring.length == 1) {NamingEnumeration namingenumeration = context.listBindings (""); while (namingenumeration.hasMore ()) {Iesiešanas saistīšana = (Iesiešana) namingenumeration.next (); System.out.println (saistošs.getName () + "" + saistošs.getObject ()); }} // Pretējā gadījumā norādiet // norādīto argumentu nosaukumus un saistījumus. else {for (int i = 1; i <rgstring.length; i ++) {Object object = context.lookup (rgstring [i]); System.out.println (rgstring [i] + "" + objekts); }} context.close (); } catch (NamingException namingexception) {namingexception.printStackTrace (); }}} 

Iepriekš uzskaitītā programma vispirms izveido sākotnējo kontekstu no norādītā JNDI nodrošinātāja (šajā gadījumā Sun failu sistēmas nodrošinātāja) un URL, kas norāda vietējo direktoriju. Ja papildu komandrindas argumenti nav norādīti, programmā ir uzskaitīti visu entītiju objekti un nosaukumi norādītajā direktorijā. Pretējā gadījumā tajā ir uzskaitīti tikai tie komandrindā norādītie objekti un nosaukumi.

Secinājums

Tagad jums vajadzētu gan izprast, gan novērtēt pakalpojumu nosaukšanu kopumā un jo īpaši JNDI. Sadalītās vidēs tie ir vērtīgi rīki informācijas un resursu atrašanai. JNDI ļauj strādāt ar dažādiem nosaukumu pakalpojumiem, neapgūstot daudzus API. Nākamajā mēnesī mēs apskatīsim JNDI otro pusi - tās direktoriju funkcijas.

Kopš datori kļuva pieejami ērtos galddatoru modeļos, Tods Sundsteds raksta programmas. Lai gan Tods sākotnēji interesējās par izplatītu lietojumprogrammu izveidi C ++, Tods pārgāja uz Java programmēšanas valodu, kad tā kļuva par acīmredzamu izvēli šāda veida lietām. Papildus rakstīšanai Tods strādā arī kā Java arhitekts ar programmatūru ComFrame.

Uzziniet vairāk par šo tēmu

  • Lejupielādējiet pilnu šī raksta avota kodu zip formātā

    //images.techhive.com/downloads/idge/imported/article/jvw/2000/01/jw-01-howto.zip

  • Visas lietas JNDI

    //java.sun.com/products/jndi/

  • JNDI dokumentācija

    //java.sun.com/products/jndi/docs.html

  • Pašlaik pieejami pakalpojumu sniedzēji

    //java.sun.com/products/jndi/serviceproviders.html

  • Pilns iepriekšējo saraksts How-To Java kolonnas

    //www.javaworld.com/javaworld/topicalindex/jw-ti-howto.html

Šo stāstu "JNDI pārskats, 1. daļa: Ievads nosaukumu pakalpojumu sniegšanai" sākotnēji publicēja JavaWorld.

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