namespace <SI-Namespace>::proxy::methods

El espacio de nombres <SI-Namespace>::proxy::methods proporciona las clases del lado del proxy para llamadas a métodos de un ServiceInterface en el módulo com de AUTOSAR Adaptive Platform. Para cada ClientServerOperation se instancia, en función del atributo del metamodelo ClientServerOperation.fireAndForget, bien la clase <Method> para llamadas regulares, bien <FnFMethod> para llamadas unidireccionales. Mientras que los métodos regulares admiten valores devueltos por el servidor y mensajes de error, los métodos fire-and-forget, por diseño, no procesan mensajes de respuesta. La vida útil de los objetos de método suele estar directamente ligada a la existencia de la instancia de proxy de nivel superior. Pregunta (abierta)

más ›

Contexto

Dentro del módulo com de AUTOSAR Adaptive Platform, el espacio de nombres <SI-Namespace>::proxy::methods reproduce las clases de interfaz específicas de métodos para proxies de servicio. Cada ClientServerOperation modelado en un ServiceInterface se asigna a una clase de método correspondiente en función de sus propiedades de configuración. El espacio de nombres contiene fundamentalmente dos patrones de clases: <Method> para operaciones con comportamiento de respuesta y <FnFMethod> para las denominadas operaciones fire-and-forget.

La responsabilidad principal de estas clases consiste en recibir las llamadas a métodos de una aplicación cliente, preparar los parámetros de transferencia para el transporte y gestionar la comunicación con la capa de middleware subyacente. Los interlocutores son, en el lado del llamante, los componentes cliente específicos de la aplicación y, en el lado de la mediación, la clase proxy de nivel superior del espacio de nombres <SI-Namespace>::proxy, que agrega las instancias de método.

La diferenciación de ambas clases se rige por el atributo del metamodelo ClientServerOperation.fireAndForget:

• <Method> se genera para operaciones en las que está configurado ClientServerOperation.fireAndForget == FALSE. Presumiblemente, una instancia de esta clase encapsula la llamada asíncrona a un servicio y pone a disposición el resultado o posibles errores de aplicación a través de un tipo de resultado orientado al futuro. Pregunta Q-75c8a4495ee9c1cb (abierta)
• <FnFMethod> se genera cuando está configurado ClientServerOperation.fireAndForget == TRUE. Es probable que un método de esta clase esté implementado como una llamada unidireccional que no espera respuesta del servidor y no devuelve ningún valor al llamante. Pregunta Q-1f9698a27137b73d (abierta)

Ciclo de vida

La creación y destrucción de las clases de métodos definidas en este espacio de nombres está estrechamente ligada al proxy de nivel superior. La vida útil de los objetos de método suele estar vinculada a la vida útil de la instancia de proxy envolvente en el espacio de nombres <SI-Namespace>::proxy. Pregunta Q-ec1ef4d1ebc90d5a (abierta) Al instanciar el objeto proxy, las instancias correspondientes de <Method> y <FnFMethod> se inicializan como miembros y quedan disponibles de inmediato para las llamadas de la aplicación.

En cuanto al estado interno, los objetos de método disponen de una disponibilidad de invocación permanente tras su inicialización, siempre que la instancia de proxy siga siendo válida. Las transiciones de estado de invocaciones individuales no afectan a la propia instancia de método, sino a los contextos de invocación individuales. En caso de accesos concurrentes desde múltiples hilos de la aplicación cliente, debe garantizarse que las invocaciones paralelas a la misma instancia de método puedan iniciarse de forma segura para hilos. La destrucción tiene lugar de manera implícita al salir del ámbito de validez o mediante la destrucción explícita de la instancia de proxy, depurándose los recursos de comunicación abiertos.

Ruta de uso

El flujo típico al utilizar las clases de método por parte de una aplicación cliente sigue una secuencia establecida:

1. Disponibilidad del proxy: la aplicación crea u obtiene una instancia inicializada del service proxy desde el espacio de nombres <SI-Namespace>::proxy.
2. Acceso a métodos: la invocación de la operación deseada se realiza a través de los miembros de método de la instancia de proxy, los cuales instancian las clases <Method> o <FnFMethod>.
3. Ejecución de una operación regular: al invocar una instancia de <Method>, el cliente transfiere los parámetros de entrada requeridos. La invocación inicia la transmisión al sistema de destino. El objeto de retorno permite a la aplicación esperar la llegada del resultado o continuar trabajando de forma asíncrona.
4. Ejecución de una operación Fire-and-Forget: al invocar una instancia de <FnFMethod>, los parámetros se transfieren y se transmiten inmediatamente para su reenvío a la capa de transporte. El método regresa al invocador directamente después de la entrega.
5. Procesamiento del resultado: en las invocaciones a métodos regulares, el cliente evalúa el resultado proporcionado y comprueba si la operación finalizó con éxito.

Escenarios de error

El tratamiento de errores difiere fundamentalmente entre ambos tipos de método: en operaciones regulares mediante <Method> pueden producirse tanto errores de la capa de transporte como errores de aplicación específicos definidos en la definición de la interfaz. Dado que ClientServerOperation.fireAndForget == FALSE está configurado, los mensajes de respuesta, incluidos los posibles mensajes de error, se devuelven del servidor al proxy. La aplicación cliente puede evaluar estos errores a través del objeto de retorno de la invocación e iniciar las rutinas de tratamiento adecuadas.

Por el contrario, el diseño de <FnFMethod> mediante ClientServerOperation.fireAndForget == TRUE excluye por principio una notificación de error al invocador desde el lado del servidor. Los errores que se producen en el servidor durante el procesamiento de la operación no se pueden transmitir al proxy. Las precondiciones y postcondiciones se limitan al lado local de la invocación: las precondiciones requieren valores de parámetros válidos y una infraestructura de comunicación operativa. Si se produce un error local durante el envío, este puede señalizarse directamente en la invocación del método, mientras que los errores de ejecución del lado del servidor pasan desapercibidos para el invocador.