Хранение объектов Java в Apache Directory Server, Часть 1

В рамках проекта Apache Directory Server

В этом разделе, состоящем из двух частей, будут рассмотрены все этапы хранения Java™-объектов в Apache Directory Server (Сервере Каталогов) (ApacheDS). В первой части Билал Сиддикви ознакомит вас с ApacheDS и сделает общий обзор его корневой структуры. Поскольку вы главным образом используете ApacheDS как LDAP сервер для хранения Java-объектов, Билал представляет краткий обзор понятий и терминологии LDAP. Он также покажет вам, как использовать JXplorer для обзора компонентов схемы LDAP, таких как типы, атрибута и классы объекта, и как вводить объект данных в ApacheDS. Раздел завершается обзором сериализации объектов Java и технологии Remote Method Invocation и их применения для хранения объектов Java в ApacheDS, в качестве подготовки к их более практическому рассмотрению в Части 2.

Билал Сиддикви, внештатный консультант, WaxSys

Билал Сиддикви (Bilal Siddiqui) является инженером-электронщиком, консультантом по XML и соучредителем WaxSys, компании, чья деятельность направлена на упрощение электронного бизнеса. После окончания в 1995 г. Инженерно-технологического Университета, г. Лахор, и получения степени по электронной технике, он начал разрабатывать программные продукты для промышленных систем управления. В дальнейшем он занимался XML и использовал свой опыт в программировании C++ для разработки Web- и Wap-базируемых инструментов для XML-технологий, серверных парсинговых программных продуктов и служебных приложений. Билал – проповедник передовых технологий и часто публикуется в этой области.



28.12.2006

Apache Directory Server является проектом открытого кода на основе языка Java многочисленных Internet-протоколов. Стержнем ApacheDS является служба каталога, которая может хранить данные приложений и выполнять операции поиска для разных типов данных. Реализации протокола работают поверх службы каталога для обеспечения Internet-сервисов, относящихся к хранению данных, их поиску и извлечению.

Вероятно, самой важной характеристикой ApacheDS является возможность применять различные протоколы в его службе каталога. Это означает, что вы можете хранить ваши прикладные данные (включая динамические объекты Java) в ApacheDS, и различные клиенты могут пользоваться вашими данными, используя различные протоколы. Наиболее важным протоколом реализуемым посредством ApacheDS является Lightweight Directory Access Protocol (Облегченный Протокол Доступа к Сетевому Каталогу) (LDAP). ApacheDS выступает в качестве LDAP-сервера, ожидает запросы и координируется с внутренним стержнем службы каталога для ответа на запросы LDAP.

В этом разделе, состоящем из двух частей, я представлю вам стержень структуры ApacheDS и рассмотрю все шаги по сохранению ваших динамических объектов Java в ApacheDS. Поскольку я сосредоточусь в основном на ApacheDS как LDAP реализации сервера, большая часть первой половины этого раздела отводится на ознакомление с функциональными возможностями LDAP и терминологией. Прежде, чем начать, я представлю вам модульную расширяемую структуру ApacheDS и объясню, как вы можете использовать ее для интеграции в реализации новых протоколов и Internet-сервисов для ApacheDS. Понимание функционирования стержня ApacheDS поможет вам в дальнейшем осознать предоставленные функциональные возможности LDAP.

Вам необходимо Скачать и инсталлировать ApacheDS и JXplorer для того, чтобы продолжить рассмотрение данного раздела. Вы можете загрузить полный исходный код для данного раздела в любое время.

Служба Каталогов в ApacheDS

Служба каталогов является приложением, которое хранит и систематизирует данные. Служба каталогов обрабатывает данные, которые не требуют частого обновления, такие как личные данные пользователей системы (например, имя, адрес и номера телефонов) или технологические возможности производственных мощностей (например, количество, типы и производственную мощность установленного оборудования). Далее в этом разделе я приведу пример, который включает оба типа данных. Сейчас я сконцентрируюсь на том, как ApacheDS обеспечивает работу службы каталогов.

ApacheDS выполняет JNDI

На Рисунке 1 вы можете увидеть, как ApacheDS выполняет надстройку назначения имен и аранжировки каталога (Java Naming and Directory Interface - JNDI) для своей стержневой службы каталогов. JNDI является интерфейсом Java, который определяет методы для выполнения таких действий каталога как хранение данных в каталоге и поиск сохраненных данных. JNDI является частью как Java 2 Enterprise Edition (J2EE), так и Java 2 Standard Edition (J2SE). Тогда как J2SE включает только клиентскую поддержку JNDI, J2EE контейнеры обычно включают серверные реализации JNDI. A J2EE-контейнер может использовать службу каталогов ApacheDS через надстройку JNDI, как показано на Рисунке 1:

Рисунок 1. ApacheDS внутри контейнера J2EE
ApacheDS внутри контейнера J2EE

Набор интерфейсов в JNDI обеспечивает абстрактный образ службы каталогов. Реализация JNDI обеспечивает логику непосредственно для сообщения со службой каталога (например, Java-платформа включает в себя реализацию JNDI для LDAP). Вы можете использовать JNDI для сообщения с любым типом службы каталога, если у вас имеется JNDI реализация именно для этого типа. Если вы хотите использовать JNDI в клиентском приложении на основе Java, вам нужна клиентская реализация JNDI. A клиентская реализация JNDI обеспечивает классы, которые реализуют интерфейсы JNDI по запросам автора к действиям каталога.

ApacheDS реализует серверную JNDI. Это значит, что он включает классы, которые реализуют JNDI интерфейсы для ответа по запросам к действиям каталога. Как я отметил (и показал на Рисунке 1), контейнер J2EE может использовать службу каталога ApacheDS через его JNDI-надстройку.


Встраиваемая поддержка протокола

Рисунок 1 показывает только одну модель использования для ApacheDS. ApacheDS предназначался для использования только в качестве службы каталога, внедренного в J2EE контейнер. Вы можете использовать ApacheDS для реализации любого протокола, который требует внутренней службы протокола. Вы даже можете использовать его для обслуживания различных типов протоколов одновременно; например, текущая ApacheDS реализация обеспечивает выполнение как LDAP, так и Kerberos. Более того, список протоколов, поддерживаемых в ApacheDS постоянно растет.

ApacheDS имеет подвижную, расширяемую структуру, которая делает возможным реализацию новых протоколов. На Рисунке 2 вы можете увидеть модель ApacheDS структуры, которая работает поверх надстройки JNDI, показанной на Рисунке 1:

