структура <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output

Структура объединяет все выходные аргументы метода сервисного интерфейса на стороне сервера для передачи вызывающей стороне. При выполнении skeleton-метода реализация сервиса инстанциирует эту структуру данных, заполняет её атрибуты вычисленными результатами и возвращает её в коммуникационный уровень. Затем промежуточное программное обеспечение сериализует содержащиеся параметры и передает пакет ответа вызывающему прокси-объекту. Поскольку в полезной нагрузке не зафиксировано явных требований спецификации, типы элементов, по всей видимости, напрямую соответствуют типам данных выходных параметров, смоделированным в сервисном интерфейсе. Вопрос Q-55d242e98cd76967 (открытый)

больше ›

Контекст

C++-структура <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output представляет собой сгенерированный компонент сервисной части в модуле com платформы AUTOSAR Adaptive Platform (релиз R25-11). В рамках сервисного интерфейса этот тип объединяет все выходные аргументы (out-параметры) определённого сервисного метода на стороне поставщика. Структура функционирует как уровень посредничества между конкретной реализацией сервиса поставщиком услуг и коммуникационным промежуточным программным обеспечением ara::com. Поскольку сигнатуры функций C++ обычно поддерживают только одно возвращаемое значение, данный тип предоставляет структурированный агрегат для типобезопасного возврата методов с несколькими выходными параметрами в вызывающую среду выполнения.

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

Создание экземпляра <Method>Output происходит в контексте приложения поставщика сервиса, как только сервисный метод завершает требуемые вычисления. Реализация сервиса локально инстанциирует агрегат данных, инициализирует объявленные в нём переменные-члены полученными значениями и затем передаёт экземпляр в коммуникационный уровень. С момента передачи фреймворку непосредственные права владения со стороны прикладной реализации метода прекращаются; объект переходит в зону ответственности промежуточного ПО. Время жизни экземпляра является транзиентным и заканчивается, как только коммуникационный уровень сериализует содержащиеся параметры в нижележащие полезные нагрузки протокола и освободит буфер. С точки зрения параллелизма каждый вызов метода изолирован: каждый контекст вызова оперирует собственным экземпляром, поэтому механизмы синхронизации на уровне классов не требуются, пока передаваемые значения не разделяют незащищённые общие ресурсы.

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

Типичный процесс при использовании <Method>Output протекает в фиксированной последовательности взаимодействий между средой выполнения, реализацией skeleton-метода и выходной структурой. После поступления запроса к методу промежуточное ПО перенаправляет вызов реализованному skeleton-классу. Прикладная логика выполняет обработку, создаёт структуру <Method>Output и заполняет все выходные параметры. Затем экземпляр передаётся в систему времени выполнения, которая выполняет сериализацию и отправляет ответное сообщение по сети запрашивающему прокси-объекту.

Диаграмма последовательности: путь вызова и возврата при использовании структуры Output в Skeleton. Источники: подтверждающие документы в полезной нагрузке не указаны.

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

Являясь чистым агрегатом данных, <Method>Output не имеет собственных процедур обработки ошибок или методов состояния. Ошибочные состояния возникают преимущественно на интерфейсах из-за неполной инициализации или нарушения предусловий. Если прикладная реализация не сможет корректно заполнить отдельные переменные-члены перед возвратом, могут быть сериализованы неинициализированные значения или нулевые состояния. Если бизнес-вычисление сервисного метода завершается сбоем ещё на предварительном этапе, в регулярном потоке управления действительный экземпляр <Method>Output не передаётся; вместо этого реализация сообщает о возникшей ошибке через предусмотренные для этого каналы ошибок сервисного интерфейса. Если в динамических структурах данных внутри выходных аргументов возникают ошибки выделения памяти, их необходимо перехватывать внутри вызываемого метода до передачи в промежуточное ПО.