path: root/docx/CommonAPISpecification

:website: http://projects.genivi.org/commonapi/
:version:
:toc:
:imagedir:
:cppstr: c++

CommonAPI C++ Specification          
===========================

This is the specification for *Common API {version}* released at {revdate}.

.Copyright and License
*******************************************************************************
Copyright (C) 2013, GENIVI Alliance, Inc.
Copyright (C) 2013, BMW AG

This file is part of the GENIVI IPC Common API C++i project.

Contributions are licensed to the GENIVI Alliance under one or more
Contribution License Agreements or MPL 2.0.
*******************************************************************************

IPC Common API is a C++ abstraction framework for *Interprocess Communication* (IPC).
It is supposed to be neutral to IPC implementations and therefore can be used with any
kind of IPC mechanism if a middleware specific _IPC Common API binding_ is provided.

IPC Common API allows applications (i.e., clients and servers using C++) developed
against IPC Common API to be linked with different IPC Common API _backends_ without
any changes to the application code.
Thus, components which have been developed for a system which uses specific IPC X could
be deployed for another system which uses IPC Y easily - just by exchanging the
IPC Common API backend without recompiling the application code.
The actual interface definitions will be created using
http://code.google.com/a/eclipselabs.org/p/franca/[Franca IDL], which is the
Common IDL solution favored by http://www.genivi.org/[GENIVI].