Рисунок 2. Гибкость и расширяемость структуры ApacheDS
Гибкость и расширяемость структуры ApacheDS

Как видно из рисунка, ApacheDS использует набор интерфейсов, называемых Multipurpose Interfaces for Networked Applications (Многоцелевые Интерфейсы для Сетевых Приложений - MINA). MINA поддерживает реализацию нового протокола для внедрения в ApacheDS. Я объясню, как функционирует MINA, прежде, чем продолжить обзор.

Как функционирует MINA

Интерфейсы в MINA содержат методы генерирования специфического протокола производственных объектов. Данные заводские объекты обеспечивают средства внедрения новой реализации протокола в ApacheDS. Реализации протокола обеспечивают выполнение MINA интерфейсов, а ApacheDS инфраструктура основывается на методах включенных в MINA для сообщения с реализациями протокола.

Например, в MINA существует интерфейс ProtocolProvider, который использует метод getCodecFactory(). Этот метод ProtocolProvider.getCodecFactory() отсылает объект, экспонирующий другой интерфейс MINA, а именно ProtocolCodecFactory.

Реализации протокола в ApacheDS обеспечивают выполнение интерфейса ProtocolProvider. Например, реализация LDAP в ApacheDS имеет класс LDAPProtocolProvider, который обеспечивает выполнение интерфейса ProtocolProvider.

Метод getCodecFactory() в LDAPProtocolProvider выдает объект, который экспонирует интерфейс ProtocolCodecFactory. Это ProtocolCodecFactory, который является заводским объектом и который инфраструктура ApacheDS использует для кодирования и декодирования объектов для LDAP.

ProtocolCodecFactory включает методы newEncoder() и newDecoder(), которые выдают объекты, экспонирующие MINA интерфейсы ProtocolEncoder и ProtocolDecoder. Кодирующий объект специфического протокола экспонирует интерфейс ProtocolEncoder, а декодирующий объект экспонирует интерфейс ProtocolDecoder.

Кодирование и декодирование в MINA

Как вы уже догадались, инфраструктура ApacheDS использует экземпляр класса ProtocolDecoder конкретного протокола для декодирования запроса протокола таким образом, чтобы можно было распознать его прежде, чем начать обработку запроса. После декодирования ApacheDS обрабатывает запрос. Например, если запросом был поиск LDAP, ApacheDS будет осуществлять поиск запрошенных данных во внутренней службе каталога и сортировку результатов поиска.

После нахождения требуемых результатов поиска, инфраструктура ApacheDS использует объект конкретного протокола ProtocolEncoder для кодирования результатов поиска. В случае поиска LDAP ApacheDS будет использовать ProtocolEncoder LDAP объект для кодирования результатов поиска прежде, чем отправить ответ автору запроса.

Инфраструктура служб MINA

MINA также имеет классы для обработки служб. Любая системная служба может зарегистрироваться в сервисе реестра, а система доступа протокола будет зарегистрирована вместе с классами системы доступа, которая обеспечивает сервис. Затем система доступа протокола преобразовывает запросы протокола в действия JNDI. Простым примером является LDAP запрос поиска, преобразованный в действия поиска JNDI. Как только инфраструктура ApacheDS распознает, какое действие JNDI необходимо запустить во время обработки запроса протокола, то она может генерировать событие.

Инфраструктура обработки события в MINA посылает событие к соответствующему обработчику. Например, если запрос требует запуска поискового действия JNDI, запускается обработчик поиска. MINA также поддерживает накопитель порождаемых процессов. Если обработчик занят выполнением предыдущей операции, событие временно хранится в накопителе порождаемых процессов до тех пор, пока оно не будет обработано.

Вы можете увидеть системы доступа протокола, интерфейсы и классы MINA, и обработчики действий, работающих с JNDI на Рисунке 2.

Вероятно, главным преимуществом ApacheDS инфраструктуры является использование общей службы каталога (JNDI) для различных систем доступа к протоколам. Это означает, что вы можете использовать ApacheDS для экспонирования ваших данных клиентам, используя различные протоколы. Поскольку одним из наиболее важных протоколов, поддерживаемых ApacheDS, является LDAP (и поскольку вы будете использовать ApacheDS прежде всего как LDAP-сервер для хранения объектов Java), я рассмотрю LDAP более детально. См. Resources (Ресурсы) для получения большей информации об ApacheDS инфраструктуре.


Обзор LDAP

LDAP-протокол распознает команды запроса и ответа для действий каталога. Действия каталога подразумевают хранение новых данных в каталоге, поиск и извлечение хранящихся данных, удаление ненужных данных, обновление устаревших данных и тому подобные действия. (См. Resources для RFC 2251, официальное описание LDAP, которая содержит команды запроса и ответа для хранения, извлечения, обновления и удаления данных в каталоге LDAP.)

Команда LDAP, которую вы используете для хранения новых данных (например, вашего действующего Java-объекта) в ApacheDS, называется bind (связать). Она передает данные пользователя в службу каталога LDAP, например ApacheDS, и хранит (или накапливает) данные в каталоге.

Для LDAP не имееет значения фактическое месторасположение хранилища данных. Вместо этого LDAP указывает Distinguished Name (Уникальное Имя - DN) для каждой учетной записи, хранящейся в ApacheDS. Каждое DN должно быть однозначно определяемым внутри службы каталога. Существование двух учетных записей с одинаковым DN невозможно. Вы узнаете о механизме LDAP, используемом для обеспечения единичности каждого DN, далее из раздела.

Кроме того, поисковый механизм LDAP использует имена DN. В следующем пункте представлен пример сценария приложения, который ознакомит вас с терминологией LDAP и представит механизм поиска LDAP. Я буду использовать пример приложения на протяжении обеих частей данного раздела.

Учебное Приложение

В качестве примера данного сценария приложения, предположим, что вы проектируете систему управления данными для производственной компании. В компании и вокруг нее имеются сотрудники, заказчики, партнеры и поставщики, и все они пользуются системой управления данными, которая обязательно хранит данные о пользователях в ApacheDS.

