Намерете услугите с услугата за търсене на Jini

Услугата за търсене на Jini, централният компонент на инфраструктурата за изпълнение на Jini, предлага на клиентите на Jini гъвкав и мощен начин за намиране на услуги на Jini. Той дава възможност на доставчиците на услуги да рекламират своите услуги и дава възможност на клиентите да намират и привличат помощта на тези услуги.

За да взаимодейства с услугата за търсене, клиентът първо трябва да получи обект на регистратор на услуга чрез откриване, протокол на мрежово ниво, използван от инфраструктурата за изпълнение на Jini. Discovery позволява на клиентите и услугите да намират услуги за търсене. (За повече информация относно откриването вижте Ресурси.) service registrarОбектът, който реализира net.jini.core.lookup.ServiceRegistrarинтерфейса, позволява на клиента да взаимодейства с услугата за търсене. За да намерят желаните услуги, клиентите изграждат ServiceTemplateекземпляр от клас net.jini.core.lookup.ServiceTemplateи го предават на един от двата lookup()метода, декларирани в ServiceRegistrarинтерфейса. Всеки lookup()метод изпраща шаблона на услугата до услугата за търсене, която изпълнява заявката и връща съответстващи обекти на услуги на клиента.

Като цяло клиентът търси услуга по тип Java, обикновено интерфейс. Например, ако клиентът трябва да използва принтер, той съставя шаблон за услуга, който включва Classобект за добре познат интерфейс към услугите на принтера. Всички услуги за принтери изпълняват интерфейса. Услугата за търсене връща обект на услуга (или обекти), които реализират този интерфейс. Можете да включите атрибути в шаблона за услуга, за да стесните броя на съвпаденията за такова търсене въз основа на тип. Клиентът използва услугата за принтер, като извиква върху обекта на услугата методите, декларирани в добре познатия интерфейс.

Класът ServiceTemplate

С ServiceTemplateкласа можете да изразите критериите за търсене на Jini справки. Класът се състои само от тези три публични полета:

public Entry [] attributeSetTemplates; public ServiceID serviceID; публичен клас [] serviceTypes;

ServiceTemplateняма методи и неговите екземпляри просто служат като "struct" подобни контейнери за заявки за търсене на услуги. Съвпаденията се извършват, както е описано в следния откъс от ServiceTemplatejavadoc страницата на:

Елементите в услугата за търсене се съчетават, като се използва екземпляр на [ ServiceTemplate]. Елемент от услуга ( item) съвпада с шаблон за услуга ( tmpl), ако:

  • item.serviceIDе равно tmpl.serviceID(или ако tmpl.serviceIDе null)
  • item.service [обектът на услугата] е екземпляр от всеки тип в tmpl.serviceTypes
  • item.attributeSets съдържа поне един съвпадащ запис за всеки шаблон за запис в tmpl.attributeSetTemplates

Запис съвпада с шаблон за запис, ако класът на шаблона е същият или суперклас на класа на записа и всяко ненулево поле в шаблона е равно на съответното поле на записа. Всеки запис може да се използва за съвпадение на повече от един шаблон. Имайте предвид, че в шаблон за услуга, за serviceTypesи attributeSetTemplates, нулевото поле е еквивалентно на празен масив; и двете представляват заместващ знак.

Както е описано тук, шаблонът за услуга може да включва препратка към масив от Classобекти. Тези обекти показват на услугата за търсене типа Java (или типовете) на обекта на услугата, който клиентът желае. Шаблонът за услуга може също да включва идентификатор на услуга, който уникално идентифицира услуга, и атрибути, които трябва точно да съответстват на атрибутите, качени от доставчика на услугата в елемента на услугата. Шаблонът за услуга може също да съдържа заместващи символи за всяко от тези полета. Уайлд кард в полето за идентификация на услугата, например, ще съответства на всеки идентификатор на услугата.

Методите за търсене ()

Методите ServiceRegistrar's lookup()приемат две претоварени форми. Двете форми се различават главно по броя на съвпаденията и елементите от услуги, които всеки от тях връща. Формата с два параметъра може да върне множество съвпадения на заявката, изразена в ServiceTemplate, докато формата с един параметър връща само едно съвпадение. В допълнение, двупараметричният формуляр връща цели услуги; формулярът с един параметър връща само обекта на услугата.

