Преглед на JNDI, Част 1: Въведение в услугите за именуване

Тези от вас, които са били в библиотека и все още могат да си спомнят преживяването, могат да си припомнят процеса на намиране на библиотечна книга. Ако не сте в контакт с антикварната си страна, тази ситуация ще изглежда непозната; но от време на време се скитам в местна библиотека, за да потърся истинска офлайн книга. Библиотеките са пълни с хиляди неща - те са прашни и направени от дървесна маса и кравешки кожи, но са очарователни по свой начин. Във всеки случай, когато принудата за намиране на определена удари, избягвам наивния начин на ходене нагоре и надолу по пътеките на библиотеката и я обръщам към каталога с карти.

TEXTBOX: TEXTBOX_HEAD: Общ преглед на JNDI: Прочетете цялата поредица!

  • Част 1. Въведение в услугите за именуване
  • Част 2. Използвайте JNDI директорийни услуги, за да управлявате по-добре вашите разпределени приложения

  • Част 3. Използвайте JNDI, за да съхранявате обектите на вашето разпределено приложение

  • Част 4. Съберете заедно наученото с приложение с активиран JNDI: END_TEXTBOX

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

Колкото и изненадващо да изглежда, понятието за каталог с карти е доста удобно и в света на компютърните технологии. При изчисленията го наричаме услуга за именуване, която свързва имената с местоположението на услугите и с информация. Той осигурява компютърни програми с едно място, където те могат да намерят нужните им ресурси. Между другото, програмите не губят време, като изпълняват електронния еквивалент на ходене нагоре и надолу по пътеките и не изискват местоположенията да бъдат кодирани в тяхната логика.

Намирането на ресурси е от особено значение в широкомащабни корпоративни среди, където приложенията, които създавате, може да зависят от услугите, предоставяни от приложения, написани от други групи в други отдели. Добре проектираната инфраструктура за именуване прави такива проекти възможни - а липсата на такъв ги прави невъзможни. Всъщност, много усилия за реинженеринг на бизнес процеси започват с проектирането и внедряването на стабилна инфраструктура за именуване и директории в цялото предприятие.

Този месец представям Java Naming and Directory Interface (JNDI). JNDI предоставя интерфейс с общ знаменател за много съществуващи услуги за именуване. Като такъв JNDI не е проектиран да замести съществуващата технология; вместо това той предоставя общ интерфейс към съществуващите услуги за именуване. Нека започнем, като разгледаме някои от тези услуги.

Въведение в услугите за именуване

Фигурата по-долу изобразява организацията на обща услуга за именуване.

Услугата за именуване поддържа набор от обвързвания. Обвързването свързва имената с обектите. Всички обекти в система за именуване се именуват по един и същ начин (т.е. те се абонират за една и съща конвенция за именуване ). Клиентите използват услугата за именуване, за да намерят обекти по име.

Съществуват редица съществуващи услуги за именуване, някои от които ще опиша по-долу. Всеки от тях следва модела по-горе, но се различава в детайлите.

  • COS (Common Object Services) Именуване: Услугата за именуване за приложения на CORBA; позволява на приложенията да съхраняват и имат достъп до препратки към обекти на CORBA.

  • DNS (Domain Name System): Услугата за именуване в Интернет; картографира имена, удобни за хората (като www.etcee.com), в удобни за компютър IP (Internet Protocol) адреси в пунктирана четворна нотация (207.69.175.36). Интересното е, че DNS е разпределена услуга за именуване, което означава, че услугата и нейната база данни се разпространяват в много хостове в Интернет.

  • LDAP (Лек протокол за достъп до директории): Разработен от Университета в Мичиган; както подсказва името му, това е олекотена версия на DAP (Protocol Access Protocol), която от своя страна е част от X.500, стандарт за мрежови директорийни услуги. В момента над 40 компании подкрепят LDAP.

  • NIS (Network Information System) и NIS +: Услуги за именуване на мрежи, разработени от Sun Microsystems. И двете позволяват на потребителите достъп до файлове и приложения на всеки хост с един идентификатор и парола.