Система позволяет всем пользователям устанавливать свои собственные параметры при пользовании системой. Например, пользователи могут настраивать данные таким образом, чтобы они отображали их личный элемент по умолчанию при пользовании системой и применять различные варианты подачи и оформления для различных единиц данных. Система также допускает специальные параметры предпочтений в зависимости от type (типа) пользователя. Например, сотрудники компании (внутренние штатные пользователи) могут устанавливать параметры команд, заказчики могут устанавливать отгрузочные параметры, а поставщики могут устанавливать параметры выставления счетов.

Самым простым способом установки индивидуальных параметров пользователя в ApacheDS являются параметры хранения в форме Java-объектов. Для данного сценария приложения вы можете начать с создания класса Preferences (индивидуальные настройки) для всех типов пользователей. Класс Preferences Содержит методы, которые позволяют пользователям устанавливать параметры, общие для всех типов пользователей (внутренние пользователи, заказчики, и поставщики, в данном случае). Например, класс Preferences может содержать метод setStyles(), определяющий местонахождение таблицы стилей. Таблица стилей будет использоваться для применения стилевого оформления к различным единицам данных.

Вы также можете расширить класс Preferences для формирования класса MessagingPreferences (Параметры команд), который будет включать параметры команд для внутренних пользователей. Подобным образом вы можете создать класс ShippingPreferences (Отгрузочные Параметры) для заказчиков и класс InvoicingPreferences (Параметры выставления счетов) для поставщиков.

Листинг 1 является схематическим изображением классов Preferences, MessagingPreferences, ShippingPreferences, и InvoicingPreferences. Для простоты я не включил в Листинг 1 никаких других методов (за исключением метода setStyles()). Сейчас я только хочу продемонстрировать хранение представителей класса в ApacheDS.

Листинг 1. Java-классы, представляющие различные типы пользовательских предпочтений
    public class Preferences implements java.io.Serializable {
        String styleSheetURL = null;
 
        public void setStyles(String styleSheetURL){
            this.styleSheetURL = styleSheetURL;
        }
        //Other methods of the Preferences class

    }

    public class MessagingPreferences extends Preferences {
        //Methods of the MessagingPreferences class
    }

    public class ShippingPreferences extends Preferences {
        //Methods of the ShippingPreferences class
    }

    public class InvoicingPreferences extends Preferences {
        //Methods of the InvoicingPreferences class
    }

Управление данными с помощью ApacheDS

Предположим, Элис работает в коммерческом отделе производственной компании. Она использует вашу систему управления данными для хранения всех своих данных (имя, отдел, электронный адрес, номер телефона, и т.д.) также, как и своих параметров (в форме MessagingPreferences объекта) в ApacheDS. Все ее данные хранятся в ApacheDS под единичным DN.

Примечание к терминологии

Вы также можете подумать, что DN это named context (именованный контекст) в службе каталога. Учетная единица данных любого пользователя, как и Эллис, записывается в именованный контекст, определяемый ее DN. Фактически, вы вскоре увидите, что термины DN и named context являются взаимозаменяемыми. В документации JNDI обычно пользуются терминами named (или naming) contexts, а в LDAP документации используют термин DN. Если вы работаете как с LDAP, так и с JNDI, вы можете заметить, что данные термины имеют одинаковое значение.

Теперь предположим, что Элис хочет изменить свои параметры команды, используя вашу систему управления данными. Сначала система управления данными использует LDAP для поиска именнованного контекста Alice и обнаружения его DN. После того, как DN найден, она извлекает для Alice объект MessagingPreferences из DN, обновляет объект последними данными Alice и снова сохраняет объект в ApacheDS.

Теперь, когда у вас есть сценарий приложения, давайте рассмотрим, как вы можете использовать ApacheDS для того, чтобы это серверная магия заработала.

Начало работы с ApacheDS

Вам необходимо изучить схемы LDAP, чтобы понять как хранить разные виды данных (включая объекты Java) в ApacheDS. Более того, будет полезным просмотреть хранящиеся в LDAP-сервере данные в графическом представлении, где вы сможете увидеть их в древовидной форме. Для этого, я покажу вам, как использовать JXplorer, реализацию LDAP с открытым кодом на основе Java, которая обеспечивает иерархическое представление о хранящихся на LDAP сервере данных. Поскольку я использую JXplorer для вашего ознакомления с LDAP схемами, вам необходимо скачать и установить JXplorer прежде, чем мы продолжим.

Если вы уже сделали это, вам также теперь необходимо скачать ApacheDS. Установка довольно проста: вы получите упакованный файл, который можете распаковать для извлечения JAR-файлов ApacheDS. Запустите LDAP-сервер в ApacheDS запуском apacheds-main-0.9.jar с командной строки следующим образом:

<JAVA_HOME>/java -jar apacheds-main-0.9.jar

LDAP-сервер в ApacheDS находится в активном режиме ожидания (по умолчанию) на localhost:389, готовый к обслуживанию LDAP-запросов от клиентских приложений.

Подсоединение к ApacheDS

После начала работы ApacheDS запустите JXplorer для получения иерархического представления, показанного на Рисунке 3. Как видите, JXplorer не подсоединен ни к какому LDAP серверу.

Рисунок 3. Первоначальный вид при запуске JXplorer
Первоначальный вид при запуске JXplorer

Далее, вам необходимо подсоединиться к ApacheDS. Для этого вы используете команду Connect (Подсоединить) в меню JXplorer File (Файл). В диалоговом окне соединения ("Open LDAP/DSML Connection"), введите значения, показанные на Рисунке 4:

Рисунок 4. Диалоговое окно соединения
Диалоговое окно соединения

Обратите внимание на Рисунке 4, что поля хоста и порта задают адрес, где находится ваш ApacheDS. Вам также необходимо имя пользователя и пароль для подсоединения к ApacheDS. ApacheDS поступает с заданным по умолчанию именем администратора (uid=admin, ou=system) и логин с паролем ("secret"), которые вы можете использовать для подсоединения к ApacheDS. Обратите внимание, что я ввел имя пользователя по умолчанию в User DN поле и пароль по умолчанию в Password поле.

После того, как вы ввели величины в диалоговое окно соединения, выберите OK. JXplorer отправит запрос подсоединения к ApacheDS, и через мгновение вы увидите на экране изображение, показанное на Рисунке 5. Теперь вы подсоединены к ApacheDS.

Рисунок 5. Первое изображение JXplorer на экране после подсоединения к ApacheDS
Первое изображение JXplorer на экране после подсоединения к ApacheDS

Данные по умолчанию в ApacheDS

