namespace <SI-Namespace>::proxy

Within module com, the namespace <SI-Namespace>::proxy provides the client-side interface for interacting with a Service Interface. Its central component is the proxy class <SI>Proxy, which abstracts middleware communication and enables method calls as well as event subscriptions. Instantiating the proxy is likely to typically require a valid handle from the service discovery. Question (open) As an essential constraint, the calling application must robustly handle connection interruptions and asynchronous response times for remote calls.

more ›

Context

Within the communication module com of the AUTOSAR Adaptive Platform, the namespace <SI-Namespace>::proxy represents the client-side representation of a Service Interface. It bundles all artifacts and types required by service consumers to interact with a service offered via the communication network. At the core of this namespace is the generated proxy class <SI>Proxy. This class abstracts the underlying message-based inter-process and network configuration and provides a C++ interface through which application software can invoke methods, subscribe to events, and query and monitor fields.

Architecturally, the proxy acts as an intermediary between the application-specific client logic and the runtime environment of the Adaptive Platform. Instead of direct network or shared-memory interactions, the application developer interacts exclusively with the instances from <SI-Namespace>::proxy. This achieves a decoupling that allows communication protocols, data transfer formats, and location details to be handled transparently by the underlying platform middleware.

Lifecycle

The lifecycle of objects in namespace <SI-Namespace>::proxy is closely coupled to the availability of the corresponding service instance. Before a proxy instance can be created, instance discovery must take place. Instantiation of the proxy <SI>Proxy is likely to typically require a handle resulting from the service discovery. Question Q-3dcfd734b218f865 (open) After successful instantiation, the proxy object represents a logical connection to the respective service provider.

During the active operational phase, the proxy instance manages the states regarding subscribed events and pending asynchronous method invocations. With regard to concurrency, it must be noted that calls to the proxy must be designed to be thread-safe or must be synchronized accordingly by the client if multiple threads use the same proxy object. Releasing or destroying the proxy object is likely to terminate the binding to the discovered service instance and resolve active subscriptions. Question Q-e9d55205ba1bf55b (open)

Usage Path

A typical usage path for using the Service Interface proxy is divided into several successive phases:

• Finding the service instance: Via the platform mechanisms of module com, the client initiates a search for available instances of the service and receives corresponding handle structures in return.
• Constructing the proxy: Using a valid handle, an instance of <SI>Proxy is instantiated, thereby establishing the communication channel to the server.
• Interacting with service elements: Via the instance, methods are invoked synchronously or asynchronously, events are subscribed to, and callbacks are registered. Asynchronous communication patterns are likely mapped via typed event and method wrappers within the proxy instance. Question Q-2e6b91c7e5f88567 (open)
• Termination and cleanup: After communication is complete, events are unsubscribed and the proxy instance is properly destroyed in order to release allocated resources.

Error Scenarios

Various error patterns can occur during interaction with the proxy namespace. These include connection losses to the server, timeouts during remote calls, and the unavailability of requested service instances during initialization. Since communication takes place across process and machine boundaries, infrastructural errors or failures of the peer are reflected in the return values. Calls prior to successful binding or after destruction of the instance lead to invalid states, which is why preconditions regarding the validity of the handle must be strictly observed.