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

Namespace <SI-Namespace>::proxy::methods provides the proxy-side classes for method calls of a ServiceInterface in module com of the AUTOSAR Adaptive Platform. For each ClientServerOperation, depending on the metamodel attribute ClientServerOperation.fireAndForget, either class <Method> is instantiated for regular calls or <FnFMethod> for unidirectional calls. While regular methods support server-side return values and error messages, fire-and-forget methods inherently do not process response messages. The lifetime of the method objects is likely tied directly to the existence of the parent proxy instance. Question (open)

more ›

Context

Within module com of the AUTOSAR Adaptive Platform, namespace <SI-Namespace>::proxy::methods maps the method-specific interface classes for service proxies. Depending on its configuration properties, each ClientServerOperation modeled in a ServiceInterface is mapped to a corresponding method class. The namespace essentially contains two class patterns: <Method> for operations with response behavior and <FnFMethod> for so-called fire-and-forget operations.

The primary responsibility of these classes is to accept method calls from a client application, prepare the input parameters for transport, and handle communication with the underlying middleware layer. Interaction partners are, on the caller side, the application-specific client components and, on the mediation side, the parent proxy class of namespace <SI-Namespace>::proxy, which aggregates the method instances.

The differentiation between the two classes is governed by the metamodel attribute ClientServerOperation.fireAndForget:

• <Method> is generated for operations where ClientServerOperation.fireAndForget == FALSE is configured. Presumably, an instance of this class encapsulates the asynchronous call of a service and provides the result or any application errors via a future-oriented result type. Question Q-75c8a4495ee9c1cb (open)
• <FnFMethod> is generated when ClientServerOperation.fireAndForget == TRUE is configured. A method of this class is likely implemented as a unidirectional call that does not expect a response from the server and provides no return value to the caller. Question Q-1f9698a27137b73d (open)

Lifecycle

The creation and destruction of the method classes defined in this namespace is tightly coupled to the parent proxy. The lifetime of the method objects is likely tied to the lifetime of the enclosing proxy instance in namespace <SI-Namespace>::proxy. Question Q-ec1ef4d1ebc90d5a (open) Upon instantiation of the proxy object, the associated instances of <Method> and <FnFMethod> are initialized as members and are immediately available to the application for calls.

Regarding internal state, the method objects possess permanent readiness for calls after their initialization as long as the proxy instance remains valid. State transitions of individual calls do not affect the method instance itself, but rather the individual invocation contexts. In the case of concurrent accesses from multiple threads of the client application, it must be ensured that parallel calls to the same method instance can be initiated in a thread-safe manner. Destruction occurs implicitly upon leaving the scope or upon explicit destruction of the proxy instance, cleaning up open communication resources.

Usage Path

The typical procedure for using the method classes by a client application follows a defined sequence:

1. Proxy provisioning: The application creates or obtains an initialized instance of the service proxy from namespace <SI-Namespace>::proxy.
2. Method access: The desired operation is invoked via the method members of the proxy instance that instantiate the classes <Method> or <FnFMethod>.
3. Execution of a regular operation: When invoking an instance of <Method>, the client passes the required input parameters. The invocation triggers transmission to the target system. The return object allows the application to wait for the arrival of the result or to continue working asynchronously.
4. Execution of a fire-and-forget operation: When invoking an instance of <FnFMethod>, the parameters are passed and forwarded immediately to the transmission layer. The method returns directly to the caller after handover.
5. Result processing: For regular method calls, the client evaluates the provided result and checks whether the operation completed successfully.

Error Scenarios

Error handling differs fundamentally between the two method types: For regular operations via <Method>, both transmission layer errors and specific application errors specified in the interface definition can occur. Since ClientServerOperation.fireAndForget == FALSE is configured, response messages including possible error messages are reported back from the server to the proxy. The client application can evaluate these errors via the invocation's return object and initiate suitable handling routines.

In contrast, the design of <FnFMethod> inherently excludes server-side error feedback to the caller due to ClientServerOperation.fireAndForget == TRUE. Errors occurring on the server during the processing of the operation cannot be transmitted to the proxy. Preconditions and postconditions are limited to the local invocation side: Preconditions require valid parameter values and an operational communication infrastructure. If a local error occurs during sending, it can be signaled immediately upon the method call, whereas server-side execution errors remain unnoticed by the caller.