Двупараметричната форма на търсене ()

Ето извадка от javadoc, която обяснява двупараметричната форма на lookup():

публично търсене на ServiceMatches (ServiceTemplate tmpl, int maxMatches) хвърля java.rmi.RemoteException; 

[Той] връща най-много maxMatchesелементи, съответстващи на шаблона, плюс общия брой елементи, които съответстват на шаблона. Връщаната стойност никога не е nullи масивът с върнати елементи е само nullако maxMatchesе нула. За всеки върнат елемент, ако обектът на услугата не може да бъде десериализиран, полето за услуга на елемента е зададено nullи не се извежда изключение. По същия начин, ако набор от атрибути не може да бъде десериализиран, този елемент от attributeSetsмасива е зададен nullи не се изхвърля изключение.

Ето ServiceMatchesкласа:

пакет net.jini.core.lookup;

публичен клас ServiceMatches разширява java.lang.Object реализира java.io.Serializable {

публични ServiceItem [] елементи; публични int totalMatches; }

И тук е ServiceItemкласът:

пакет net.jini.core.lookup;

публичен клас ServiceMatches разширява java.lang.Object реализира java.io.Serializable {

public Entry [] attributeSets; обществена услуга java.lang.Object; public ServiceID serviceID; }

Както бе споменато по-рано, всеки елемент от itemsмасива, върнат от формуляра с два параметъра, е пълен елемент на услугата, който включва обекта на услугата, идентификатора на услугата и всички набори от атрибути. В maxMatchesобластта помага на клиентите да управляват броя на обектите, върнати от това lookup().

Дължината на itemsмасива във върнатия ServiceMatchesобект е по-малка или равна на стойността, предадена на lookup()in maxMatches. Общият брой на съответстващите сервизни елементи (върнати в totalMatches) е по-голям или равен на дължината на itemsмасива.

Например, ако maxMatchesе 50 и шаблонът на услугата съвпада с 25 елемента, дължината на върнатия itemsмасив и стойността на totalMatchesса и двете 25. Като алтернатива, ако maxMatchesе 50, но шаблонът на услугата съответства на 100 елемента, дължината на върнатия itemsмасив е 50 и стойността на totalMatchesе 100. Когато шаблон на услуга съвпада с повече от maxMatchesелементи на услугата, елементите на услугата, върнати от двупараметричния, lookup()се избират произволно от пълния набор от съответстващи елементи на услугата.

Еднопараметричната форма на търсене ()

Методът с един параметър lookup()връща един съвпадащ обект на услуга, избран произволно от всички съвпадения. Ето извадка от javadoc, обясняваща тази форма:

публично търсене на обекти (ServiceTemplate tmpl) хвърля java.rmi.RemoteException; 
Връща обекта на услугата (т.е. само ServiceItem.service) от елемент, съответстващ на шаблона, или nullако няма съвпадение. Ако няколко елемента съвпадат с шаблона, той е произволен по отношение на това кой сервизен обект се връща. Ако върнатият обект не може да бъде десериализиран, UnmarshalExceptionсе изхвърля със стандартната RMI семантика.

Тъй като един параметър lookup()връща само един съвпадащ обект на услуга, клиентите могат да минимизират броя на изтеглените файлове на състоянието на обекта и клас. Но тъй като върнатият обект на услуга е избран произволно и не е идентифициран с идентификатор на услуга или описан от асоциирани набори от атрибути, клиентът трябва да е уверен, че всеки съвпадащ обект на услуга ще бъде достатъчен.

Методите на сърфиране

In addition to the two lookup() methods, the ServiceRegistrar has three browsing methods, which yield information about registered service items. The three methods -- getServiceTypes(), getEntryClasses(), and getFieldValues() -- are called browsing methods because they enable clients to browse the services and attributes in the lookup service.