Общи черти

Както споменах по-рано, основната функция на именната система е да обвързва имена с обекти (или, в някои случаи, с препратки към обекти - повече за това в един момент). За да бъде услуга за именуване, услугата трябва най-малкото да предоставя способността да обвързва имена с обекти и да търси обекти по име.

Много системи за именуване не съхраняват обекти директно. Вместо това те съхраняват препратки към обекти. Като илюстрация помислете за DNS. Адресът 207.69.175.36 е препратка към местоположението на компютъра в Интернет, а не към самия компютър.

JNDI предоставя интерфейс, който поддържа цялата тази обща функционалност. Ще представя този интерфейс по-късно в тази статия.

Техните различия

Също така е важно да се разбере как се различават съществуващите услуги за именуване, тъй като JNDI трябва да осигури работеща абстракция, която заобикаля тези разлики.

Освен функционалните разлики, най-забележимата разлика е начинът, по който всяка услуга за именуване изисква да бъдат посочени имена - нейното споразумение за именуване. Няколко примера трябва да илюстрират проблема.

В DNS имената се изграждат от компоненти, които са разделени с точки ("."). Те четат отдясно наляво. Името "www.etcee.com" назовава машина, наречена "www" в домейна "etcee.com". По същия начин името „etcee.com“ назовава домейна „etcee“ в домейна от най-високо ниво „com“.

В LDAP ситуацията е малко по-сложна. Имената се изграждат от компоненти, които са разделени със запетаи (","). Подобно на DNS имената, те четат отдясно наляво. Компонентите в LDAP име обаче трябва да бъдат посочени като двойки име / стойност. Името "cn = Todd Sundsted, o = ComFrame, c = US" назовава лицето "cn = Todd Sundsted" в организацията "o = ComFrame, c = US." По същия начин името „o = ComFrame, c = US“ назовава организацията „o = ComFrame“ в държавата „c = US“.

Както илюстрират примерите по-горе, само конвенцията за именуване на услуга за именуване има потенциала да внесе значителна част от вкуса на основната услуга за именуване в JNDI. Това не е функция, която трябва да има независим от изпълнението интерфейс.

JNDI решава този проблем с Nameкласа и неговите подкласове и помощни класове. В Nameкласа представлява име, съставен от подредена последователности от subnames и предлага методи за работа с имена, независимо от основната услуга за именуване.

Поглед към именуването на JNDI

Както споменах по-горе, важно е да запомните, че JNDI е по- скоро интерфейс , отколкото изпълнение. Този факт има някои недостатъци - имате нужда от достъп до съществуваща услуга за именуване (като LDAP услуга) и трябва да разберете нещо за това как работи, за да играете с JNDI. От друга страна, това позволява на JNDI да се интегрира безпроблемно в съществуваща изчислителна среда, където утвърдената услуга за именуване има влияние.

JNDI naming revolves around a small set of classes and a handful of operations. Let's take a look at them.

Context and InitialContext

The Context interface plays a central role in JNDI. A context represents a set of bindings within a naming service that all share the same naming convention. A Context object provides the methods for binding names to objects and unbinding names from objects, for renaming objects, and for listing the bindings.

Some naming services also provide subcontext functionality. Much like a directory in a filesystem, a subcontext is a context within a context. This hierarchical structure permits better organization of information. For naming services that support subcontexts, the Context class also provides methods for creating and destroying subcontexts.

JNDI performs all naming operations relative to a context. To assist in finding a place to start, the JNDI specification defines an InitialContext class. This class is instantiated with properties that define the type of naming service in use and, for naming services that provide security, the ID and password to use when connecting.