Экран на Рисунке 5 поделен на две части, почти так же как экран Windows Explorer. С левой стороны находится разветвленное древо каталогов, а с правой стороны отображены элементы того, что вы можете выбрать из этого изображения.

С левой стороны имеются три ярлыка, отмеченных как Explore (Изучить), Results (Результаты), и Schema (Схема). Ярлык Explore помогает вам изучить данные, находящиеся в ApacheDS. Вы используете ярлык Explore для обзора учетных записей в ApacheDS. Ярлык Results показывает результаты поиска, и ярлык Schema предоставляет элементы схем, поддерживаемых ApacheDS. При дальнейшем рассмотрении в основном я буду использовать ярлыки Explore и Schema.

Обратите внимание, что на Рисунке 5 показан выбор ярлыка Explore, который предоставляет детали о данных, содержащихся в ApacheDS. Поскольку я еще не сохранил никаких данных в ApacheDS, то все, что вы можете сейчас видеть, -- данные по умолчанию. Например, если вы щелкнете на запись admin на Рисунке 5, вы получите изображение на экране, показанное на Рисунке 6, которое отображает административную запись по умолчанию, поступающую при загрузке ApacheDS:

Рисунок 6. Элементы записи admin
Элементы записи admin

Запись admin отображает администратора ApacheDS, чье имя пользователя и пароль были введены на Рисунке 4. Правая часть Рисунка 5 отображает HTML-вид записи admin, в которой содержится несколько полей, таких как User Password поле. Вы можете изменить пароль администратора, задав новый пароль в поле password и щелкнув кнопку Submit (Согласиться).

Примечание по типам атрибута

Каждая запись с правой стороны Рисунка 6 на самом деле является атрибутом LDAP. Многие типы атрибута предназначены для LDAP. Тип атрибута придается коду attributeType, в терминологии LDAP.

Атрибуты предназначены для хранения значений данных (так же как поле Common Name содержит имя ApacheDS администратора в качестве значения). Вы должны определить множество аспектов данных, которые вы хотите хранить в качестве значений атрибута. Например, вам нужно задать кодирование данных (будет ли атрибут содержать текстовые или несформированные двоичные данные).

Другим важным аспектом использования данных является возможность их поиска. Например, вам захочется найти все данные пользователя, чье имя или электронный адрес вы знаете, следовательно, вам нужно установить правила согласования, которые будут применяться во время операции поиска. В случае с электронным адресом вы можете выполнять поиск без учета регистра.

JXplorer может показать вам типы атрибута, использующиеся для определения административных записей по умолчанию. Щелкните ярлык Table Editor (Редактор Таблицы) с правой стороны экрана, показанного на Рисунке 6; у вас отображен вид Table Editor, как показано на Рисунке 7:

Рисунок 7. Вид записи admin в редакторе таблицы Table Editor
Вид записи admin в редакторе таблицы Table Editor

Таблица на Рисунке 7 содержит "attribute type" (тип атрибута) колонку и "value" (значение) колонку. Вы можете отобразить несколько типов атрибута, показанных в полях на Рисунке 6. Например, cn и sn типы атрибутов на Рисунке 7 соотносятся с полями Common Name и Surname на Рисунке 6, соответственно.

Это означает, что атрибуты записей данных имеют соответствующие типы атрибута. ApacheDS поддерживает десятки типов атрибута, предназначенных для широкого круга задач и установленных в различных Internet стандартах. В этом разделе описывается подгруппа типов атрибута, поддерживаемая ApachDS, а именно те, которые используются для хранения Java-объектов. В особенности часто я буду использовать универсальный тип атрибута cn, используемый для установки общего имени любой записи. Вы можете использовать тип атрибута cn для обозначения имени менеджера, работающего в коммерческом отделе предприятия и вы также можете использовать его для наименования объекта Java. Как можно догадаться, тип атрибута sn не является универсальным: он только используется для указания фамилии человека.


Классы объекта в ApacheDS

Теперь, когда вы имеете некоторое представление о типах атрибута, давайте рассмотрим тип атрибута objectClass, имеющий четыре величины на Рисунке 7: inetOrgPerson, organizationalPerson, person, и top. Это значит, что запись admin состоит из четырех object classes (классов объекта).

Фактически, все учетные записи данных в ApacheDS используют классы объекта. Класс объекта является совокупностью типов атрибута. Если запись данных (как запись admin на Рисунке 6 или Рисунке 7) ассоциируется с классом объекта, запись содержит все типы атрибута в классе объекта.

Вы сами можете увидеть типы атрибута, содержащиеся в четырех классах объекта, используемых admin записью. Щелкните ярлык Schema с левой стороны Рисунка 7 для получения изображения на экране, показанного на Рисунке 8. Ярлык Schema отображает информацию о типах атрибута, классах объекта и форматах данных, которые ApacheDS поддерживает.

Рисунок 8. Ярлык Schema
Ярлык Schema

Теперь раскройте запись objectClasses с левой стороны экрана, показанного на Рисунке 8. Запись разворачивается в длинный, выстроенный в алфавитном порядке список типов объекта, поддерживаемых ApacheDS. Найдите класс объекта person в списке и щелкните. Вы видите изображение на экране, показанное на Рисунке 9:

Рисунок 9. Класс объекта person
Класс объекта person

Установка класса объекта

На Рисунке 9, вы можете видеть элементы класса объекта person в виде различных полей. Следующие поля задают класс объекта:

Таблица 1. Поля, задающие класс объекта
DESCОбеспечивает текстовое описание класса объекта person. Класс объекта person задается в RFC 2256 (см. Resources), где описываются многие классы объекта и типы атрибута, используемые клиентами или пользователями LDAP службы каталога. Например, любой человек может быть пользователем LDAP службы и, следовательно, класс объектаperson определяет атрибуты, присущие любому человеку (такие как полное имя человека).
MAYЗадает список выборочных типов атрибута, включенных в класс объекта person. Например, класс объекта person может содержать типы атрибута userPassword и telephoneNumber, которые используются для хранения пароля и телефонного номера субъекта. Далее в разделе я покажу вам, как установить элементы типа атрибута.
MUSTУказывает обязательные типы атрибута для класса объекта person. Класс объекта person содержит всего два обязательных атрибута: sn и cn, о которых уже рассказывалось выше.
NAMEУказывает имя класса объекта.
OIDУказывает идентификатор объекта для класса объекта. Каждый класс объекта LDAP и тип атрибута должны иметь единичный идентификатор объекта. RFC 2256 указывает идентификатор объекта для класса объекта person. Для обеспечения уникальности идентификатора объекта Internet Assigned Numbers Authority (см. Resources) бесплатно формирует идентификаторы объекта. Вам не нужно выбирать никаких идентификаторов объекта в данном разделе, поскольку мы не задаем никаких новых типов атрибута.
SUPУказывает родительский элемент класса объекта. Понятие наследственности (проявляющееся в передаче способностей родителя к ребенку) для классов объекта сходно с наследственностью в объектно-ориентированных языках программирования. Обратите внимание на значение атрибута SUP на Рисунке 9, где класс объекта person переходит в класс, именуемый top, который является суперклассом для всех классов объекта. Это значит, что все классы объекта в LDAP прямо или косвенно переходят в класс объекта top.