The getServiceTypes() method takes a ServiceTemplate (the same ServiceTemplate that is passed to the lookup() methods) and a String prefix. It returns an array of Class instances representing the most specific types (classes or interfaces) of the service objects that match the template. These service objects are neither equal to, nor a superclass of, any of the types specified in the template, and they have names that start with the specified prefix. The service object or objects for which Class instances are returned are all instances of all the types (if any) passed in the template, but the Class instances are all more specific than (and are subclasses or subinterfaces of) those types. Each class appears only once in the returned array, and in arbitrary order.

Here's what getServiceTypes() looks like:

public java.lang.Class[] getServiceTypes(ServiceTemplate tmpl, java.lang.String prefix) throws java.rmi.RemoteException; 

The getEntryTypes() method takes a ServiceTemplate and returns an array of Class instances that represent the most specific classes of entries for the service items that match the template, which either don't match any entry template or are a subclass of one. Each class appears only once in the returned array, again in arbitrary order.

Here's what getEntryClasses() looks like:

public java.lang.Class[] getEntryClasses(ServiceTemplate tmpl) throws java.rmi.RemoteException; 

The getFieldValues() method takes a ServiceTemplate, an integer index, and a String field name. It returns an array of Objects for the named field of all instances of the entry that appears in the ServiceTemplate's Entry[] array at any matching service item's passed index. Each object of a particular class and value appears only once in the returned array, and in arbitrary order.

Here's what getFieldValues() looks like:

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

The behavior and purpose of these browsing methods can be obscure. You might think of them as tools that incrementally narrow queries of the lookup service.

For example, a client such as a graphical lookup service browser could first invoke getServiceTypes() with an empty template. The getServiceTemplate() method returns all possible service types registered in the lookup service, which the browser could display. The user could select one or more types, then push the Requery button. The browser would add that type (or types) to the service template and invoke getServiceTypes() again. A smaller list of types would be returned and displayed by the browser. The user could select one and press an Entries button. The browser would form a template with the most recently selected service type or types, and then invoke getEntryTypes(). The getEntryTypes() method would return an array of entry classes, which the browser could then display.

The user could select some entries -- and a field of a selected entry -- and push a Fields button. The browser would build a template using the currently selected service and entry types. It would then pass the index of the entry class in which the user selected the field, and the name of the selected field, to getFieldValues(). The browser would display all the values that getFieldValues() returned. With those values the user could further narrow the search for a service, eventually choosing a particular service. Thus, these methods help clients, whether or not a human user is involved, to browse the services registered in a lookup service. The arrays returned from the browsing methods can help the client further refine its queries, ultimately resulting in a ServiceTemplate that, when passed to lookup(), returns the most appropriate service object.

The notify() method

In addition to the lookup and browsing methods, the ServiceRegistrar interface also has a notify() method that notifies clients when new services register or unregister with a lookup service:

public EventRegistration notify(ServiceTemplate tmpl, int transitions, RemoteEventListener listener, MarshalledObject handback, long leaseDuration) throws RemoteException; 

You invoke notify() to register yourself (or another listener) to receive a distributed event whenever the services that match the passed ServiceTemplate undergo a state change described by the transitions parameter.

The transitions parameter is a bitwise OR of any nonempty set of these three values, defined as constants in ServiceRegistrar:

TRANSITION_MATCH_MATCH TRANSITION_MATCH_NOMATCH TRANSITION_NOMATCH_MATCH 

You build the ServiceTemplate for notify() in the same way you build it for lookup(). You can indicate explicit types, a service ID, attributes (which must exactly match), or wild cards (which match anything) in any of those fields. The transitions are based on a change (or nonchange) in the status of whatever matches your ServiceTemplate before and after any operation is performed on the lookup service.

Например TRANSITION_MATCH_MATCHпосочва, че поне един елемент от услугата съответства на вашия шаблон преди и след операция. TRANSITION_MATCH_NOMATCHпоказва, че макар поне един конкретен елемент от услугата да съвпада с вашия шаблон преди операция, той вече не съвпада с вашия шаблон след операцията. За да получите известие, когато към услуга за търсене се добавят нови услуги, просто посочвате шаблон, който съответства на която и да е услуга и преминавате TRANSITION_NOMATCH_MATCHкато преход към notify()метода.

SUBHEAD_BREAK: Услуга за търсене спрямо сървъри за имена