Programmering

Find tjenester med Jini-opslagstjenesten

Jini-opslagstjenesten, den centrale komponent i Ninis runtime-infrastruktur, tilbyder Jini-klienter en fleksibel og effektiv måde at finde Jini-tjenester på. Det giver tjenesteudbydere mulighed for at annoncere for deres tjenester og gør det muligt for klienter at finde og hente hjælp fra disse tjenester.

For at interagere med opslagstjenesten skal klienten først skaffe sig en service registrar objekt via opdagelse, en protokol på netværksniveau, der bruges af Ninis runtime-infrastruktur. Discovery gør det muligt for klienter og tjenester at finde opslagstjenester. (For mere information om opdagelse, se Ressourcer.) The service registrar objekt, der implementerer net.jini.core.lookup.ServiceRegistrar interface, gør det muligt for klienten at interagere med opslagstjenesten. For at finde de ønskede tjenester bygger klienter en Service skabelon, en forekomst af klasse net.jini.core.lookup.ServiceTemplate, og videregive det til en af ​​to kig op() metoder erklæret i Service Registrering interface. Hver kig op() metode sender serviceskabelonen til opslagstjenesten, som udfører forespørgslen og returnerer matchende serviceobjekter til klienten.

Generelt ser en klient en tjeneste op efter Java-type, normalt en grænseflade. For eksempel, hvis en klient har brug for en printer, komponerer den en serviceskabelon, der inkluderer en Klasse objekt for en velkendt grænseflade til printertjenester. Alle printertjenester implementerer grænsefladen. Opslagstjenesten returnerer et serviceobjekt (eller objekter), der implementerer denne grænseflade. Du kan medtage attributter i serviceskabelonen for at indsnævre antallet af matches for en sådan typebaseret søgning. Klienten bruger printertjenesten ved at påkalde serviceobjektet de metoder, der er angivet i den velkendte grænseflade.

ServiceTemplate-klassen

Med Service skabelon klasse, kan du udtrykke søgekriterierne for Jini-opslag. Klassen består udelukkende af disse tre offentlige felter:

public Entry [] attributSetTemplates; public ServiceID serviceID; offentlige klasse [] servicetyper; 

Service skabelon har ingen metoder, og dens forekomster tjener kun som "struktur" -lignende containere til opslagstjenesteforespørgsler. Matchninger udføres som beskrevet i følgende uddrag fra Service skabelon's javadoc side:

Elementer i opslagstjenesten matches med en forekomst af [Service skabelon]. En servicepost (vare) matcher en serviceskabelon (tmpl) hvis:

  • item.serviceID lige med tmpl.serviceID (eller hvis tmpl.serviceID er nul)
  • item.service [service-objektet] er en forekomst af enhver type i tmpl.serviceTypes
  • item.attributeSets indeholder mindst en matchende post for hver indtastningsskabelon i tmpl.attributeSetTemplates

En post matcher en indtastningsskabelon, hvis skabelonklassen er den samme som eller en superklasse af indgangsklassen, og hvert ikke-nul-felt i skabelonen svarer til det tilsvarende felt i posten. Hver post kan bruges til at matche mere end en skabelon. Bemærk, at i en serviceskabelon til serviceTypes og attributSetTemplates, et null-felt svarer til et tomt array; begge repræsenterer et jokertegn.

Som beskrevet her kan serviceskabelonen omfatte en henvisning til en matrix af Klasse genstande. Disse objekter angiver opslagstjenesten Java-typen (eller -typerne) for det serviceobjekt, som klienten ønsker. Serviceskabelonen kan også omfatte en service-id, som entydigt identificerer en tjeneste og attributter, der skal stemme overens med de attributter, der er uploadet af tjenesteudbyderen i serviceelementet. Serviceskabelonen kan også indeholde jokertegn til et af disse felter. Et jokertegn i service-ID-feltet vil f.eks. Matche ethvert service-ID.

Opslagsmetoderne ()

Det Service Registrering's kig op() metoder tager to overbelastede former. De to formularer adskiller sig hovedsageligt i antallet af matches og serviceposter, hver enkelt returnerer. Formularen med to parametre kan returnere flere matches af forespørgslen udtrykt i Service skabelon, mens formularen med en parameter kun returnerer et match. Derudover returnerer toparameterskemaet hele serviceposter; formularen med en parameter returnerer kun serviceobjektet.

To-parameterformen for opslag ()

Her er et javadoc-uddrag, der forklarer toparameterformen af kig op():

offentlig ServiceMatches-opslag (ServiceTemplate tmpl, int maxMatches) kaster java.rmi.RemoteException; 