Теперь взгляните на top (верхний) класс объекта, показанный на Рисунке 10, который содержит только один тип атрибута, именуемый objectClass. Как и все классы объекта восходят к верхнему классу, так и тип атрибута objectClass всегда присутствует во всех записях данных, независимо от того, какой класс объекта используется в записях данных. Проще говоря, это означает, что все записи данных должны определять класс объекта, который они используют.

Рисунок 10. Верхний класс объекта
Верхний класс объекта

Типы классов объекта

Существуют три типа классов объекта: абстрактный, структурный, и вспомогательный. Зная это, вы можете заметить, что класс объекта top является абстрактным, это означает, что он существует только для того, чтобы другие классы объекта могли из него расшириться. Ни одна запись данных не использует абстрактный класс напрямую.

С другой стороны, класс объекта person является структурным. Все записи данных используют структурные классы. Структурные классы расширяются в другие структурные классы, также как и абстрактные классы. Например, структурный класс, именуемый organizationalPerson (заданный в RFC 2256) расширяется в класс объекта person, который в свою очередь расширяется в класс объекта top.

Класс объекта organizationalPerson отображает конкретный тип субъекта, работающего в учреждении. Следовательно, он определяет атрибуты, которые могут применяться к субъекту, работающему в учреждении (например, должность служащего). Рисунок 11 отображает класс объекта organizationalPerson на экране JXplorer:

Рисунок 11. Класс объекта organizationalPerson
Класс объекта organizationalPerson

Вспомогательные классы объекта предназначаются для решения некоторых весьма специфических задач. Это означает, что вспомогательные классы объекта не содержат универсальных типов атрибута (таких как типы атрибута cn и objectClass, о которых говорилось ранее), требуемых почти во всех записях данных.

Запись данных не может полностью основываться на вспомогательном классе объекта. Следовательно, запись данных, использующая вспомогательный класс объекта должна также использовать хотя бы один структурный класс. Позже в данном разделе я приведу пример вспомогательного класса, когда я буду показывать вам, как хранить объекты Java в ApacheDS.


Типы атрибута в ApacheDS

Теперь давайте рассмотрим использование типов атрибута в ApacheDS. Раскройте ярлык attributeTypes на JXplorer экране, показанном на Рисунке 8, и вы увидите экран на Рисунке 12, который отображает многочисленные типы атрибута. Данные типы атрибута определяются несколькими спецификациями, поддерживаемыми ApacheDS (как например RFC 2713, которая определяет типы атрибута и классы объекта для хранения объектов Java в LDAP-каталоге; см. Resources).

Рисунок 12. Типы атрибута, поддерживаемые ApacheDS
Типы атрибута, поддерживаемые ApacheDS

Щелкните cn запись атрибута, показанную на Рисунке 12 и вы увидите экран, схожий с изображением, показанном на Рисунке 13. Рисунок 13 отображает поля, которые совместно определяют тип атрибута:

Рисунок 13. Тип атрибута cn
Тип атрибута cn

Вы уже имеете представление о нескольких из выше перечисленных полей из моего предыдущего пояснения о классе объекта person, следовательно я поясню только то, с чем вы прежде не встречались в данном разделе:

Таблица 2. Дополнительные поля
EQUALITYЗадает правило сочетаемости, которое применяется при поиске записей данных с определенными значениями атрибута. Значением этого поля для cn типя атрибута является caseIgnoreMatch. Использование данного типа атрибута и значений означает, что при поиске человека с конкретным именем, операция поиска будет проводиться без учета регистра.
SUBSTRСходно с EQUALITY полем, за исключением того, что SUBSTR поле задает правила сочетаемости для операции поиска, выполняемой для поиска указанных подпоследовательностей вместо цельного значения атрибута. Я продемонстрирую действие SUBSTR поля в Части 2 данного раздела.

Также обратите внимание на поле SYNTAX на Рисунке 13, которое содержит OID значение. OID значение распознает синтаксис (или формат данных) для значения атрибута. Каждый тип атрибута определяет синтаксис данных, предназначенных для хранения в качестве значения атрибута. OID на Рисунке 13 указывает на LDAP синтаксис, используемый для хранения последовательностей, цепочек в LDAP каталоге. В следующем пункте рассматривается LDAP синтаксис.


LDAP синтаксис в ApacheDS

Если вы раскроете закладку Schema в JXplorer и затем щелкнете на выбор ldapSyntaxes в данном ярлыке, вы увидите алфавитный список LDAP синтаксиса, поддерживаемого ApacheDS. Найдите и щелкните по Directory String. Вы увидите экран, показанный на Рисунке 14, который отображает поля, который определяют синтаксис LDAP:

Рисунок 14. Синтаксис последовательности каталога
Синтаксис последовательности каталога

Синтаксис Directory String хранит значения последовательностей в LDAP-каталоге. Вы можете легко понять значение всех полей, поскольку они схожи с теми полями, которые я уже разъяснял. Однако обратите внимание, что поле OID на Рисунке 14 строго соответствует полю SYNTAX атрибута cn на Рисунке 13. Это происходит потому, что тип атрибута cn следует за синтаксисом Directory String в LDAP. Это значит, что LDAP обрабатывает имена как последовательности.

Также посмотрите на Рисунок 15, на котором изображен другой синтаксис LDAP, именуемый Octet String, который представляет собой последовательность октад. Объект Java хранится как последовательность октад, следовательно вы будете использовать Octet String LDAP синтаксис в данном ряду разделов.

Рисунок 15. Синтаксис последовательности октад
Синтаксис последовательности октад

