4. Спецификация Приложения
Для того, чтобы описанный алгоритм стал используемым, нужно написать спецификации приложения и по крайней мере одной базы данных. Для задания спецификации приложения требуются перечисленные ниже компоненты.
- Application Unique String — Уникальная Строка Приложения
Это единственная строка, к которой применяются правила перезаписи. Строка должна иметь регулярную структуру и быть уникальной в приложении так, чтобы все, кто применяет Правила из одной Базы данных, получали в результате одинаковые Ключи. Например, приложение URI Resolution в качестве Application Unique String определяет URI.
Ни каким приложениям не дозволено определять Application Unique String так, чтобы Ключ, полученный правилом перезаписи, трактовался бы как Application Unique String для ввода в новое правило, поскольку это ведет к правилам перезаписи в стиле sendmail, которые отличаются склонностью к ошибкам. Единственное исключение из этого правила возможно в случае, когда Приложение определяет некий флаг или состояние, в котором правила для приложения подавляются и принимается новое Приложение DDDS или некий произвольный набор правил. Один из таких случаев можно найти в приложении URI Resolution, которое определяет флаг p, указывающий, что следующий шаг зависит от протокола (protocol specific) и, таким образом, выходит за рамки DDDS.
- First Well Known Rule — Первое Общеизвестное Правило
- Это первое правило, которое применяется к Application Unique String и создает первый Ключ. Для выражения может использоваться такая же форма, какая принята для Правил, или несколько более сложная форма. Например, приложение URI Resolution может задавать, что это правило возвращает в качестве первого Ключа последовательность символов URI вплоть (но не включая) до первого двоеточия (схема URI).
- Valid Databases — корректные Базы данных
- Приложение может определить, какая из Баз данных является корректной. Для каждой базы данных Приложение должно определить, как вывод правила First Well Known Rule (первый Ключ) может быть обращен во что-либо, подходящее для этой Базы данных. Например, приложение URI Resolution может использовать в качестве Базы данных систему DNS. Операция обращения первого Ключа во что-либо, подходящее для базы данных, будет преобразованием в некое корректное с точки зрения DNS имя. В дополнение для каждой Базы данных, которую определяет Приложение, оно должно задать допустимые наборы символов, которые будут порождать корректные Ключи. В примере URI Resolution набором символов URI является 7-битовый код ASCII, который согласуется с 8-битовым ограничением для символов в файлах зон DNS.
- Expected Output — ожидаемый результат
- Приложение должно определить ожидаемый результат Завершающего Правила. Например, приложение URI Resolution направлено на поиск серверов, которые содержат полномочные данные о данном URI. Таким образом, результатом завершающего правила будет информация (хосты, порты, протоколы и т.п.), которая будет служить для контакта с полномочным сервером.
В прошлом были некоторые недоразумения, касающиеся распределения нагрузки и использования DDDS Priority. Приложениям следует понимать, что Priority данного правила является лишь способом показать, что одно правило «быстрее, лучше, дешевле» другого. Если приложению требуется некий метод, позволяющий клиенту распределять нагрузку между серверами (например, взвешенный случайный выбор и т.п.), это следует реализовать за пределами алгоритма DDDS. Например, Приложение, использующее DNS Database может трактовать запись SRV, как способ обозначения того, что определенная служба действительно поддерживается несколькими скооперированными хостами. Распределение нагрузки будет осуществляться между хостами, которые идентичны с точки зрения DDDS в части путей передачи полномочий, которые имеют некий общий набор свойств или административный домен.