[Det] returnerer højst maxMatches elementer, der matcher skabelonen plus det samlede antal varer, der matcher skabelonen. Returneringsværdien er aldrig nul, og arrayet med returnerede varer er kun nul hvis maxMatches er nul. For hver returneret vare, hvis serviceobjektet ikke kan deserialiseres, er servicefeltet for varen indstillet til nul og ingen undtagelse kastes. Tilsvarende, hvis et attributtsæt ikke kan deserialiseres, skal elementet i attributSæt array er indstillet til nul og ingen undtagelse kastes.

Her er ServiceMatches klasse:

pakke net.jini.core.lookup;

public class ServiceMatches udvider java.lang.Object implementerer java.io.Serializable {

public ServiceItem [] -genstande; public int totalMatches; }

Og her er ServiceItem klasse:

pakke net.jini.core.lookup;

public class ServiceMatches udvider java.lang.Object implementerer java.io.Serializable {

public Entry [] attributSets; offentlig java.lang.Object-tjeneste; public ServiceID serviceID; }

Som nævnt tidligere, hvert element i genstande array, der returneres af formularen med to parametre, er et komplet serviceelement, der inkluderer serviceobjektet, service-id og alle attributter. Det maxMatches felt hjælper klienter med at administrere antallet af objekter, der returneres af dette kig op().

Længden af genstande array i det returnerede ServiceMatches objekt er mindre end eller lig med den værdi, der sendes til kig op() i maxMatches. Det samlede antal matchende serviceprodukter (returneret i totalMatches) er større end eller lig med længden af genstande array.

For eksempel hvis maxMatches er 50, og serviceskabelonen matcher 25 varer, længden på den returnerede genstande array og værdien af totalMatches er begge 25. Alternativt, hvis maxMatches er 50, men serviceskabelonen matcher 100 varer, længden på den returnerede genstande array er 50 og værdien af totalMatches er 100. Når en serviceskabelon matcher mere end maxMatches serviceartikler, serviceartiklerne returneret med to-parameteren kig op() vælges tilfældigt fra det komplette sæt af matchende serviceelementer.

Enparameterformen for opslag ()

Den ene parameter kig op() metoden returnerer et matchende serviceobjekt valgt tilfældigt blandt alle matches. Her er et javadoc-uddrag, der forklarer denne form:

offentlig objektopslag (ServiceTemplate tmpl) kaster java.rmi.RemoteException; 
Returnerer serviceobjektet (dvs. bare ServiceItem.service) fra et element, der matcher skabelonen, eller nul hvis der ikke er noget match. Hvis flere elementer matcher skabelonen, er det vilkårligt, hvilket serviceobjekt der returneres. Hvis det returnerede objekt ikke kan deserialiseres, an UnmarshalException kastes med standard RMI-semantikken.

Fordi en-parameteren kig op() returnerer kun et matchende serviceobjekt, klienter kan minimere antallet af downloadede objekttilstands- og klassefiler. Men fordi det returnerede serviceobjekt er valgt vilkårligt og ikke identificeres af et service-ID eller beskrevet af tilknyttede attributsæt, skal klienten være sikker på at nogen matchende serviceobjekt er tilstrækkeligt.

Browsermetoderne

Ud over de to kig op() metoder, den Service Registrering har tre browsing metoder, som giver information om registrerede serviceprodukter. De tre metoder - getServiceTypes (), getEntryClasses ()og getFieldValues ​​() -- hedder browsermetoder fordi de gør det muligt for klienter at gennemse tjenesterne og attributterne i opslagstjenesten.

Det getServiceTypes () metoden tager en Service skabelon (det samme Service skabelon der sendes til kig op() metoder) og a Snor præfiks. Det returnerer en række Klasse forekomster, der repræsenterer de mest specifikke typer (klasser eller grænseflader) af de serviceobjekter, der matcher skabelonen. Disse serviceobjekter er hverken lig med eller en superklasse af nogen af ​​de typer, der er angivet i skabelonen, og de har navne, der starter med det angivne præfiks. Tjenesteobjektet eller de objekter, som Klasse forekomster returneres er alle forekomster af alle typer (hvis nogen) der er sendt i skabelonen, men Klasse forekomster er alle mere specifikke end (og er underklasser eller undergrænseflader af) disse typer. Hver klasse vises kun en gang i det returnerede array og i vilkårlig rækkefølge.

Her er hvad getServiceTypes () ligner:

offentlig java.lang.Class [] getServiceTypes (ServiceTemplate tmpl, java.lang.String præfiks) kaster java.rmi.RemoteException; 

Det getEntryTypes () metoden tager en Service skabelon og returnerer en matrix af Klasse forekomster, der repræsenterer de mest specifikke indgangsklasser for de serviceelementer, der matcher skabelonen, som enten ikke matcher nogen indgangsskabelon eller er en underklasse af en. Hver klasse vises kun en gang i det returnerede array, igen i vilkårlig rækkefølge.