'

Уже принимая во внимание синтаксисы последовательности каталога и последовательности октад, вы можете перейти к следующему этапу создания записи данных с использованием ApacheDS.


Ввод данных в ApacheDS

На данном этапе вы' уже имеете достаточно знаний о LDAP компонентах и о том, как они реализуются в ApacheDS, для внесения новых записей данных в ApacheDS. Данное упражнение поможет вам понять, как такие компоненты схемы как классы объекта, типы атрибута, и синтаксис хранят или отображают записи данных в LDAP каталоге.

Начните с открытия закладки JXplorer Explore и затем выберите запись Users (Пользователи). ApacheDS не имеет никаких пользователей по умолчанию, следовательно Users запись является пустой. Щелкните правой кнопкой мыши на запись, и вы увидите всплывающее меню. Выберите New command (Новая Команда) из всплывающего меню, и вы получите диалоговое окно, именуемое "Set Entry Object Classes", (Задать классы объектов для записи), как показано на Рисунке 16:

Рисунок 16. Задание классов объектов для записи: диалоговое окно
Задание классов объектов для записи: диалоговое окно

Первое, что вы должны сделать, это внести информацию в диалоговое окно, что будет рассмотрено в следующем пункте.

Использование синтаксиса уникального имени

Как я уже упоминал в начале моего рассмотрения схем LDAP, все данные в ApacheDS хранятся в форме дерева. Это означает, что каждая запись данных, за исключением корневой, имеет родительский элемент. Корневая запись в ApacheDS помечена как system, и вы можете ее увидеть на Рисунке 16.

Каждая запись имеет DN, которое должно быть уникальным для всего каталога. RFC 2253 (см. Resources) обеспечивает синтаксис для написания DN в форме последовательности. Согласно RFC 2253, DN пишется как список компонентов через запятую, где каждый компонент имеет свое значение. Хотя вы можете использовать несколько компонентов для определения DN, в данном разделе я использую только три из них: ou, uid, и cn. Каждый из них имеет различные задачи:

  • Компонент ou указывает имя организационной единицы. В рамках данного раздела вы можете представить, что это фактически является именем единицы данных организации. Вы можете структурировать различные типы данных в ApacheDS, используя этот атрибут.
  • Компонент uid обеспечивает идентификатор пользователя для записи. Обычно вы используете этот атрибут для идентификации пользователей (например, Элис) ApacheDS.
  • Компонент cn называет объекты Java.

DN для корневой записи system, показанной на Рисунке 16 это ou=system. Запись "users" является прямым порождением всей системы, следовательно DN пользователей это ou=users, ou=system. Обратите внимание, что первая часть user' DN (ou=users) называется его relativedistinguished name (Уникальное Относительное Имя) (RDN).

Создание записи RDN (относительного имени пользователя)

RDN порожденной записи (например, ou=users) добавляется к началу родительской DN (например, ou=system) через запятую для формирования DN порожденной записи (например, ou=users, ou=system). Две непосредственных порожденных записи родительского элемента (как то родственные узлы) не могут иметь одинаковое RDN. Это обеспечивает единичность DNов в объеме всего каталога LDAP.

Принимая это во внимание, вы легко сможете понять значение полей Parent DN и Enter RDN, показанных на Рисунке 16. При создании новой записи вы щелкаете правой кнопкой мыши по ярлыку Users, и затем появляется поле Parent DN, которое уже заполнено DN Users записи.

На следующем этапе вы задаете запись RDN, которую вы хотите создать. Рассмотрим пример этого применения, где вы хотите создать нового пользователя, именуемого Элис, для этого вы вводите uid=Alice в поле Enter RDN на Рисунке 16. Для этого создается uid=alice, ou=users, ou=system DN Alice записи.

Обратите внимание, что запрос данных или операция поиска по отличительным именам (которые я демонстрирую во второй половине данного раздела) совершаются без учета регистра. Это означает, что исходя из практических целей, нет никакой разницы между указанием uid=Alice или uid=alice в качестве значения поля RDN.

Использование классов объекта

Пока все идет хорошо. Далее вы выбираете классы объекта для внесения вашей новой записи. Вы можете выбрать любое число классов объекта для записи. При выборе класса объекта вам необходимо подключить все обязательные атрибуты, включенные в отдельный класс объекта. В дополнение, вы можете также подключить любой из выборочных атрибутов класса объекта.

Напомню вам, что Элис работает в коммерческом отделе компании, для которой вы создаете систему управления данными, следовательно ей необходимы только атрибуты, характерные для класса объекта organizationalPerson, который был представлен на Рисунке 11. Поэтому вы добавляете organizationalPerson класс объекта в Selected Classes (Выбранные Классы) список, показанный на Рисунке 16 и щелкаете OK.

Перед вами экран на Рисунке 17, который отображает запись Alice вскоре после диалогового окна Задать классы объектов для записи (Set Entry Object Classes). Обратите внимание на Рисунок 17, где значение Alices uid (идентификатора пользователя), (которое вы только что создали) выделено голубым цветом:

Рисунок 17. Запись Alice вскоре после диалогового окна Задать классы объектов для записи
Запись Alice вскоре после диалогового окна Задать классы объектов для записи

Применение значений атрибута

Далее вам необходимо ввести значения для обязательных атрибутов (cn и sn, выделенных жирным шрифтом на Рисунке 15) и щелкнуть Submit. Затем JXplorer создает запрос LDAP для создания новой записи и посылает его в ApacheDS.

ApacheDS посылает ответное сообщение с подтверждением обратно в JXplorer, и JXplorer обновляет дерево данных, как показано на Рисунке 16. Вы видите итоговую запись, именуемую Alice в правой части Рисунка 18:

Рисунок 18. Запись для Alice
Запись для Alice

Итак, с этим мы разобрались. Вы выполнили свой первый ввод записи данных с использованием ApacheDS!


Java-сериализация и протокол RMI (Remote Method Invocation)

Всякий раз как вы хотите сохранить Java-объект в каталоге, вам прежде всего необходимо преобразовать ваш объект Java в байты информации. Этот преобразовательный процесс называется serialization (сериализация/преобразование в последовательную форму). Результатом процесса сериализации является поток байтов, который может перемещаться по сети и к ApacheDS, где он может храниться в виде представления байтов вашего Java-объекта.