IPC Common API is not restricted to GENIVI members
(see https://www.genivi.org/sites/default/files/genivi_public_newsletter_October_2013_liquid.html#LIC[public GENIVI licensing policy]).
It is available as open source code, which is split into runtime code for the target
system and code generation tooling (see http://projects.genivi.org/) to be used on
development systems.

.This document
********************************************************************************
This document originates from the GENIVI Wiki and was the result of
some work of the IPC subdomain as part of the GENIVI System Infrastructure Expert Group.

If you're new to IPC Common API please read the introduction of this document and
the IPC Common API Tutorial available at the
http://git.projects.genivi.org/?p=ipc/common-api-tools.git;a=summary[CommonAPI-Tools repository].
********************************************************************************

General Design
--------------

Basic Assumptions
~~~~~~~~~~~~~~~~~

- The applications use the client-server communication paradigm.
- The C++ API is based on the common interface description language Franca IDL which provides the possibility to specify interfaces independent from the platform, middleware or programming language. That means that the application specific part of the API is generated via a code generator from a Franca IDL specification file (see figure 1).
- CommonAPI specifies only an API and not an concrete IPC mechanism. It can only be used with a language binding that has to be developed for a special middleware.
- In principle, the CommonAPI should be platform independent. However, this is without any restrictions very difficult to realize. Therefore it is agreed that CommonAPI attempts to use only features supported from the gnu C++ compiler version \<= 4.4.2. Please find supported ((compiler)) and compiler versions in the NEWS file of the CommonAPI distribution.

.Code Generation from Franca IDL
image::{imagedir}/CodeGenerationFrancaIDL.png[Code Generation image]

Deployment
~~~~~~~~~~

One problem with definition of a middleware-independent C++ API is that depending on the middleware different configuration parameters for parts of the API could be necessary. Examples:

- QoS parameter
- Maximum length of arrays or strings
- Endianness of data
- Priorities

The Franca IDL offers the possibility to specify these kind of parameters which depend on the used middleware in a middleware-specific or platform-specific deployment model (*.depl file). The deployment parameters can be specified arbitrarily.

But as indicated above it is an explicit goal that an application written against CommonAPI can be linked against different CommonAPI IPC backends without any changes to the application code. This goal brings an important implicit restriction:

[NOTE]
The interface defined in Franca IDL is the only information that should be used to generate the CommonAPI headers that define the implementation API. Deployment models that are specific to the IPC backend must not affect the generated API. But a non specific deployment model is allowed.

.Deployment Concept
image::{imagedir}/Deployment.png[Deployment image]

Basic Parts of CommonAPI
~~~~~~~~~~~~~~~~~~~~~~~~

CommonAPI can be divided up into two parts:

- The first part (Franca based part, generated by the CommonAPI code generator) refers to the variable (generated) part of the logical interface. That is the part of the interface which depends on the specifications in the Franca IDL file (data types, arrays, enumerations and interface basics as attributes, methods, callbacks, error handling, broadcast).
- The second fixed part (CommonAPI Runtime features) which is mainly independent from the interface specifications. It refers to the CommonAPI library functions as service discovery, connect/disconnect, and address handling which relate primarily to the runtime environment provided by the underlying middleware. Furthermore this part contains common type definitions and base classes.

Franca based part
-----------------

Namespaces
~~~~~~~~~~

The *namespace* of the CommonAPI base functions is CommonAPI; the ((namespace)) of a CommonAPI application depends on the the qualified package name of the interface specification.

[cols="<50%asciidoc,<50%asciidoc",frame="none",grid="none"]
|====
|.FrancaIDL
[source,java]
----
package example.user
----
|.CommonAPI C++
[source,{cppstr}]
----
namespace example {
namespace user {

}
}
----
|====

Data Types
~~~~~~~~~~

Primitive Types
^^^^^^^^^^^^^^^

The integer data types used by Common API are defined in +stdint.h+.

.Mapping Of Franca Primitive Types With CommonAPI C++ Types
[width="100%",cols="3,5,8",options="header"]
|=========================================================
|Franca Type Name |CommonAPI C++ Type |Notes

|+UInt8+ |+uint8_t+ |
unsigned 8-bit integer (range 0..255).

|+Int8+ |+int8_t+ |
signed 8-bit integer (range -128..127).

|+UInt16+ |+uint16_t+ |
unsigned 16-bit integer (range 0..65535).

|+Int16+ |+int16_t+ |
signed 16-bit integer (range -32768..32767).

|+UInt32+ |+uint32_t+ |
unsigned 32-bit integer (range 0..4294967295).

|+Int32+ |+int32_t+ |
signed 32-bit integer (range -2147483648..2147483647).

|+UInt64+ |+uint64_t+ |
unsigned 64-bit integer.

|+Int64+ |+int64_t+ |
signed 64-bit integer.

|+Boolean+ |+bool+ |
boolean value, which can take one of two values: false or true.

|+Float+ |+float+ |
floating point number (4 bytes, range +/- 3.4e +/- 38, ~7 digits).

|+Double+ |+double+ |
double precision floating point number (8 bytes, range +/- 1.7e +/- 308, ~15 digits).

|+String+ |+std::string+ |
character string.

|+ByteBuffer+ |+std::vector<uint8_t>+ |
buffer of bytes (aka BLOB).
|=========================================================

Franca has only one string data type, and if necessary the wire format / ((encoding)) can be specified via deployment model. The Proxies always expect and deliver *UTF-8*.

Arrays
^^^^^^

Franca ((array)) types (in explicit and implicit notation) are mapped to +std::vector<T>+. While explicitly defined array types will be made available as typedef with the name as it was given in Franca IDL, the implicit version will just be generated as +std::vector<T>+ wherever needed.

Structures
^^^^^^^^^^

Franca struct types are mapped to C++ struct types.

.FrancaIDL
[source,java]
----
struct TestStruct {
	UInt16 uintValue
	String stringValue
}
----

.CommonAPI C++
[source,{cppstr}]
----
struct TestStruct: CommonAPI::SerializableStruct {
	TestStruct() = default;
	TestStruct(const uint16_t& uintValue, const std::string& stringValue);

	virtual void readFromInputStream(CommonAPI::InputStream& inputStream);
	virtual void writeToOutputStream(CommonAPI::OutputStream& outputStream) const;

	uint16_t uintValue;
	std::string stringValue;
};
----

One problem is the possibility to inherit structures in Franca IDL. This feature can be mapped 1:1 to C\++ inheritance for structs. Due to the limitations of the C\++ language, we can make use of the C\++ virtual methods to guarantee proper serialization of derived struct types. For that we define +InputStream+ and +OutputStream+ classes which are part of the CommonAPI library. Each basic struct (the topmost parent in inheritance) must derive from +SerializableStruct+ which is also defined within the CommonAPI library. This will force each struct to implement two virtual methods: +readFromInputStream()+ and +writeToOutputStream()+.

The CommonAPI library also defines the two input and output stream operators on +SerializableStruct+: +operator<<()+ and +operator>>()+, whose purpose is to signal the +InputStream+ and +OutputStream+ implementations that a struct is about to be serialized, and call the internal +readFromInputStream()+ or +writeToOutputStream()+ methods. The latter are CommonAPI specific and must not be accessible from the application or the individual bindings to avoid confusion. A typical application will create a struct instance, fill in the values and call a proxy method with the struct instance. The proxy method will be dispatched to the apropriate binding, which will eventually serialize the struct using the stream operators. This will result in calling the binding specific +InputStream+ or +OutputStream+ implementations through SerializableStruct's virtual methods +readFromInputStream()+ or +writeToOutputStream()+.

Enumerations
^^^^^^^^^^^^

Franca ((enumerations)) will be mapped to C++ strongly typed enums. Enum backing datatype and wire format by default is +uint32_t+. If needed, the wire format can be specified via deployment model, but proxy only delivers and expects the default.

.FrancaIDL
[source,java]
----
enumeration MyEnum {
	E_UNKNOWN = "0x00"
}

enumeration MyEnumExtended extends MyEnum {
	E_NEW = "0x01"
}
----

.CommonAPI C++
[source,{cppstr}]
----
enum class MyEnum: int32_t {
	E_UNKNOWN = 0 };

// Definition of a comparator is necessary for GCC 4.4.1
// Topic is fixed since 4.5.1
struct MyEnumComparator;

enum class MyEnumExtended: int32_t {
	E_UNKNOWN = MyEnum::E_UNKNOWN,
	E_NEW = 1
};
----

[NOTE]
To enable comparisons between enumerations in an inheritance hierarchy comparators have to be generated for the C\++ types, as C++ does not support enum-inheritance natively.

Maps
^^^^

For efficiency reasons the CommonAPI data type for Franca ((maps)) is +std::unordered_map<K,V>+.

[cols="<30%asciidoc,<70%asciidoc",frame="none",grid="none"]
|====
|[source,java]
.FrancaIDL
----
map MyMap {
	UInt32 to String
}
----
|[source,{cppstr}]
.CommonAPI C++
----
typedef std::unordered_map<uint32_t, std::string> MyMap;
----
|====

Unions
^^^^^^

Franca ((union)) types are implemented as a typedef of CommonAPI generic templated C++ variant class.

[cols="<40%asciidoc,<60%asciidoc",frame="none",grid="none"]
|====
|[source,java]
.FrancaIDL
----
union MyUnion {
	UInt32 MyUInt
	String MyString
}
----
|[source,{cppstr}]
.CommonAPI C++
----
typedef Variant<uint32_t, std::string> MyUnion;
----
|====

This uses a variadic template to define the possible options, and implements operators in the expected fashion.

Assignment works by constructor or assignment operator:
----
MyUnion union = 5;
MyUnion stringUnion("my String");
----

Getting the contained value is done via a get method templated to the type desired for type safety. This results in a compile error if an impossible type is attempted to be fetched. In case of fetching a type which can be contained but is not an exception is thrown. The choice of an exception at this point is made for the following reasons:

- Returning pointers is inconvenient, especially in case of primitives.
- Returning a temporary reference in case of failure is dangerous due to potential for segmentation faults in case of accidental use.
- Returning a null heap object will be a memory leak if not deleted by the user.

----
MyUnion union = 5;
int a = union.get<uint32_t>(); //Works!
std::string b = union.get<std::string>(); //Throws exception
----

Also available is an templated isType method to test for the contained type:

----
MyUnion union = 5;
bool contained = union.isType<uint32_t>(); //True!
contained = union.isType<std::string>(); //False!
----

[NOTE]
To enable comparisons between variants in an inheritance hierarchy comparators have to be generated for the C\++ types, as C++ as all ((variants)) are instances of the same generic class.

Type Aliases
^^^^^^^^^^^^

Franca typedefs are mapped to C++ typedef.

Type Collections
^^^^^^^^^^^^^^^^

In Franca a set of user-defined types can be defined as _type collection_. The name of the type collection, referred to as _typecollectionname_, can be empty. CommonAPI uses for empty type collection the default name _AnonymousTypeCollection_.

The CommonAPI code generator generates the header file +typecollectionname.h+ and creates an own namespace for the type collection.

[source,java]
.FrancaIDL
----
package commonapi.examples

typeCollection {
// type definitions here
}
----

[source,{cppstr}]
.CommonAPI C++
----
namespace commonapi {
namespace examples {
namespace AnonymousTypeCollection {

static inline const char* getTypeCollectionName() {
	static const char* typeCollectionName = "commonapi.examples.AnonymousTypeCollection";
	return typeCollectionName;
}

} // namespace AnonymousTypeCollection
} // namespace examples
} // namespace commonapi
----

Interfaces
~~~~~~~~~~

Basics
^^^^^^

For the Franca interface name, referred to as _interfacename_, a class name is generated which provides the methods +getInterfaceName+ and +getInterfaceVersion+. The ((version)) is mapped to a struct +CommonAPI::Version+.

[NOTE]
Specifying a version is mandatory for CommonAPI.

[source,java]
.FrancaIDL
----
package commonapi.examples

interface ExampleInterface {
	version { major 1 minor 0 }
}
----

[source,{cppstr}]
.CommonAPI C++
----
namespace commonapi {
namespace examples {

class ExampleInterface {
 public:
	virtual ~ExampleInterface() { }

	static inline const char* getInterfaceId();
	static inline CommonAPI::Version getInterfaceVersion();
};

const char* ExampleInterface::getInterfaceId() {
	static const char* interfaceId = "commonapi.examples.ExampleInterface";
	return interfaceId;
}

CommonAPI::Version ExampleInterface::getInterfaceVersion() {
	return CommonAPI::Version(1, 0);
}

} // namespace examples
} // namespace commonapi
----

The specification of the version structure is part of the namespace CommonAPI:
[source,{cppstr}]
----
struct Version {
	Version() = default;

	Version(const uint32_t& majorValue, const uint32_t& minorValue):
		Major(majorValue),
		Minor(minorValue) {}

	uint32_t Major;
	uint32_t Minor;
};
----

As described above it is a basic assumption that the applications use the client-server communication paradigm. That means that the CommonAPI code generator generates stub code for the server implementation and proxy code for the client implementation.

At least the following files are generated:

.Generated files of the CommmonAPI code generator for the example interface +ExampleInterface+
[width="80%",cols="2,1"]
|=========================================================
|ExampleInterface.h | Common header file for client and service

|ExampleInterfaceProxy.h | proxy class

|ExampleInterfaceProxyBase.h | base class for proxy

|ExampleInterfaceStub.h | stub

|ExampleInterfaceStubDefault.cpp | stub default implementation

|ExampleInterfaceStubDefault.h | stub default header

|=========================================================

The following picture shows the relationships between the proxy classes.

.Proxy Classes
image::{imagedir}/Diag_GeneratedProxy.png[Proxy image]

On stub side it looks like this.

.Stub Classes
image::{imagedir}/Diag_GeneratedStub.png[Stub image]

Methods
^^^^^^^

Franca IDL supports the definition of ((methods)) and ((broadcasts)). Methods can have several in and out parameters; if an additional flag ((fireAndForget)) is specified, no out parameters are permitted. Broadcasts can have only out parameters. Methods without the +fireAndForget+ flag can return an error which can be specified in Franca IDL as an enumeration. For broadcasts an additional flag +selective+ can be defined. This flag indicates that the message should not be sent to all registered participants but that the service makes a selection.

[NOTE]
- In Franca IDL there is no difference between an asynchronous or synchronous call of methods; the CommonAPI will provide both. The user of the API can decide which variant he calls.
- The CommonAPI does not provide the possibility to cancel asynchronous calls.

For methods without the +fireAndForget+ flag an additional return value ((CallStatus)) is provided which is defined as enumeration:

[source,{cppstr}]
----
enum class CallStatus {
	SUCCESS,
	OUT_OF_MEMORY,
	NOT_AVAILABLE,
	CONNECTION_FAILED,
	REMOTE_ERROR
};
----

The +CallStatus+ defines the transport layer result of the call, i.e. it returns:

- SUCCESS, if the remote call returned successfully.
- OUT_OF_MEMORY, if sending the call or receiving the reply could not be completed due of a lack of memory.
- NOT_AVAILABLE, if the corresponding service for the remote method call is not available.
- CONNECTION_FAILED, if there is no connection to the communication medium available.
- REMOTE_ERROR, if the sent remote call does not return (in time). *NOT* considered to be a remote error is an application level error that is defined in the corresponding Franca interface, because from the point of view of the transport layer the service still returned a valid answer. It *IS* considered to be a remote error if no answer for a sent remote method call is returned within a defined time. It is discouraged to allow the sending of any method calls without a defined timeout. This timeout may be middleware specific. This timeout may also be configurable by means of a Franca Deployment Model. It is *NOT* configurable at runtime by means of the Common API.

For the return parameters a function object is created which is passed to the asynchronous method call. This function object can then be used directly in the client application as function pointer to a callback function or be bound to a function with a different signature. The usage of +std::bind+ is not enforced but must be possible. The bound callback function object will be called in any case:

- If the call returns successfully: Once the remote method call successfully returns, the callback function object is called with SUCCESS for its CallStatus and any received parameters.
- If a transport layer error occurs: If an error occurs that would trigger the method to return anything other but SUCCESS for its CallStatus, the callback has to be called with the corresponding CallStatus value. All other values that are input to the callback may remain unitialized in this case.

The asynchronous call returns the CallStatus as ((future)) object. This allows the synchronization of asynchronous calls to a defined time. The future object will attain its value at the same time at which the callback function object is called.

The following example shows the signatures of the generated functions. First, the Franca IDL example:

[source,java]
----
package commonapi.examples

interface ExampleInterface {

	version { major 1 minor 0 }

	method getProperty {
		in {
		UInt32 ID
	}
	out {
		String Property
	}
	error {
		OK
		NOT_OK
	}
	}

	method newMessage fireAndForget {
	in {
		String MessageName
	}
	}

	broadcast signalChanged {
	out {
		UInt32 NewValue
	}
	}

	broadcast signalSpecial selective {
	out {
		UInt32 MyValue
	}
	}
}
----

See the generated function calls for the methods _getProperty_ and _newMessage_ on *proxy side*:

[source,{cppstr}]
----
/* Calls getProperty with synchronous semantics. */
virtual void getProperty(const uint32_t& ID, CommonAPI::CallStatus& callStatus, ExampleInterface::getPropertyError& methodError, std::string& Property);

/* Calls getProperty with asynchronous semantics. */
virtual std::future<CommonAPI::CallStatus> getPropertyAsync(const uint32_t& ID, GetPropertyAsyncCallback callback);

/* Calls newMessage with Fire&Forget semantics. */
virtual void newMessage(const std::string& MessageName, CommonAPI::CallStatus& callStatus);
----

- All const parameters are input parameters.
- All non-const parameters will be filled with the returned values.
- The CallStatus will be filled when the methods return and indicate either +SUCCESS+ or which type of error has occurred. In case of an error, *ONLY* the CallStatus will be set.
- The provided callback of the asynchronous call will be called when the reply to this call arrives or an error occurs during the call. The +std::future+ returned by this method will be fulfilled at arrival of the reply. It will provide the same value for CallStatus as will be handed to the callback.

On *stub side* the generated functions are part of the default stub (+ExampleInterfaceStubDefault.h+):

[source,{cppstr}]
----
virtual void getProperty(const std::shared_ptr<CommonAPI::ClientId> clientId, uint32_t ID, ExampleInterface::getPropertyError& methodError, std::string& Property);
virtual void newMessage(const std::shared_ptr<CommonAPI::ClientId> clientId, std::string MessageName);
----

Note that it makes on the stub side no difference whether the function call was synchronous or asynchronous.

On stub side the additional parameter of type _ClientId_ is passed. The _ClientId_ identifies a client sending a call to a stub. It is used to identify the caller within a stub and is supposed to be added by the middleware and can be compared using the == operator. The ClientId class is declared as:

[source,{cppstr}]
----
class ClientId {
public:
	virtual ~ClientId() { }
	virtual bool operator==(ClientId& clientIdToCompare) = 0;
	virtual std::size_t hashCode() = 0;
};
----

The pure virtual methods operator==() and hascode() have to be implemented by the middleware specific binding. Note that the value of the ClientId itself is irrelevant for CommonAPI. As API only the comparison operator is offered; the middleware specific identifier could be of any size as long as it is unique. The method hascode() is there so that the ClientId can be used as key in a hashmap.

If we now consider the broadcast methods the generated functions on *proxy side* are:

[source,{cppstr}]
----
virtual SignalChangedEvent& getSignalChangedEvent() {
	return delegate_->getSignalChangedEvent();
}

virtual SignalSpecialSelectiveEvent& getSignalSpecialSelectiveEvent() {
	return delegate_->getSignalSpecialSelectiveEvent();
}
----

These methods return a wrapper class for an event that provides access to the broadcast +signalChanged+ (see below in this specification the CommonAPI definition of events). The wrapper class provides the methods subscribe and unsubscribe. The private property +delegate_+ is used for forwarding the function call to the specific binding.

The generated stub provides methods to fire the broadcasts and some hooks:

[source,{cppstr}]
----
virtual void fireSignalChangedEvent(const uint32_t& NewValue);
virtual void fireSignalSpecialSelective(const uint32_t& MyValue, const std::shared_ptr<CommonAPI::ClientIdList> receivers = NULL);
virtual std::shared_ptr<CommonAPI::ClientIdList> const getSubscribersForSignalSpecialSelective();

/* Hook method for reacting on new subscriptions or removed subscriptions respectively for selective broadcasts. */
virtual void onSignalSpecialSelectiveSubscriptionChanged(const std::shared_ptr<CommonAPI::ClientId> clientId, const CommonAPI::SelectiveBroadcastSubscriptionEvent event);
/* Hook method for reacting accepting or denying new subscriptions */
virtual bool onSignalSpecialSelectiveSubscriptionRequested(const std::shared_ptr<CommonAPI::ClientId> clientId);
----

Note that the Franca keyword _selective_ is implemented only on stub side by using the _ClientId_ and the provided hooks.

[NOTE]
The _ClientId_ can be generated only on the stub side due to middleware specific data that can be composed entirely arbitrary.

Attributes
^^^^^^^^^^

An attribute of an interface is defined by name and type. Additionally the specification of an attribute can have two flags:

- +noSubscriptions+
- +readonly+

CommonAPI provides a basic implementation of the attribute interface and a mechanism for so-called ((extensions)). The basic implementation is shown in the example below. There are four possible combinations of flags:

- standard attributes with no additional flag.
- readonly attributes (readonly flag is set).
- non observable attributes (noSubscription flag).
- and non observable and non writable attributes (both flags are set).

Attributes which are non readable but only writable are not supported by Franca IDL and CommonAPI.

Template classes for each of those four types of attributes are defined in the header file Attribute.h. The CommonAPI provides a getter function which returns a reference to an instance of the appropriate attribute template class.

.Attributes
image::{imagedir}/Diag_Attributes.png[Attribute image]

Observable attributes provide a ChangedEvent which can be used to subscribe to updates to the attribute. This Event works exactly as all other events (see description below). By default, the attributes are not cached in client side. Creating a cache on client side is not an implementation-specific detail that should be a part of the logical interface specification, nor is it a platform- or middleware-dependent parameter. Moreover, the requirements for an attribute cache can be very different depending on the application specific use case. Differences in points of view include, but are not limited to:

- Is the cache value to be updated on any value changed event or is it to be updated periodically?
- Should calls to getters of potentially cached values be blocking or non-blocking?
- Should caching be configurable per attribute or per proxy, or should caching always be enabled?
- Is getting a cached value a distinct method call or is it to be included transparently within the standard getter methods?

Because of this, there is a general scheme to include individual extensions in order to provide any additional features for attributes (Attribute Extensions). This would prevent an exponential growth of configuration possibilities within the Common API and also relieve Common API developers from the necessity to always implement all specified features for their specific middleware, regardless of whether the feature is supported by the middleware or not. On the other hand, it gives complete freedom to application developers to add an implementation for their specific needs to attribute handling.

The basic principle is that the user of the API has to implement an extension class that is derived from the base class +AttributeExtension+. The +AttributeExtension+ is packed in a wrapper class which in turn is generated for each attribute the Proxy has. A wrapper for a given attribute only then is mixed into the proxy if an extension for this given attribute is defined during construction time. The wrapper forwards the correct attribute to the constructor of the extension, so that the extension sees nothing but the attribute it should extend. Wrappers are written as templates, so that all wrappers can be reused for all attributes of the same category. As soon as an extension for an attribute is defined during construction time, the extension class will be instantiated and a method to retrieve the extended attribute will be added to the proxy.

Such an solution requires the proxy to be made ready for mixins. The proxy inherits from all mixins that are defined during construction time, so that their interface is added directly to the proxy itself. The interface that would be added to the proxies in our case would be the interface of the defined attribute extension wrappers, which in turn provide access to the actual attribute extensions. By using variadic templates the amount of possible mixins is arbitrary.

[NOTE]
Because a given proxy may not inherit from the same class twice, only one extension per attribute per proxy is possible.

The base class for extensions is defined in +AttributeExtension.h+.

The CommonAPI for attributes on *stub side* looks like this when we only consider the attribute +A+:

[source,{cppstr}]
----
 public:
	virtual const uint32_t& getAAttribute(const std::shared_ptr<CommonAPI::ClientId> clientId);
	virtual void setAAttribute(const std::shared_ptr<CommonAPI::ClientId> clientId, uint32_t value);

 protected:
	virtual bool trySetAAttribute(uint32_t value);
	virtual bool validateAAttributeRequestedValue(const uint32_t& value);
	virtual void onRemoteAAttributeChanged();
----

The attribue +A+ is stored in the default implementation of the stub class as private member and via CommonAPI accessible by calling the corresponding get function. CommonAPI defines furthermore three callbacks to handle remote set events related to the attributes defined in the IDL description for ExampleInterface.

- The first, +validate<AttributeName>RequestedValue+, allows for verification of the attribute value before it actually is set. This callback receives the new requested value and should return true if the operation is possible or false if the operation cannot be completed at all. In the default case, this callback will return true.
- The second, +trySet<AttributeName>Attribute+, setting and modification of the attribute value. This callback receives the new requested value as a reference and modifies this as needed. Additionally it returns true if the value was modified before setting, or false if it is set as requested. In the default case, this callback will return the same value and true (i.e. the new value for the attribute is accepted without further modifications).
- The third callback, +onRemote<AttributeName>Changed+, is called if the new value of the attribute differs from the old, and allows the service to do arbitrary work in response to such an attribute change. This is called after the clients are informed of the change.

These are protected to avoid exposing them to the API code, as they should only be called by the adapter. This is done via a generated class, the <interfaceName>StubRemoteEvent, which has access to these methods.

The CommonAPI library will transmit any "attribute changed" event notifications to remote listeners after the verify callback but before the change callback, if and only if the value of the attribute actually has changed after verification.

The default implementation of a generated stub does

- nothing on method calls
- return the new value of an attribute on a verify callback
- do nothing on an attribute changed callback

Events
^^^^^^

Events provide an asyncronous interface to remotely triggered actions. This covers broadcast methods in Franca IDL and change events for attributes Every proxy also provides an availabity event which can be used for notifications of the proxies status. The Events provide a subscribe and unsubscribe method which allow registration and de-registration of callbacks.

The public interface of the event class is as follows:

[source,{cppstr}]
----
template<typename ... _Arguments>
class Event {
 public:

	typedef std::function<void(const _Arguments&...)> Listener;
	typedef std::function<SubscriptionStatus(const _Arguments&...)> CancellableListener;
	typedef std::list<CancellableListener> ListenersList;
	typedef typename ListenersList::iterator Subscription;

	class CancellableListenerWrapper;

	/* Subscribe a listener to this event.*/
	virtual inline Subscription subscribe(Listener listener);
	/*Subscribe a cancellable listener to this event.*/
	Subscription subscribeCancellableListener(CancellableListener listener);
	void unsubscribe(Subscription listenerSubscription);

	virtual ~Event() {}

};
----

[NOTE]
- You should not build new proxies or register services in callbacks from events. This can cause a deadlock or assert. Instead, you should set a trigger for your application to do this on the next iteration of your event loop if needed. The preferred solution is to build all proxies you need at the beginning and react to events appropriatly for each.
- Do not call +unsubscribe+ inside a listener notification callback it will deadlock! Use cancellable listeners instead.

Runtime
-------

Loading the Middleware
~~~~~~~~~~~~~~~~~~~~~~

The Common API ((Runtime)) is the base class from which all class loading starts. The Common API Runtime accesses a config file to determine which specific middleware runtime library shall be loaded. Middleware libraries are either linked statically or are provided as shared objects (file extension .so), so they can be loaded dynamically. To make dynamic loading controllable, additional configuration parameters are available, see the chapter on "Configuration Files" below.

The public interface of the runtime class provides the following functions:

[width="100%",cols="50%asciidoc,50%"]
|=========================================================
|[source,{cppstr}]
----
static std::shared_ptr<Runtime>
load();
----
|Loads the runtime for the default middleware binding. This can be one of the middleware bindings that were linked at compile time. It is the first middleware binding that is encountered when resolving bindings at runtime or the middleware binding that was configured as default in the corresponding configuration file (throws an error if no such binding exists). The function returns the runtime object for the default binding, or null if any error occurred.

|[source,{cppstr}]
----
static std::shared_ptr<Runtime>
load(LoadState& loadState);
----
|The _loadState_ is an enumeration that will be set appropriately after loading has finished or aborted. May be used for debugging purposes.

|[source,{cppstr}]
----
static std::shared_ptr<Runtime>
load(const std::string&
	middlewareIdOrAlias);
----
|Loads the runtime for the specified middleware binding. The given well known name can be either the well known name defined by a binding, or a configured alias for a binding.

|[source,{cppstr}]
----
static std::shared_ptr<Runtime>
load(const std::string&
	middlewareIdOrAlias,
	LoadState& loadState);
----
|

|[source,{cppstr}]
----
std::shared_ptr<MainLoopContext>
getNewMainLoopContext() const;
----
|Creates and returns a new MainLoopContext object. This context can be used to take complete control over the order and time of execution of the abstract middleware dispatching mechanism. Make sure to register all callback functions before subsequently handing it to createFactory(), as during creation of the factory object the callbacks may already be called.

|[source,{cppstr}]
----
std::shared_ptr<Factory>
createFactory(
	std::shared_ptr<MainLoopContext>
	mainLoopContext =
	std::shared_ptr<MainLoopContext>(NULL),
	const std::string factoryName = "",
	const bool nullOnInvalidName = false);
----
|In case mainloop integration shall be used, a std::shared_ptr<MainLoopContext> can be passed in. If no parameter is given, internal threading will handle sending and receiving of messages automatically. If the mainloop context is not initialized, no factory will be returned. If additional configuration parameters for the specific middleware factory shall be provided, the appropriate set of parameters may be identified by the _factoryName_. If a factoryName is provided, the parameter _nullOnInvalidName_ determines whether the standard configuration for factories shall be used if the specific parameter set cannot be found, or if instead no factory shall be returned in this case.

|[source,{cppstr}]
----
std::shared_ptr<Factory>
createFactory(const std::string
	factoryName,
	const bool nullOnInvalidName = false);
----
|

|[source,{cppstr}]
----
virtual std::shared_ptr<ServicePublisher>
getServicePublisher() = 0;
----
| Returns the ServicePublisher object for this runtime. Use the interface provided by the ServicePublisher to publish and de-publish the services that your application will provide to the outside world over the middleware represented by this runtime. A ServicePublisher exists once per middleware.
|=========================================================


Linking the Middleware at Compile Time
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A specific Middleware runtime registers itself with the Common API Runtime during startup time via static initialization. Static initialization is done via a statically defined method in a +.cpp+ file with +__attribute\((constructor))+ as prefix. Within this method, registerRuntimeLoader of the Common API Runtime will be called. A specific middleware runtime needs to register itself with a well known string identifier, e.g. +DBus+ for a D-Bus middleware.

The architecture was chosen this way in order to ease later support of dynamic linkage. No template based architecture was used to cross the boundary from Common API to a specific middleware, because template parameters can not be substituted dynamically.

[source,{cppstr}]
----
__attribute__((constructor)) void registerDBusMiddleware(void) {
	Runtime::registerRuntimeLoader("DBus", &DBusRuntime::getInstance);
}
----

[NOTE]
These specification assumes that the operating system is Linux. For some reasons CommonAPI can be used for test purposes on Windows. Then, the procedure may be slightly different from the one described.

Linking the Middleware at Runtime
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

CommonAPI supports the loading of Middleware specific libraries at runtime, without linking them to the executable beforehand. For this purpose, each Middleware binding library provides a struct defined as extern "C", which provides information on the well known name of the Middleware, plus a function pointer to its runtime loader.

----
extern "C" const CommonAPI::MiddlewareInfo middlewareInfo;
----

The type +CommonAPI::MiddlewareInfo+ is defined in CommonAPI/MiddlewareInfo.h:
[source,{cppstr}]
----
typedef std::shared_ptr<Runtime> (*MiddlewareRuntimeLoadFunction) ();

struct MiddlewareInfo {
	const char* middlewareName_;
	MiddlewareRuntimeLoadFunction getInstance_;
	Version version_;
};
----

Factory
~~~~~~~

Create Factory
^^^^^^^^^^^^^^

The +CommonAPI::Factory+ class builds the proxies and registers stubs for a specific instance of a commonapi runtime (i.e. a particular binding) and connection. This class provides templated build methods which return particular instances of proxies according to the templates and passed address.

[NOTE]
If there are multiple connections to the rpc mechanism (not a specific service) multiple instances of Factory are needed.

A CommonAPI factory can be obtained with:

[source,{cppstr}]
----
//Loads default or first runtime binding defined in config file
std::shared_ptr<CommonAPI::Factory> factory = CommonAPI::Runtime::load()->createFactory();

//Loads a named runtime binding, either according to a well known name defined in the binding or a defined arbitrary alias as stated in the config file
std::shared_ptr<CommonAPI::Factory> factory2 = CommonAPI::Runtime::load("namedBinding")->createFactory();
----

The code to generate a factory is equal on both sides (stub and proxy).

The factory provides functions for the creation of the proxies and for determining the available services.

[source,{cppstr}]
----
/* Get a pointer to the runtime of this factory.*/
inline std::shared_ptr<Runtime> getRuntime();

/* Get all instances of a specific service name available. Synchronous call.*/
virtual std::vector<std::string> getAvailableServiceInstances(const std::string& serviceName, const std::string& serviceDomainName = "local") = 0;

/* Is a particular complete common api address available. Synchronous call.*/
virtual bool isServiceInstanceAlive(const std::string& serviceAddress) = 0;

/ * Is a particular complete common api address available. Synchronous call.*/
virtual bool isServiceInstanceAlive(const std::string& serviceInstanceID, const std::string& serviceName, const std::string& serviceDomainName = "local") = 0;
----

The asynchronous functions are defined analogously.

Create Proxy Objects
^^^^^^^^^^^^^^^^^^^^

The factory provides at least two functions for building the proxy:

[source,{cppstr}]
----
template<template<typename ...> class _ProxyClass, typename ... _AttributeExtensions >
std::shared_ptr<_ProxyClass<_AttributeExtensions...> > buildProxy(const std::string& serviceAddress);

template <template<typename ...> class _ProxyClass, template<typename> class _AttributeExtension>
std::shared_ptr<typename DefaultAttributeProxyFactoryHelper<_ProxyClass, _AttributeExtension>::class_t> buildProxyWithDefaultAttributeExtension(const std::string& serviceAddress);
----

_isAvailable_ is a non-blocking check whether the remote service for this proxy currently is available. Always returns false until the availability of the proxy is determined. The proxy actively determines its availability status asynchronously and ASAP as soon as it is created, and maintains the correct state afterwards.

- Calls to synchronous methods will block until the initial availability status of the proxy is determined. As soon as the availability status has been determined at least once, calls to synchronous methods will return NOT_AVAILABLE as value for the CallStatus whenever isAvailable() would return false.
- Calls to asynchronous methods do not wait for the initial availability status to be determined. Calls to asynchronous methods will instantly call the given callback with NOT_AVAILABLE as value for the CallStatus whenever isAvailable() would return false.
- You may subscribe to the ProxyStatusEvent in order to have a callback notified whenever the availability status of the proxy changes. It is guaranteed that the callback is notified of the proxy's currently known availability status at the same instant in which the subscription is done (i.e. the callback will most likely be called with a value of false if you subscribe for this event right after the proxy has been instantiated).

The parameter +serviceAddress+ is the address at which the service that shall be accessed will be available. Semantically, this address consists of three parts, separated by colons:

[width="80%",cols="3,10"]
|=========================================================

|Domain |
The first part, defines in which domain the service is located.

|ServiceID |
The second part. This defines the name or type of the service that shall be accessed.

|InstanceID |
The third part. This defines the specific instance of this service that shall be accessed.

|=========================================================

Register Services
^^^^^^^^^^^^^^^^^

The Factory class provides a +registerService()+ and +unregisterService()+ method. These allow the activation and deactivation of services and stubs via a complete common api address and a provided stub. The usage is similar to that for Proxies, except that no object is returned. Included below is the header for Common API factory.

Provider
^^^^^^^^

A ((provider)) is made up of two parts, the interface adapter and its helpers and the stub. The interface adapters need to be generated individually for each service, but they remain invisible to the application developer, except when designing a derived stub class.

An interface adapter is responsible for serialization and deserialization of messages, as well as the dispatching of the (de-)serialized messages to a registered stub. The stub forwards the broadcasts that are fired by a call to the "fire<BroadcastName>" methods to the adapter via the held shared pointer in order to send them.

An interface adapter for a specific middleware needs to be generated in order to provide dispatching and callback handling that matches the stub. The procedure to attain the correct interface adapter is equivalent to the procedure to attain the correct proxy on client side. A given instance of an interface handler can serve one and only one stub at a time. The connection from the adapter to the stub is established during build time by a call to the predefined initStubAdapter method of the Stub template class.

The common ancestor of any middleware specific handler (+CommonAPI::StubAdapter+) and stub (+CommonAPI::Stub+) classes defines a basic interface to retrieve general information about the service.

Stubs are the methods to be implemented by a provider. This includes the remotely callable methods defined in the interface and the callbacks for attribute accessors. These are provided as a default stub class with a default blank implementation for all methods and storage and handling of attribute values inside the stub, which allows the application developer to overwrite the methods in a subclass as needed. Alternatively the pure virtual root class can be implemented directly, which also allows delegation of attribute handlers to other parts of the code. A given instance of a stub can be appended to one and only one interface adapter.

Threading Model
~~~~~~~~~~~~~~~

CommonAPI supports multithreaded execution (standard threading) as well as single threaded execution (i.e. ((mainloop) integration). The decision which of both is desired happens when +CommonAPI::Runtime::createFactory+ is called. If single threaded execution is desired, a +CommonAPI::MainLoopContext+ has to be created, and then has to be passed as an argument to this method. All objects that are created by a factory that was instantiated this way will be controllable via the mainloop context that was handed to this factory. If a factory is not given this parameter during instantiation, standard threading will be set up for all objects that are created by this factory.

Standard Threading
^^^^^^^^^^^^^^^^^^

To create a factory that uses standard threading, a factory has to be created this way:

[source,{cppstr}]
----
std::shared_ptr<CommonAPI::Runtime> runtime = CommonAPI::Runtime::load();
std::shared_ptr<CommonAPI::Factory> factory = runtime->createFactory();
----

Mainloop Integration
^^^^^^^^^^^^^^^^^^^^

A +CommonAPI::MainLoopContext+ provides nothing but hooks for callbacks that will be called on specific binding internal events. Internal events may be

- (De-)Registration of a +CommonAPI::DispatchSource+
- (De-)Registration of a +CommonAPI::Watch+
- (De-)Registration of a +CommonAPI::Timeout+
- Issuing of a wakeup call

Each of these calls has to be mapped to an appropriate method in the context of the actual Mainloop that does the single threaded execution. CommonAPI does *NOT* provide a fully fledged implementation for a Mainloop!

What the mainloop related interfaces are meant for is this:

- +CommonAPI::DispatchSource+: Hooks that may have work ready that is to be done, e.g. dispatching a method call to a stub, dispatching a method return to a proxy callback and the like. There is no constraint on what kind of work may be represented by a DispatchSource, *BUT* a dispatch source may *NOT* be directly related to a file descriptor that is used to actually read or write the incoming or outgoing transmission from or to a transport!
- +CommonAPI::Watch+: Work that is related to a file descriptor that is used for reading from or writing to a transport is represented by Watches. *ANY* work that is not directly related to such a file descriptor may *NOT* be represented by watches!
- +CommonAPI::Timeout+: Represents the work that has to be done when a timeout occurs (e.g. deleting the structures that are used to identify an answer to an asynchronous call and calling the callback that is waiting for it with an appropriate error flag). A timeout stores internally both the interval of time within which it is to be dispatched, and the next moment in time the timeout is to be dispatched.

A binding developer *MUST* provide his own implementations for at least DispatchSource and Watch in order to ensure the functionality of his respective CommonAPI binding in the single threaded case, and must ensure that the appropriate instances of those classes are handed to the application via the MainLoopContext that was handed to the factory that is used to instantiate proxies and stubs.

An application developer *MAY* provide additional implementations of all these classes.

[NOTE]
During instantiation (i.e. during the call to +CommonAPI::Runtime::createFactory+) a binding *MAY* already issue calls to the callbacks that are registered with the +CommonAPI::MainLoopContext+. Therefore, it is mandatory to do any registration of required callbacks *BEFORE* doing so.

To create a factory that supports Mainloop integration, a factory has to be created this way:

[source,{cppstr}]
----
std::shared_ptr<CommonAPI::Runtime> runtime = CommonAPI::Runtime::load();
//Do any registration of callbacks for the actual Mainloop here!
std::shared_ptr<CommonAPI::MainLoopContext> context = runtime->getNewMainLoopContext();
std::shared_ptr<CommonAPI::Factory> factory = runtime->createFactory(context);
----

Configuring CommonAPI
~~~~~~~~~~~~~~~~~~~~~

Change the behavior of interfaces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There are basically two possibilities to realize a specific behavior of your interface or to realize new features:

- As described above the middleware implementation can be changed without changing the API for the applications. Changes in the configuration in the middleware or platform can be realized by changing the deployment specification and the deployment settings in the *.depl files.
- For attributes (see specification below) there is the possibility to define and implement so-called extensions. This allows the developer to extend the standard framework with own implementations in a predefined and specified way. One example is to implement a cache for attributes on proxy side.

Configuration Files
^^^^^^^^^^^^^^^^^^^

Each CommonAPI configuration file will define additional parameters for specific categories. Which categories and which parameters for each of those categories are available will be detailed below. All parameters for all categories are optional. For each omitted parameter a reasonable default will be set. Because of this, it is not mandatory to provide a config file unless you want to alter any of the configurable default values.

CommonAPI config files can be defined locally per binary, globally per binary or globally for all binaries. If more than one config file is defined for a given binary (e.g. one locally and one globally) and a given category is defined in several of these config files, for each parameter that may be provided for this category the value found in the most specific config file will take precedence. If a category is defined several times within the same config file, the first occurrence of each parameter will take precedence.

All categories and all parameters are separated from each other by one or more newline characters.

CommonAPI Config files have to be named this way:

- Binary local: "<FqnOfBinary>.conf", e.g. "/usr/bin/myBinary.conf" if the binary is "/usr/bin/myBinary"
- Binary global: "/etc/CommonApi/<NameOfBinary>.conf", e.g. "/etc/CommonAPI/myBinary.conf"
- Global: "/etc/CommonAPI/CommonAPI.conf"

Available categories
++++++++++++++++++++

_Well known names of specific middleware bindings_

Allows to set parameters that influence the loading procedure of specific middleware bindings.

The syntax is:

----
{binding:<well known binding name>}
libpath=<Fully qualified name of the library of the binding>
alias=<One or more desired aliases for the binding, separated by ":">
genpath=<One or more fully qualified names to libraries containing additional (generated) code for this binding, separated by ":">
default
----

- *libpath*: Provides a fully qualified name that replaces the search path when trying to dynamically load the identified binding.
** The library found at libpath will take precedence over all other dynamically discoverable libraries for this binding.
** If a library for the specified middleware binding is linked to the binary already, this parameter will have no effect.
** Not finding an appropriate library at libpath is considered to be an error! In this case, no further attempts to resolve the library will be made, and the load function will return an empty std::shared_ptr<CommonAPI::Runtime>.
** If an explicit error state is desired, one of the overloaded Runtime::load() functions may be called to pass in an instance of Runtime::LoadState as argument.

- *alias*: In order to load a specific middleware binding, one normally has to know the well known name of the middleware (e.g. "DBus" for the D-Bus middleware binding) and pass this name as parameter when calling CommonAPI::Runtime::load("<name>"). _alias maps the well known name for this purpose to one or more arbitrary aliases, thereby decoupling the loading of a specific middleware binding from its specific name.
** You *MAY* specify this parameter more than once for a binding. The effect will be the same as if you had one alias parameter specifying the exact same names separated by ":".
** If the same alias is specified more than once, only the first occurrence of the alias will be considered.
** As CommonAPI itself does not know about which well known middleware names there are, it is possible to specify the well known name of an actual binding as an alias for any other middleware binding. In this case, the actual middleware binding will not be accessible any longer, unless you specify another unique alias for it.
- *genpath*: Specifies one or more paths at which a generic library containing additional (e.g. generated middleware and interface code for the middleware binding is to be found. This additional code will be injected when the specific middleware considers it to be the right time to do so.
** You *MAY* specify this parameter more than once for a binding. The effect will be the same as if you had one genpath parameter specifying the exact same values separated by ":".
** If No such parameter is defined, the standard search paths "/usr/lib" and "/usr/local/lib" plus any additional paths defined in the environment variable COMMONAPI_BINDING_PATH (see below) will be searched for any libraries that match the name pattern "lib<wellKnownMiddlewareName>Gen-<arbitraryName>.so[.major.minor.revision]". All matching libraries will be loaded.
** Not finding an appropriate library at any single one of the defined genpaths may result in undefined behavior.
- *default*: Specifies the library for this binding as the default that is to be loaded if no parameter is given to CommonAPI::Runtime::load().
** Not finding an appropriate library for a configured default binding at neither specified nor the default paths is considered to be an error! In this case, no further attempts to resolve the library will be made, and the load function will return an empty std::shared_ptr<CommonAPI::Runtime>. If an explicit error state is desired, one of the overloaded Runtime::load() functions may be called to pass in an instance of Runtime::LoadState as argument.

[NOTE]
The genpath parameter will be parsed by the CommonAPI framework and stored in the singleton class CommonAPI::Configuration. Actually loading the libraries and following the rules described here however is task of the specific middleware binding. You might want to use the convenience methods provided in <CommonAPI/utils.h> for this purpose. By taking control of the actual proceedings, you may introduce additional mechanisms of discovering and loading such libraries, and you may defer the loading of these libraries until you deem it to be the right time to do so.

Environment Variables
^^^^^^^^^^^^^^^^^^^^^

- *COMMONAPI_BINDING_PATH*: By default, the standard paths "/usr/lib" and "/usr/local/lib" will be searched for binding libraries that are loaded dynamically (i.e. at runtime without linking them to the binary beforehand). All paths defined in this environment variable will take precedence over those two default paths. Separator between several paths is ":".

[glossary]
Glossary
--------

[glossary]
BLOB::
  Binary Large Object.

IDL::
  Interface Description Language.

IPC::
  Interprocess Communication.

GENIVI::
  is a non-profit industry alliance committed to driving the broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform.


ifdef::backend-docbook[]
[index]
Example Index
-------------
////////////////////////////////////////////////////////////////
The index is normally left completely empty, it's contents being
generated automatically by the DocBook toolchain.
////////////////////////////////////////////////////////////////
endif::backend-docbook[]