Her er hvad getEntryClasses () ligner:

offentlig java.lang.Class [] getEntryClasses (ServiceTemplate tmpl) kaster java.rmi.RemoteException; 

Det getFieldValues ​​() metoden tager en Service skabelon, et heltal indeks og a Snor feltnavn. Det returnerer en række Objekts for det navngivne felt af alle forekomster af posten, der vises i Service skabelon's Indgang[] array ved en hvilken som helst matchende serviceelements beståede indeks. Hvert objekt af en bestemt klasse og værdi vises kun én gang i det returnerede array og i vilkårlig rækkefølge.

Her er hvad getFieldValues ​​() ligner:

offentlig java.lang.Object [] getFieldValues ​​(ServiceTemplate tmpl, int setIndex, java.lang.String field) kaster java.lang.NoSuchFieldException, java.rmi.RemoteException; 

Opførelsen og formålet med disse browsermetoder kan være uklar. Du kan måske tænke på dem som værktøjer, der trinvis indsnævrer forespørgsler fra opslagstjenesten.

For eksempel kan en klient som en grafisk opslagstjenestebrowser først påberåbe sig getServiceTypes () med en tom skabelon. Det getServiceTemplate () metoden returnerer alle mulige servicetyper, der er registreret i opslagstjenesten, som browseren kunne vise. Brugeren kunne vælge en eller flere typer og derefter trykke på knappen Forespørgsel. Browseren vil tilføje denne type (eller typer) til serviceskabelonen og påberåbe sig getServiceTypes () igen. En mindre liste over typer returneres og vises af browseren. Brugeren kunne vælge en og trykke på knappen Indtastninger. Browseren danner en skabelon med den senest valgte servicetype eller -typer og påberåber sig derefter getEntryTypes (). Det getEntryTypes () metoden returnerer en række indgangsklasser, som browseren derefter kunne vise.

Brugeren kunne vælge nogle poster - og et felt i en valgt post - og trykke på en Fields-knap. Browseren ville oprette en skabelon ved hjælp af de aktuelt valgte service- og indtastningstyper. Derefter videregives indekset for den indgangsklasse, hvor brugeren valgte feltet og navnet på det valgte felt, til getFieldValues ​​(). Browseren viser alle de værdier, der getFieldValues ​​() vendt tilbage. Med disse værdier kunne brugeren yderligere indsnævre søgningen efter en tjeneste og til sidst vælge en bestemt tjeneste. Disse metoder hjælper således klienter, uanset om en menneskelig bruger er involveret eller ikke, til at gennemse de tjenester, der er registreret i en opslagstjeneste. Arrays, der returneres fra browsemetoderne, kan hjælpe klienten med at finjustere sine forespørgsler, hvilket i sidste ende resulterer i en Service skabelon det, når det sendes til kig op(), returnerer det mest passende serviceobjekt.

Notify () -metoden

Ud over opslags- og browsemetoderne er Service Registrering interface har også en underrette() metode, der underretter klienter, når nye tjenester registreres eller afregistreres med en opslagstjeneste:

offentlig EventRegistration-meddelelse (ServiceTemplate tmpl, int-overgange, RemoteEventListener-lytter, MarshalledObject-handback, long leaseDuration) kaster RemoteException; 

Du påberåber dig underrette() at registrere dig selv (eller en anden lytter) til at modtage en distribueret begivenhed, når de tjenester, der matcher bestået Service skabelon gennemgå en tilstandsændring beskrevet af parameteren overgange.

Overgangsparameteren er bitvis ELLER af ethvert ikke-frit sæt af disse tre værdier, defineret som konstanter i Service Registrering:

TRANSITION_MATCH_MATCH TRANSITION_MATCH_NOMATCH TRANSITION_NOMATCH_MATCH 

Du bygger Service skabelon til underrette() på samme måde som du bygger det til kig op(). Du kan angive eksplicitte typer, et service-id, attributter (som skal nøjagtigt matche) eller jokertegn (som matcher noget) i et af disse felter. Overgangene er baseret på en ændring (eller ikke-ændring) i status for det, der passer til din Service skabelon før og efter enhver handling udføres på opslagstjenesten.

For eksempel, TRANSITION_MATCH_MATCH angiver, at mindst en serviceartikel matchede din skabelon før og efter en operation. TRANSITION_MATCH_NOMATCH angiver, at selv om mindst et bestemt servicepost matchede din skabelon før en operation, matchede det ikke længere din skabelon efter operationen. For at modtage underretning, når nye tjenester føjes til en opslagstjeneste, skal du blot angive en skabelon, der matcher enhver tjeneste og pas TRANSITION_NOMATCH_MATCH som overgangen til underrette() metode.

SUBHEAD_BREAK: Opslagstjeneste versus navneservere

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