For those of you familiar with the RMI Naming class, many of the methods provided by the Context interface outlined below will look familiar. Let's take a look at Context's methods:

  • void bind(String stringName, Object object): Binds a name to an object. The name must not be bound to another object. All intermediate contexts must already exist.

  • void rebind(String stringName, Object object): Binds a name to an object. All intermediate contexts must already exist.

  • Object lookup(String stringName): Returns the specified object.

  • void unbind(String stringName): Unbinds the specified object.

The Context interface also provides methods for renaming and listing bindings.

  • void rename(String stringOldName, String stringNewName): Changes the name to which an object is bound.
  • NamingEnumeration listBindings(String stringName): Returns an enumeration containing the names bound to the specified context, along with the objects and the class names of the objects bound to them.

  • NamingEnumeration list(String stringName): Returns an enumeration containing the names bound to the specified context, along with the class names of the objects bound to them.

Each of these methods has a sibling that takes a Name object instead of a String object. A Name object represents a generic name. The Name class allows a program to manipulate names without having to know as much about the specific naming service in use.

The example

The example below illustrates how to connect to a naming service, list all of the bindings, or list a specific binding. It uses the filesystem service provider, which is one of the reference JNDI service-provider implementations provided by Sun. The filesystem service provider makes the filesystem look like a naming service (which it is, in many ways -- filenames like /foo/bar/baz are names and are bound to objects like files and directories). I selected it because everyone has access to a filesystem (as opposed to, say, an LDAP server).

import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.Binding; import javax.naming.NamingEnumeration; import javax.naming.NamingException; import java.util.Hashtable; public class Main { public static void main(String [] rgstring) { try { // Create the initial context. The environment // information specifies the JNDI provider to use // and the initial URL to use (in our case, a // directory in URL form -- file:///...). Hashtable hashtableEnvironment = new Hashtable(); hashtableEnvironment.put( Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory" ); hashtableEnvironment.put( Context.PROVIDER_URL, rgstring[0] ); Context context = new InitialContext(hashtableEnvironment); // If you provide no other command line arguments, // list all of the names in the specified context and // the objects they are bound to. if (rgstring.length == 1) { NamingEnumeration namingenumeration = context.listBindings(""); while (namingenumeration.hasMore()) { Binding binding = (Binding)namingenumeration.next(); System.out.println( binding.getName() + " " + binding.getObject() ); } } // Otherwise, list the names and bindings for the // specified arguments. else { for (int i = 1; i < rgstring.length; i++) { Object object = context.lookup(rgstring[i]); System.out.println( rgstring[i] + " " + object ); } } context.close(); } catch (NamingException namingexception) { namingexception.printStackTrace(); } } } 

The program in the listing above first creates an initial context from the specified JNDI provider (in this case, Sun's filesystem provider) and a URL specifying a local directory. If no additional command-line arguments are specified, the program lists the objects and names of every entity in the specified directory. Otherwise, it lists the objects and names of only those items specified on the command line.

Conclusion

You should now have both an understanding of and an appreciation for naming services in general and JNDI in particular. In distributed environments, they are valuable tools for locating information and resources. JNDI makes it possible to work with a variety of naming services without having to master a multitude of APIs. Next month, we'll take a look at the other half of JNDI -- its directory functions.

Тод Съндстед пише програми, откакто компютрите стават достъпни в удобни настолни модели. Въпреки че първоначално се интересуваше от изграждането на разпределени приложения в C ++, Тод премина към езика за програмиране Java, когато той стана очевидният избор за такъв тип неща. В допълнение към писането, Тод работи и като архитект на Java със софтуера ComFrame.

Научете повече за тази тема

  • Изтеглете пълния изходен код за тази статия в zip формат

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

  • Всички неща JNDI

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

  • Документация за JNDI

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

  • Понастоящем на разположение са доставчиците на услуги

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

  • Пълен списък на предишни Java колони с инструкции

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

Тази история, „Общ преглед на JNDI, част 1: Въведение в услугите за именуване“, първоначално беше публикувана от JavaWorld.