Remote Method Invocation (RMI - Удаленный Вызов Метода) особым образом использует процесс сериализации. Прежде чем я начну подробно объяснять процесс хранения Java-объектов в ApacheDS, позвольте убедиться, что вы знакомы с используемым понятийным аппаратом'

Сериализация объекта Java

В языке Java имеется спецификация, называемая Java Object Serialization Specification version 1.5, которая определяет процесс преобразования объекта Java в поток байтов (см. Resources). В соответствии с Java Object Serialization specification, процесс сериализации Java-объекта уже реализован в JRE в виде рабочего цикла сериализации, выполняющего сериализацию и десериализацию объектов Java.

Сериализация пользователя

Если ваша структура приложения не позволяет вашим компонентам данных быть сериализуемыми (например, один из компонентов данных принадлежит к существующему несериализуемому классу), вам необходимо ввести вашу собственную пользовательскую логическую схему сериализации и десериализации в Java классе, который вы хотите сериализовать. Сериализция пользователя выходит за рамки данного раздела; см. Resources для получения более детальной информации по сериализации пользователя.

Рабочий цикл сериализации содержит пару методов, writeObject() и readObject(), которые используются для сериализации и десериализации объектов Java согласно Java Object Serialization specification. объект Java, который вы хотите сериализовать, нуждается только в реализации интерфейса, именуемого java.io.Serializable. Интерфейс Serializable не содержит никаких методов: он предназначен только для того, чтобы сообщить рабочему циклу сериализации, о том, что ваш объект может быть сериализован.

Обратите внимание на то, что рабочий цикл сериализации преобразовывает компоненты данных ваших объектов Java во время процесса сериализации. Если какие-либо компоненты данных сами являются другими Java-объектами, вам необходимо сериализовать эти компоненты вместе с основным объектом, который вы хотите сериализовать. Следовательно, такие компоненты данных должны также реализовывать Serializable интерфейс.

Во второй части данного раздела я продемонстрирую как использовать поддержку сериализации по умолчанию в Java для хранения Java-объектов в ApacheDS.

RMI

В дополнение к сериализации ваших объектов вы сможете применить специфическую кодировку к представлению байта, прежде чем отправить их по сети. Данный процесс кодирования называется marshalling (формирование/компоновка), и является важным элементом Java RMI Спецификации. Структура RMI позволяет вашим Java-приложениям использовать удаленные объекты. Удаленный объект храниться вне области действия вашего Java-приложения, также как и везде в Интернет.

Используя RMI, вы можете запрашивать методы удаленных объектов так же, как запрашиваете методы локальных объектов. Для этого вам необходим суррогат класса (stub class) удаленного объекта. Суррогат класса содержит метод, характерный для удаленного объекта. Ваше приложение приписывает значение фиктивному классу и местно запрашивает его методы. Затем структура RMI осуществляет сообщение с удаленным объектом, в результате чего происходит удаленная активизация запрашиваемых методов. В итоге приложению не важно, является ли объект в действительности локальным или удаленным.

Элементы структуры RMI выходят за рамки данного раздела, но вы можете получить дополнительную информацию, последовав этой ссылке: Resources. Что действительно важно в данном обзоре, как вы уже могли догадаться, так это то, что структура RMI позволяет Java-объектам перемещаться по сети для активации методов удаленного объекта. Следовательно, RMI необходимо сериализовать Java-объекты. Спецификация RMI определяет компоновочный алгоритм, который применяется к сериализованной форме Java-объектов. В алгоритм включены специальные метки в сериализованных объектах.

Спецификация RMI уже реализуется в J2SE, следовательно, вам не надо беспокоиться о низкоуровневых компонентах формирования объекта. Вы можете просто использовать RMI классы для формирования ваших Java-объектов. LDAP позволяет вам хранить сформированные Java-объекты каталоге в LDAP. Во второй части данного раздела я продемонстрирую, как формировать и расформировывать объекты Java, а также как хранить и извлекать их в ApacheDS.


Хранение объектов Java в ApacheDS

В завершении данного раздела я рассмотрю простейшее приложение полученной вами информации. Я покажу вам, как отображать сериализованный объект Java, использовать различные классы объекта, отображать скомпонованный объект Java и хранить ссылку на объект Java в ApacheDS. В Части 2 я подробнее рассмотрю эти простые примеры; а сейчас просто сосредоточусь на основных предусмотренных этапах.

Сначала вам необходим набор классов объекта для дальнейшей работы. RFC 2713 (см. Resources) определяет классы объекта и типы атрибута для отображения Java-объектов в LDAP каталоге. ApacheDS обеспечивает полную поддержку данных типов атрибута и классов объекта. Я использую четыре класса объекта в данном примере и примерах в Части 2: javaContainer, javaObject, javaSerializedObject и javaNamingReference. Давайте обратим внимание на первые два класса объекта и их атрибуты.

Класс javaContainer (изображен на Рисунке 19) является структурным классом, содержащим всего один атрибут: cn. Целью данного класса объекта является наименование записи данных, содержащих объект Java. LDAP позволяет вам использовать другие структурные классы объекта для наименования вашего объекта Java. Например, вы можете также использовать класс объекта person для хранения вашего объекта Java.

Рисунок 19. Класс javaContainer
Класс javaContainer

Класс javaObject является абстрактным классом. Целью этого класса объектов является определение вспомогательных атрибутов, которые не используются напрямую для хранения данных Java-объекта, но могут быть полезными для нахождения или извлечения объекта из каталога при операции поиска. На Рисунке 20 изображен javaObject класс:

Рисунок 20. Класс javaObject
Класс javaObject

Типы атрибута в javaObject классе, изображенные на Рисунке 20, являются следующими:

  • Обязательный тип атрибута, именуемый javaClassName, хранит имя класса, чей представитель хранится в ApacheDS. Обычно вы используете этот тип атрибута для нахождения представителей определенного класса, хранящегося в ApacheDS.
  • Другой тип атрибута, именуемый javaClassNames, хранит имена всех суперклассов объекта Java, а также имена всех интерфейсов, которые реализует объект. Этот атрибут предназначен для хранения ряда значений, следовательно, он является многозначным типом атрибута. LDAP позволяет многозначным атрибутам хранить множество значений. Вы используете javaClassNames тип атрибута для поиска объектов, реализовавших отдельный интерфейс или объектов, расширяющих отдельный класс.
  • Тип атрибута javaCodebase, изображенный на Рисунке 20, хранит месторасположение, необходимое для нахождения определения класса для сохраняемого Java-объекта. Он является выборочным атрибутом, который вы используете в том случае, если ваше приложение требует определения загрузочного класса путем считывания их местонахождения из ApacheDS.
  • Тип атрибута javaDoc также является выборочным и служит носителем URL, указывающего на Java документацию класса, чей представитель хранится в ApacheDS.

