Спецификация интерфейса приложения - Википедия - Application Interface Specification
 | Эта статья не цитировать любой источники. (Март 2010 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
В Спецификация интерфейса приложения (АИС) представляет собой набор открытых спецификаций, определяющих интерфейсы прикладного программирования (API) для прикладного компьютерного программного обеспечения высокой доступности. Он разработан и опубликован Форум доступности услуг (Форум SA) и находится в свободном доступе. Помимо снижения сложности приложений с высокой доступностью и сокращения времени разработки, спецификации предназначались для облегчения переносимости приложений между различными реализациями промежуточного программного обеспечения и допуска сторонних разработчиков в область, которая в прошлом была очень частной.
История
AIS является частью интерфейсов доступности услуг (SAI) SA Forum. Исходные спецификации, выпущенные 14 апреля 2003 г., включали в себя структуру управления доступностью (AMF), службу членства в кластере (CLM) и четыре других служебных службы (контрольная точка, событие, сообщение, блокировка).
Дополнительные услуги были добавлены в последующих выпусках.
- В версии 3 (18 января 2006 г.) добавлен первый набор служб управления: журнал, уведомление и управление информационными моделями (IMM).
- Версия 4 (27 февраля 2007 г.) расширила служебные службы с помощью таймера и именования.
- Версия 5 (16 октября 2007 г.) расширила службы управления с помощью Security и добавила Software Management Framework.
- В выпуске 6 (21 октября 2008 г.) добавлена служба управления платформой, чтобы сократить разрыв между AIS и HPI (Интерфейс аппаратной платформы ).
AIS состоит из 12 сервисов и двух фреймворков. Эти службы подразделяются на три функциональные группы - службы платформы AIS, базовые службы управления AIS и общие служебные службы AIS - в дополнение к структурам AIS.
Первоначально API были определены в Язык программирования C только, но по состоянию на июль 2008 г. Ява отображение различных API сервисов выпускается постепенно.
Зависимости сервисов
Различные службы и структуры спецификаций интерфейса были разработаны так, чтобы модульный и в определенной степени независимы друг от друга. Это позволяет системе, предоставляющей только AIS, без HPI существовать и наоборот.
Единственная необходимая архитектурная зависимость - это зависимость от службы членства в кластере (CLM). Все службы AIS, за исключением службы управления платформой (PLM) и службы таймера (TMR), зависят от CLM.
Ожидается, что все службы AIS должны использовать службы управления AIS для предоставления своих административных интерфейсов, конфигурации и информации управления средой выполнения (рис. 2).
Сервисы платформы
Служба управления платформой (PLM) обеспечивает логическое представление оборудования и программного обеспечения нижнего уровня системы. В этом смысле низкоуровневое программное обеспечение включает в себя уровни операционной системы и виртуализации, которые обеспечивают среды выполнения для всех видов программного обеспечения.
Основные логические объекты, реализованные PLM:
- Аппаратный элемент (HE) - Аппаратный элемент - это логический объект, который представляет любой вид аппаратного объекта, который может быть, например, шасси, Лезвие процессора, или устройство ввода-вывода. Обычно все Сменные блоки в полевых условиях (FRU) моделируются как элементы оборудования.
- Среда выполнения (EE) - Среда выполнения - это логический объект, представляющий среду, в которой могут выполняться некоторые программы. Например, blade-сервер ЦП или SMP машина запускает один экземпляр операционной системы, смоделированный как среда выполнения. Поддерживаются различные архитектуры виртуализации (рис. 4).
PLM поддерживает состояние этих сущностей в информационной модели и предоставляет средства для контроль их и отслеживать любые изменения состояния. Для выполнения этих задач для HE служба PLM обычно использует HPI. В случае EEs PLM отвечает за получение всей необходимой информации о состоянии операционной системы и всех доступных уровнях виртуализации.
Служба членства в кластере (CLM) предоставляет приложениям информацию о членстве об узлах, которые были административно настроены в конфигурации кластера (эти узлы также называются узлами кластера или настроенными узлами), и является ядром любой кластерной системы. Кластер состоит из этого набора настроенных узлов, каждый из которых имеет уникальное имя.
Служба членства в кластере реализует два логических объекта:
- Кластер - Представляет сам кластер и является родительским объектом для объектов узла кластера.
- Узел кластера - представляет настроенный узел кластера.
CLM предоставляет API-интерфейсы для получения текущей информации о членстве в кластере и отслеживания изменений членства (например, выход из узла, присоединение к нему). Все общекластерные службы AIS должны использовать API отслеживания CLM для определения членства.
Управленческие услуги
Различные объекты, реализованные сервисами AIS (например, среды выполнения, контрольные точки, компоненты и т. Д.), Представлены как управляемые объекты на форуме SA Информационная модель (IM), который можно рассматривать как база данных управления конфигурацией. Управляемые объекты - это экземпляры классов объектов, определенных соответствующей спецификацией службы AIS, которая определяет атрибуты класса и административные операции. Административные операции, указанные для классов объектов, представляют собой операции, которые могут выполняться над сущностями, представленными объектами, например блокировка служебной единицы или экспорт содержимого IM в формате XML. Объекты в IM хранятся в древовидной иерархии, где объект может иметь не более одного родительского объекта и любое количество дочерних объектов.
Логические объекты, представленные объектами в IM, обычно не реализуются самой службой IMM; вместо этого пользовательские приложения и службы AIS, такие как служба контрольных точек или структура управления доступностью, обеспечивают их реализацию. Поэтому они называются исполнители объектов (OI). В целях управления все службы AIS представляют свои реализованные объекты как управляемые объекты через службу IMM.
В IM есть две категории объектов и атрибутов: время выполнения и конфигурация.
Время выполнения объекты и атрибуты отражают текущее состояние объектов, которые они представляют - они описательный природа.
Напротив, объекты конфигурации и атрибуты находятся предписывающий что касается приложений управления - или менеджеры объектов (OM) - это средства для предоставления разработчикам объекта ввода информации о том, какие сущности им необходимо реализовать.
Объекты конфигурации могут включать как атрибуты конфигурации, так и атрибуты времени выполнения, в то время как объекты времени выполнения могут включать только атрибуты времени выполнения. Административные операции могут быть определены для обеих категорий объектов.
Соответственно, служба IMM предоставляет «на юг »- интерфейс IMM-OI API - к разработчикам объектов и«движущийся на север »- IMM-OM API - к приложениям управления (рис. 5), например Агенты SNMP и являются посредниками между этими двумя сторонами. Он также отвечает за хранение постоянных объектов и атрибутов.
Журнал
Служба журнала предназначена для регистрация событий, то есть для сбора общекластерной, функциональной (в отличие от конкретной реализации) информации о системе, которая подходит для системных администраторов или автоматизированных инструментов.
Служба журнала позволяет приложениям выражать и записывать записи журнала через потоки журнала, ведущие к определенным местам назначения вывода, таким как именованный файл. Попав в место назначения вывода, запись журнала подчиняется правилам форматирования вывода, которые можно настраивать и открывать для всех. Приложению ведения журнала не нужно знать ни о каком из этих аспектов (например, о местоположении файла назначения, ротации или форматировании файлов и т. Д.), Поскольку служба журнала обрабатывает их на основе текущих настроек для целевого потока журнала. Поскольку выходной формат является общедоступным, сторонние инструменты могут читать эти файлы журналов.
Указаны четыре типа потоков журналов: тревога (Записи журналов на основе ITU X.733 и ITU X.736), уведомление (Записи журналов на основе ITU X.730 и ITU X.731), система и применение. Тип приложения используется приложениями для определения потоков журналов для конкретных приложений. В кластере SA Forum существует ровно один предопределенный поток журнала для каждого типа потока сигналов тревоги, уведомлений и системного журнала. Пользовательским приложениям разрешено использовать любой из предопределенных потоков или создавать новые потоки журналов для конкретных приложений.
Уведомление
Служба уведомлений в значительной степени основана на ITU-T Модель управления сбоями (как можно найти в серии документов X.700), а также многие другие вспомогательные рекомендации.
Служба уведомлений основана на концепции уведомление, который объясняет происшествие или изменение статуса. Термин «уведомление» используется вместо «событие», чтобы четко отличить его от «события», как это определено службой событий AIS.
Сервис NTF основан на опубликовать-подписаться парадигма. Он определяет шесть типов уведомлений: тревога, тревога безопасности, создание / удаление объекта, изменение состояния, изменение значения атрибута и прочее. Уведомления генерируются / публикуются производители с помощью API производителя уведомлений. Потребители уведомлений могут быть либо подписчики, которые подписываются на уведомления и получают их по мере их появления; или читатели, которые получают уведомления из сохраненных журналов с помощью API-интерфейса потребителя уведомлений. Оба типа потребителей уведомлений могут определять фильтры, которые определяют характеристики уведомлений, которые они заинтересованы в получении или чтении.
Уведомления могут генерироваться службами AIS, а также приложениями. У служб AIS, которые генерируют уведомления, есть раздел в спецификации, описывающий их уведомления.
Безопасность
Служба безопасности предоставляет механизмы, которые могут использоваться службами AIS для аутентифицировать Клиентские процессы службы AIS (и, возможно, другие) в кластере и для разрешить им выполнять определенные действия. Эти механизмы можно использовать для сохранения честность инфраструктуры высокой доступности и приложений SA Forum, включая их данные, путем защиты от несанкционированного доступа.
Обеспечение безопасности делегировано самим реализациям службы AIS: службы AIS с поддержкой безопасности запрашивают авторизацию у реализации SEC от имени своих клиентских процессов, когда они инициируют различные действия. SEC отвечает на эти запросы авторизации с указанием разрешено или отклонено, и служба AIS должна разрешить или запретить операцию соответственно. SEC предоставляет эти показания на основе набора политики безопасности настраивается через IMM. Он также информирует своих подписчиков об изменениях политики с помощью соответствующих обратных вызовов.
Каркасы
Структура управления доступностью
Структура управления доступностью позволяет доступность услуги в системах, совместимых с SA Forum. Он координирует рабочую нагрузку различных субъектов, находящихся под его контролем, в зависимости от степени их готовности предоставлять услуги. Для этого приложение необходимо описать в соответствии с информационной моделью, указанной для AMF. Эта модель описывает, какие ресурсы принадлежат приложению в кластере и какие услуги предоставляет приложение.
Основной логической сущностью этой информационной модели является составная часть, который представляет собой набор ресурсов для инфраструктуры управления доступностью, которые инкапсулируют некоторые конкретные функции приложения. Рабочая нагрузка, создаваемая предоставлением некоторой службы, которая может быть назначена компоненту с помощью AMF, представлена как экземпляр службы компонентов (CSI). Когда компонент активно предоставляет услугу, ему назначается активное состояние от имени CSI, представляющего услугу.
Основополагающий принцип отказоустойчивый дизайн заключается в предоставлении услуг набором избыточные объекты и поэтому компоненты должны иметь возможность действовать как резервные от имени CSI. Резервные компоненты поддерживают себя в таком состоянии, чтобы они были способны взять на себя предоставление услуг, если компонент с активным назначением выйдет из строя. Роль AMF заключается в назначении активных или резервных рабочих нагрузок компонентам приложения в зависимости от состояния компонентов и конфигурации системы.
Соответственно, API-интерфейсы, предоставляемые структурой управления доступностью, позволяют регистрировать компоненты, управлять жизненным циклом и назначать рабочие нагрузки. Они включают в себя функции для отчетов об ошибках и мониторинга состояния. Они также позволяют отслеживать назначение экземпляров службы компонентов среди набора компонентов, защищающих CSI.
Конфигурация инфраструктуры управления доступностью включает политики восстановления и исправления. Он позволяет приоритизировать ресурсы и предоставляет множество моделей резервирования. Они варьируются от простой модели 2N (также известной как 1 + 1 или активный резервный) до более сложных, таких как модель N-стороннего резервирования, которая позволяет выполнять более одного резервного назначения от имени одного и того же экземпляра компонентной службы или N-way-active, который позволяет выполнять несколько активных назначений.
Для упрощения администрирования AMF дополнительно группирует компоненты в сервисные единицы и группы сервисов, а экземпляры сервисов компонентов - в экземпляры сервисов. Все это составляет приложение. Через IMM над этими логическими объектами доступен набор административных операций.
Для целей управления программным обеспечением объекты, на которых работает одно и то же программное обеспечение, сгруппированы по типам, что позволяет использовать единую точку входа для конфигурации этих объектов.
Платформа управления программным обеспечением
Систему, совместимую с SA Forum, можно охарактеризовать конфигурацией развертывания, которая состоит из программного обеспечения, развернутого в системе, вместе со всеми настроенными программными объектами. Конфигурация развертывания составляет важную часть информационной модели, управляемой службой IMM.
Инфраструктура управления программным обеспечением (SMF) поддерживает ту часть информационной модели, которая описывает программное обеспечение, доступное и развернутое в кластере. Но главная цель SMF - дать возможность эволюции «живой» системы за счет организации миграции от одной конфигурации развертывания к другой. В терминах SMF этот процесс миграции называется кампания обновления.
Software Management Framework определяет схему XML, которая будет использоваться для определения кампании обновления. Реализация SMF переносит систему из одной конфигурации развертывания в новую желаемую на основе такого XML-файла, который по сути является сценарий упорядоченных действий и изменений конфигурации, которые приводят к новой конфигурации.
Во время этой миграции SMF
- поддерживает модель состояния кампании,
- отслеживает возможные ситуации ошибки, вызванные миграцией, и
- развертывает процедуры исправления ошибок по мере необходимости.
Для выполнения всех этих задач реализация SMF взаимодействует по крайней мере (1) с AMF, чтобы поддерживать доступность, (2) с IMM, чтобы выполнять изменения в информационной модели, и (3) с NTF, чтобы получать уведомления, которые могут указывать на ошибку. ситуации, вызванные продолжающейся кампанией.
Software Management Framework также предоставляет API для клиентских процессов, чтобы регистрировать их заинтересованность в получении обратных вызовов, когда в кластере инициируется соответствующая кампания по обновлению и когда она проходит через важные этапы. Это позволяет координировать действия, связанные с конкретным приложением, с обновлением. Это может варьироваться от простого блокирования запуска кампании обновления, когда приложение выполняет некоторую критическую задачу, до координации действий по обновлению на уровне приложения, таких как обновление схемы базы данных или развертывание новых протоколов.
Для поставщиков программного обеспечения, поставляющих приложения для развертывания в кластере SA Forum, Software Management Framework также определяет схему XML для файл типов сущностей, который описывает типы программных сущностей, реализованные приложением. Эта информация используется для создания соответствующих конфигураций развертывания.
Коммунальные услуги
Пропускной пункт
Служба контрольных точек предоставляет процессам возможность записывать пропускной пункт данные постепенно, что можно использовать для защиты приложения от сбоев. Когда процесс восстанавливается после сбоя (перезапуском или аварийное переключение процедура), службу контрольной точки можно использовать для извлечения данных с ранее установленными контрольными точками и возобновления выполнения из записанного состояния, тем самым минимизируя влияние сбоя.
Контрольно-пропускные пункты - это объекты всего кластера. Копия данных, хранящихся в контрольной точке, называется репликой контрольной точки, которая обычно хранится в основной памяти, а не на диске из соображений производительности. Контрольная точка может иметь несколько реплик контрольных точек, хранящихся на разных узлах кластера, для защиты от сбоев узлов. Процесс создания контрольной точки может выбирать между синхронной и асинхронной политиками обновления реплик. В случае асинхронной репликации можно также выбрать совместное размещение для оптимизации производительности обновления.
События
Служба событий - это механизм публикации / подписки между несколькими точками, который основан на концепции каналов событий: один или несколько издателей асинхронно обмениваются данными с одним или несколькими анонимными подписчиками, используя события по каналу событий. Каналы событий - это именованные сущности всего кластера, которые обеспечивают доставку событий с максимальной эффективностью. Издатели также могут быть подписчиками на одном и том же канале событий.
События состоят из стандартного заголовка и нуля или более байтов опубликованных данных о событии. API службы событий не требует определенного макета для опубликованных данных событий.
Когда процесс подписывается на канал событий для получения опубликованных событий, он указывает фильтры, применяемые к опубликованным событиям. События доставляются в процесс только в том случае, если они удовлетворяют предоставленным фильтрам.
Замки
Служба блокировки - это распределенная служба блокировки, который предназначен для использования в кластере, где процессы на разных узлах могут конкурировать друг с другом за доступ к общему ресурсу. Для них служба блокировки предоставляет объекты, называемые ресурсами блокировки, которые, в свою очередь, используются процессами приложений для координации доступа к этим общим ресурсам.
Служба блокировки предоставляет простую модель блокировки, поддерживающую один режим блокировки для монопольного доступа и другой для общего доступа. Блокировки, предоставляемые службой блокировки, не рекурсивны. Таким образом, заявка на одну блокировку неявно требует другой блокировки; скорее, каждая блокировка должна запрашиваться индивидуально.
Сообщения
Служба сообщений определяет API для кластерного система межпроцессного взаимодействия. Связь основана на очередях сообщений, идентифицируемых логическим именем. Любое количество процессов может отправлять сообщения в очередь сообщений, но максимум один процесс за раз может открыть ее для приема. Таким образом, одиночная очередь сообщений поддерживает точка-точка или шаблоны связи "точка-точка".
Процессы, отправляющие сообщения в очередь сообщений, не знают идентичности принимающего процесса; следовательно, процесс, который изначально получал эти сообщения, мог быть заменен другим процессом во время аварийное переключение или переключение.
Очереди сообщений можно сгруппировать в группы очередей сообщений. Группы очереди сообщений разрешают многоточечную связь. Они идентифицируются логическими именами, поэтому процесс-отправитель не знает о количестве очередей сообщений и о расположении очередей сообщений в кластере, с которым он взаимодействует. Группы очередей сообщений могут использоваться для распределения сообщений по очередям сообщений, относящихся к группе очередей сообщений. MSG определяет три одноадресная передача политики распределения - равное распределение нагрузки, локальное равное распределение нагрузки и локальная лучшая очередь - и широковещательная (многоадресная передача ) политика.
По запросу служба сообщений предоставляет различные гарантии доставки (например, подтверждение, постоянство сообщений и т. Д.) Для очередей сообщений и групп очередей одноадресных сообщений.
Именование
Служба именования предоставляет механизм, с помощью которого понятные для человека имена связываются с объектами («привязаны к»), так что эти объекты можно искать по их именам. Объекты обычно представляют точки доступа к услугам, конечные точки связи и другие ресурсы, которые предоставляют какой-либо вид обслуживания.
Служба именования не налагает ни определенного макета, ни соглашения о именах (UTF-8 предполагается кодировка) или объекты, с которыми они связаны. Это позволяет пользователям сервиса выбирать и использовать свою собственную схему именования, не предполагая какой-либо конкретной аппаратной или логической конфигурации программного обеспечения. Ожидается, что клиенты службы именования должны понимать структуру, макет и семантику привязок объектов, которые они намереваются хранить внутри и извлекать из службы.
Таймеры
Служба таймера предоставляет механизм, с помощью которого клиентские процессы могут устанавливать таймеры и получать уведомления, когда таймер истекает. Таймер - это логический объект, который создается динамически и представляет время истечения срока его действия в виде абсолютного времени или продолжительности от текущего времени.
Служба таймера предоставляет два типа таймеров: таймеры одного события и периодические таймеры. Таймеры отдельных событий истекают один раз и удаляются после уведомления. Периодические таймеры истекают каждый раз, когда достигается указанная продолжительность, и процесс уведомляется об истечении срока. Периодические таймеры должны быть явно удалены путем вызова функции удаления таймера.
Модель программирования
Все службы AIS используют одну и ту же модель программирования. В спецификации используются одни и те же соглашения об именах, стандартные предопределенные типы и константы, семантика API, управление жизненным циклом библиотеки и т. Д.
Интерфейс приложения SA Forum находится между процесс и библиотека, реализующая интерфейс. Интерфейс разработан для использования как многопоточными, так и однопоточными процессами приложений. Термин «процесс» можно рассматривать как эквивалент процесса, определенного стандартом POSIX; однако AIS не требует POSIX процесс, а скорее любой эквивалентный объект, который система предоставляет для управления исполняемым программным обеспечением.
В сервер области абстракция, представляющая сервер, который предоставляет услуги для спецификации площадь (Структура управления доступностью, служба членства в кластере, служба контрольных точек и т. Д.). Каждая область имеет отдельный сервер логической области, хотя разработчик может создать отдельный физический модуль для каждого сервера области или объединить один или несколько серверов области в один физический модуль.
Библиотеки реализации области могут быть реализованы в одной или нескольких физических библиотеках; однако требуется процесс для инициализации, регистрации и получения объекта выбора операционной системы отдельно для каждой библиотеки реализации области. Таким образом, с точки зрения программирования, полезно рассматривать их как отдельные библиотеки.
Модель использования типична для управляемой событиями архитектуры, в которой приложение выполняет настройку, а затем получает обратные вызовы при возникновении событий (рис. 6).
Использование библиотеки доступности службы начинается с вызова для инициализации библиотеки, которая потенциально загружает любой динамический код и связывает асинхронные вызовы, реализованные процессом. Когда процессу больше не требуется использование функций области, он вызывает функцию завершения области, которая отделяет процесс от экземпляра реализации области интерфейса и восстанавливает все связанные ресурсы.
AIS использует модели синхронного и асинхронного программирования. Синхронные API обычно используются для служебных интерфейсов библиотек и ассоциаций. Многие службы AIS предоставляют возможность отслеживания изменений в объектах, которые они реализуют. Отслеживание API обычно состоит из трех функций: инициирование и остановка отслеживания объекта по запросу клиента; и вызываемый службой обратный вызов для уведомления клиента о (ожидающих) изменениях отслеживаемого объекта.
Обратная совместимость
Для достижения обратной совместимости при разработке спецификации AIS следует соблюдать ряд правил:
- Определение функции или типа никогда не изменяется для конкретной версии SA Forum.
- Изменения в определении функции или типа (добавление нового аргумента к функции, добавление нового поля в структуру данных) вызывают определение новой функции или имени типа. Новое имя функции или типа создается из исходного имени в предыдущей версии с суффиксом, указывающим версию, в которой функция / тип изменились (например, saAmfComponentRegister_3 ()).
- В качестве исключения из предыдущего правила новые значения перечисления, значения флагов или поля объединения могут быть добавлены к существующему типу перечисления, флага или объединения без изменения имени типа, если размер перечисления, флага или объединения тип не меняется.
- Разработчики AIS должны гарантировать, что они соблюдают номера версий, предоставленные приложением при инициализации библиотеки, и не предоставляют новые значения перечисления приложениям, использующим более старые версии.
- Разработчики AIS должны также убедиться, что они соблюдают номера версий, предоставленные приложением при инициализации библиотеки, в отношении новых или измененных кодов ошибок и не раскрывают приложениям коды ошибок, которые применяются только к функциям в самой последней версии спецификации. написано для более старой версии спецификации.
В качестве примера рассмотрим основную версию Vx данной службы, которая включает функцию f (), и предположим, что f () пришлось изменить в более новой основной версии Vy (Vy> Vx), что привело к введению функции f_y ( ) вариант, который теперь заменяет f () в Vy.
Учитывая реализацию AIS, которая поддерживает обе версии Vx и Vy, процесс может инициализировать библиотеку, указав либо Vx, либо Vy:
- если процесс инициализирует дескриптор библиотеки с помощью Vx, этот дескриптор не предоставляет доступ к функциям, которые были введены в версиях более новых, чем Vx. В частности, этот дескриптор не позволит процессу успешно вызвать f_y ()
- если процесс инициализирует дескриптор библиотеки с помощью Vy, этот дескриптор не предоставляет доступ к функции, представленной в версиях старше Vy, а затем замененной более новым вариантом той же функции. В частности, этот дескриптор не позволит процессу успешно вызвать f ().
Обратите внимание, однако, что процесс может инициализировать библиотеку несколько раз каждый раз с версией, соответствующей функциональности, которую он намеревается получить.
Документ спецификации службы AIS для Vy включает только последний вариант определения функции или типа, поддерживаемый Vy.
Версии спецификаций: <код выпуска>. <Основная версия>. <Дополнительная версия>
Код выпуска - это заглавная буква. Обратная совместимость поддерживается только среди версий одного и того же кода выпуска. Основная и дополнительная версия - это инкрементные номера. Релизы с изменением основного номера могут вводить новые функции и изменять API обратно совместимым способом, как описано выше. Релизы с незначительным изменением номера не изменяют API. Они предоставляют своим предшественникам исправления ошибок, редакционные изменения и разъяснения.
Реестр внедрения
Реестр реализации SA Forum - это процесс, который позволяет регистрировать реализации спецификаций SA Forum и делать их общедоступными.Для регистрации реализаций членство не требуется. Реализации, которые были успешно зарегистрированы, могут называться «Форум доступности услуг зарегистрирован[постоянная мертвая ссылка ].”