6.2. Служба идентификации документов
Этот пример напоминает предыдущий, поскольку документы в этой системе можно рассматривать аналогично автомобильным деталям. Различие состоит в том, что информация о документе хранится близко к его автору (обычно на его настольном компьютере). Это означает, что число передач полномочий может быть достаточно большим. Кроме того, для того, чтобы избавиться от необходимости поддержки большого плоского пространства авторов, они организованы по компаниям и подразделениям.
Предположим, что строка Application Unique String для данного примера имеет вид:
<organization>-<department>-<author>:<project>-<bookcase>-<book>
Спецификация приложения может выглядеть примерно так:
- Application Unique String — приведенная выше строка идентификации документа;
- First Well Known Rule — символы до (но не включая) «-» трактуются, как первый Ключ;
- Valid Databases — каталог DIS LDAP;
- Expected Output — запись с сервера LDAP, содержащая библиографические данные о документе в формате XML.
Спецификация базы данных для DIS LDAP Directory будет иметь вид:
- General Specification — база данных использует службу каталогов LDAP; каждый сервер LDAP имеет запись, содержащую Правило перезаписи; правила указывают на другие серверы LDAP, используя схему LDAP URL;
- Lookup Procedure — используя стандартные запросы LDAP, клиент спрашивает у сервера LDAP информацию о ключе;.
- Key Format — преобразование не требуется;
- Rule Format — см. спецификацию LDAP Rewrite Rule;
- Rule Insertion Procedure — см. процедуры, опубликованные стороной, имеющей полномочия для данной ветви дерева DIS; первым разделом (организация) владеет Агентство DIS.
В этом примере первый поиск осуществляется по организации. В результате организация может может возвратить клиенту конечный результат, если база данных этой организации содержит его. В других случаях процесс может включать дополнительные Правила и делегировать запрос вниз по иерархии к владельцу документа.