Как вы уже можете догадаться, тип атрибута description хранит текстовое описание класса.

Представление сериализованного Java-объекта

Обратите внимание, что ни один из типов атрибута в javaObject не хранит фактическую последовательность октад, которая представляет хранящийся объект. Поэтому javaObject класс остается абстрактным, и вот почему вы не можете использовать его напрямую для создания записи данных. LDAP определил javaObject класс таким образом, потому что LDAP позволяет вам хранить объекты Java в различной форме (например, объекты в сериализованной или скомпонованной форме). Каждая форма представления объекта имеет свой собственный класс объекта, который расширяет javaObject класс.

Класс объекта, именуемый javaSerializedObject (изображен на Рисунке 21) расширяет класс javaObject путем добавления всего одного атрибута, именуемого javaSerializedData. Атрибут javaSerializedData содержит фактическую сериализованную форму вашего объекта Java.

Класс javaSerializedObject, изображенный на Рисунке 21, является вспомогательным классом объекта, вследствие причин, которые я кратко объясню:

Рисунок 21. Класс javaSerializedObject
Класс javaSerializedObject

Теперь посмотрите на Рисунок 22, где сериализованный объект Java, именуемый MessagingPreferences хранится в ApacheDS, как изображено на экране JXplorer:

Рисунок 22. Объект Alice MessagingPreferences, хранящийся в ApacheDS
Объект Alice MessagingPreferences, хранящийся в ApacheDS

Объект MessagingPreferences на Рисунке 22 отображает параметры, которые будут применены вашим пользователем Элис. Вот почему MessagingPreferences объект значится как порождаемый элемент объекта записи данных Alice, который был вами ранее создан в данном разделе.

Использование различных классов объекта

Как изображено на Рисунке 22, объект записи данных MessagingPreferences использует четыре класса объекта: javaSerializedObject, javaObject, javaContainer и top. Можете ли вы догадаться почему объект MessagingPreferences нуждается в этих четырех классах?

Объекту записи данных MessagingPreferences необходим класс javaSerializedObject потому, что вы храните сериализованную форму объекта MessagingPreferences.

Ему необходим класс javaObject потому, что класс javaSerializedObject расширяет класс javaObject. Это значит, что всякий раз когда объект записи данных использует класс javaSerializedObject, он также использует класс javaObject.

Ему необходим класс javaContainer потому, что ни один из этих трех классов объекта (javaSerializedObject, javaObject и top) не является структурным классом. Каждому объекту записи данных в ApacheDS необходимо использовать структурный класс. Ваши объекты Java могут использовать или javaContainer, или любой другой структурный класс (такой как класс объекта person). LDAP требуется, чтобы вы сочетали ваши записи Java-объекта со структурными классами (такими как javaContainer или person), так что спецификация LDAP определила класс javaSerializedObject как вспомогательный.

И наконец, объекту записи данных MessagingPreferences необходим класс top потому, что все классы объекта разворачиваются из верхнего (top) класса, как я уже объяснял выше.

Отображение сформированного объекта Java

Теперь посмотрите на Рисунок 23, где изображен сформированный объект Java, хранящийся в ApacheDS:

Рисунок 23. Сформированный объект, хранящийся в ApacheDS
Сформированный объект, хранящийся в ApacheDS

Вы можете сравнить Рисунок 23 с Рисунком 22 (где изображен сериализованный объект на экране JXplorer). Атрибут javaClassName на Рисунке 23 показывает, что запись содержит объекта, принадлежащего классу java.rmi.MarshalledObject. Я еще использую данный класс во второй части раздела для того, чтобы продемонстрировать формирование объектов Java.

Хранение ссылок объекта Java

Наконец, LDAP также позволяет вам хранить reference (ссылку) на объект Java в каталоге вместо хранения фактического объекта. В этом случае вы храните адрес вашего Java-объекта в ApacheDS. При разыменовании адреса для извлечения представителя вашего объекта вам необходим производственный объект. Производственный объект реализует вашу логическую процедуру разыменования.

Основным преимуществом хранения ссылки является коллективное использование объекта среди пользователей. Например, рассмотрим класc MessagingPreferences, который я упоминал ранее в комментарии к Листингу 1. Если несколько пользователей совместно используют общие параметры сообщения, возможно, удобнее хранить всего один элемент MessagingPreferences, отображающий общие параметры ссылки для каждого пользователя в отдельности.

RFC 2713 имеет класс объекта, именуемый javaNamingReference (изображенный на Рисунке 24), который расширяет класс javaObject и определяет два новых типа атрибута, именуемых javaReferenceAddress и javaFactory. Тип атрибута javaReferenceAddress хранит ссылку (или адрес) Java-объекта, а тип атрибута javaFactory хранит имя заводского объекта.

Рисунок 24. Класс javaNamingReference
Класс javaNamingReference

Выводы к Части 1

В первой части моего ознакомительного курса по хранению объектов Java в ApacheDS вы немного узнали о встраиваемых протоколах поддержки ApacheDS. Вы также ознакомились с основными LDAP понятиями и терминологией, как то отличительные имена, классы объекта, типы атрибута и LDAP синтаксис. В заключение вы научились тому, как можно использовать LDAP для отображения и хранения объектов Java в ApacheDS.

Во второй части данного раздела вы примените эти понятия на практике. Я рассмотрю несколько примеров Java-приложений, наряду с многочисленными кодировками Java для того, чтобы наглядно показать как хранить, искать и извлекать объекты Java в ApacheDS. Примеры приложений реализуют различные аспекты сценария управления данными, представленными здесь. Прежде, чем подвести итоги второй части данной статьи я также кратко представлю основные понятия в форме урока по технологии Java, который вы сможете использовать в разработке ваших собственных приложений. Перейти к Части 2 сейчас.


Загрузка

ОписаниеИмяРазмер
Source codej-apachedssource.zip40KB

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source
ArticleID=186225
ArticleTitle=Хранение объектов Java в Apache Directory Server, Часть 1
publish-date=12282006