пространство имён <SI-Namespace>::proxy

Пространство имён <SI-Namespace>::proxy предоставляет внутри модуля com клиентский интерфейс для взаимодействия с Service Interface. Его центральным компонентом является прокси-класс <SI>Proxy, который абстрагирует межплатформенное взаимодействие через промежуточное программное обеспечение и делает возможными вызовы методов, а также подписки на события. Создание экземпляра прокси, как правило, предполагает наличие действительного дескриптора (Handle), полученного в результате поиска сервиса. Вопрос (открытый) В качестве существенного граничного условия вызывающее приложение должно надёжно обрабатывать разрывы соединений и асинхронное время отклика при удалённых вызовах.

больше ›

Контекст

Пространство имён <SI-Namespace>::proxy представляет собой клиентское представление Service Interface в модуле связи com платформы AUTOSAR Adaptive Platform. Оно объединяет все артефакты и типы, необходимые потребителям сервисов для взаимодействия с сервисом, предлагаемым через коммуникационную сеть. В центре этого пространства имён находится сгенерированный прокси-класс <SI>Proxy. Этот класс абстрагирует базовую конфигурацию обмена сообщениями между процессами и сетью и предоставляет C++-интерфейс, через который прикладное программное обеспечение может вызывать методы, подписываться на события, а также опрашивать и отслеживать поля.

С точки зрения архитектуры прокси выполняет роль посредника между логикой клиентского приложения и средой выполнения Adaptive Platform. Вместо прямого взаимодействия через сеть или разделяемую память разработчик приложения взаимодействует исключительно с экземплярами из <SI-Namespace>::proxy. За счёт этого достигается разделение, позволяющее промежуточному программному обеспечению базовой платформы прозрачно управлять коммуникационными протоколами, форматами передачи данных и деталями размещения.

Жизненный цикл

Жизненный цикл объектов в пространстве имён <SI-Namespace>::proxy тесно связан с доступностью соответствующего экземпляра сервиса. Перед созданием экземпляра прокси необходимо выполнить обнаружение экземпляра. Создание экземпляра прокси <SI>Proxy, как правило, требует дескриптора (Handle), полученного в результате поиска сервиса. Вопрос Q-3dcfd734b218f865 (открытый) После успешного создания экземпляра прокси-объект представляет собой логическое соединение с соответствующим поставщиком сервиса.

Во время активной фазы работы экземпляр прокси управляет состояниями, связанными с подписками на события и ожидающими асинхронными вызовами методов. В отношении параллелизма следует учитывать, что вызовы прокси должны быть потокобезопасными или должны соответствующим образом синхронизироваться клиентом, если один и тот же прокси-объект используется несколькими потоками. Освобождение или уничтожение прокси-объекта, вероятно, прекращает привязку к найденному экземпляру сервиса и аннулирует действующие подписки. Вопрос Q-e9d55205ba1bf55b (открытый)

Путь использования

Типичный сценарий использования прокси Service Interface подразделяется на несколько последовательных фаз:

• Поиск экземпляра сервиса: клиент инициирует поиск доступных экземпляров сервиса с помощью платформенных механизмов модуля com и получает в ответ соответствующие структуры дескрипторов (Handle).
• Конструирование прокси: с использованием действительного дескриптора создаётся экземпляр <SI>Proxy, благодаря чему устанавливается канал связи с сервером.
• Взаимодействие с элементами сервиса: через экземпляр синхронно или асинхронно вызываются методы, оформляются подписки на события и регистрируются функции обратного вызова. Асинхронные шаблоны взаимодействия, предположительно, реализуются через типизированные обёртки событий и методов внутри экземпляра прокси. Вопрос Q-2e6b91c7e5f88567 (открытый)
• Завершение и очистка: после завершения взаимодействия отменяются подписки на события и экземпляр прокси корректно уничтожается для освобождения занятых ресурсов.

Сценарии ошибок

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