2. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119.
- Application Unique String — Уникальная строка Приложения
- Строка, являющаяся начальными данными для приложения DDDS. Лексическая структура этой строки должна заключать в себе уникальный путь делегирования, который анализируется и трассируется повторяющимся выбором и применением правил перезаписи (Rewrite Rule).
- Rewrite Rule — правило перезаписи
- Правило, которое применяется к Application Unique String для создания нового ключа выбора нового правила перезаписи из базы правил или результирующей строки, которая возвращается вызвавшему приложению. Часто используется просто термин Правило (Rule).
- First Well Known Rule — первое общеизвестное правило
- Это правило перезаписи, которое определяется приложением и реально не хранится в базе правил (Rule Database). Это праило используется для создания первого корректного ключа.
- Terminal Rule — конечное правило
- Правило перезаписи, при использовании которого возвращается строка конечного результата процесса DDDS, а не другой ключ базы данных.
- Application — Приложение
- Набор протоколов и спецификаций, которые задают реальные значения для различных обобщенных частей алгоритма DDDS. Приложение должно определять синтаксис и семантику Application Unique String, First Well Known Rule и одной или множества баз данных, которые корректны для этого Приложения.
- Rule Database — База правил
- Любое хранилище правил, позволяющее по уникальному ключу идентифицировать набор правил, задающих этап передачи полномочий используемый для конкретного значения ключа (Key).
- Services — службы
- Общая база правил может использоваться для связывания различных служб с данной строкой Application Unique String (например, различные функции протокола, разные рабочие характеристики, географическое положение, обратная совместимость и т.п.). Возможными вариантами служб могут быть, например, получение сообщения по факсу/телефону/электронной почте, распределение нагрузки между web-серверами, выбор ближайшего сервера-зеркала, учет отношения цена/производительность и т.п. Эти Службы включаются как часть Правила, чтобы позволить Приложению принять решение о выборе на основе применимости той или иной ветви процесса или иных параметрой Сервиса.
- Flags — флаги
- Большинство Приложений будет требовать для Правил способа сигнализировать Приложению, что некие Правила обеспечивают варианты результата (например, различные форматы вывода, механизмы расширяемости, сигнализация конечного правила и т.п.), тогда, как другие правила этого не делают. Большинство Баз данных определяют поле Flags, которое Приложение может использовать для представления различных значений, выражаемых этими сигналами.