diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/CommonAPISpecification | 1065 | ||||
| -rw-r--r-- | doc/Makefile | 87 | ||||
| -rw-r--r-- | doc/Tutorial | 705 | ||||
| -rwxr-xr-x | doc/images/CodeGenerationFrancaIDL.png | bin | 0 -> 11443 bytes | |||
| -rwxr-xr-x | doc/images/Deployment.png | bin | 0 -> 14984 bytes | |||
| -rwxr-xr-x | doc/images/Diag_Attributes.png | bin | 0 -> 18429 bytes | |||
| -rwxr-xr-x | doc/images/Diag_GeneratedProxy.png | bin | 0 -> 16965 bytes | |||
| -rwxr-xr-x | doc/images/Diag_GeneratedStub.png | bin | 0 -> 66369 bytes | |||
| -rwxr-xr-x | doc/images/E04PhoneBook.png | bin | 0 -> 44793 bytes | |||
| -rwxr-xr-x | doc/images/E05Manager.png | bin | 0 -> 25028 bytes | |||
| -rwxr-xr-x | doc/images/icons/important.png | bin | 0 -> 3851 bytes | |||
| -rw-r--r-- | doc/images/icons/note.png | bin | 0 -> 4049 bytes | |||
| -rw-r--r-- | doc/mainpagetests/01_mainpage.dox | 27 |
13 files changed, 1884 insertions, 0 deletions
diff --git a/doc/CommonAPISpecification b/doc/CommonAPISpecification new file mode 100644 index 0000000..5793b97 --- /dev/null +++ b/doc/CommonAPISpecification @@ -0,0 +1,1065 @@ +CommonAPI C++ Specification +=========================== +:website: http://projects.genivi.org/commonapi/ +:version: +:date: +:toc: +:revdate: +:imagedir: +:cppstr: c++ + +This is the specification for *CommonAPI {version}* Revision Date {revdate}. + +.Copyright and License +******************************************************************************* +Copyright (C) 2013, GENIVI Alliance, Inc. +Copyright (C) 2013, BMW AG + +This file is part of the GENIVI Project IPC Common API C++. + +Contributions are licensed to the GENIVI Alliance under one or more +Contribution License Agreements or MPL 2.0. +******************************************************************************* + +CommonAPI is a C++ standard API framework for Interprocess Communication (IPC). A specific IPC framework is not included but it can be used with any kind of IPC mechanism if a middleware specific CommonAPI binding is provided. + +Common API allows that applications (i.e., clients and servers using C++) developed against Common API can be linked against different Common API IPC backends without any changes to the application code. Thus, components which have been developed for a system which uses IPC X can be deployed for a system which uses IPC Y easily, just by generating some glue code and rebuilt. 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]. + +Common API will not be restricted to GENIVI members (cf. new GENIVI open source policy). It is available as open source code and some code generation tooling (see http://projects.genivi.org/). + +.This document +******************************************************************************** +This document originates from a page in the GENIVI Wiki which was the result of some work of the System Infrastructure Expert Group +for the IPC subdomain. + +If you're new to CommonAPI please read the introduction of this document and the CommonAPI Tutorial which can be found in 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[] + diff --git a/doc/Makefile b/doc/Makefile new file mode 100644 index 0000000..ac1cbab --- /dev/null +++ b/doc/Makefile @@ -0,0 +1,87 @@ +# Creating CommonAPI documentation +docgendir=../doc-gen +iconsdir=../../images/icons +imagedir=../../images +datestring=$(shell date "+%m-%d-%y") +verification_project_path=../org.genivi.commonapi.core.verification +commonapi_version=2.1.5 + +all: doc + +doc: spec_html spec_pdf tut_html tut_pdf test_html test_pdf + +spec_html: docgendir + mkdir -p $(docgendir)/spec/html + asciidoc \ + -a revdate=$(datestring) \ + -a icons \ + -a iconsdir=$(iconsdir) \ + -a imagedir=$(imagedir) \ + -a version=$(commonapi_version) \ + -a cppstr=cpp \ + -a tabsize=4 \ + -o $(docgendir)/spec/html/CommonAPISpecification.html \ + CommonAPISpecification + +spec_pdf: docgendir + mkdir -p $(docgendir)/spec/pdf + a2x \ + -a revdate=$(datestring) \ + -a icons \ + -a iconsdir=$(iconsdir) \ + -a imagedir=$(imagedir) \ + -a version=$(commonapi_version) \ + -a tabsize=4 \ + -f pdf \ + --dblatex-opts "-P latex.output.revhistory=0" \ + --icons \ + -D $(docgendir)/spec/pdf \ + CommonAPISpecification + +tut_html: docgendir + mkdir -p $(docgendir)/tutorial/html + asciidoc -a revdate=$(datestring) \ + -a icons \ + -a iconsdir=$(iconsdir) \ + -a imagedir=$(imagedir) \ + -a version=$(commonapi_version) \ + -a cppstr=cpp \ + -a tabsize=4 \ + -b html \ + -o $(docgendir)/tutorial/html/Tutorial.html \ + Tutorial + +tut_pdf: docgendir + mkdir -p $(docgendir)/tutorial/pdf + a2x \ + -a revdate=$(datestring) \ + -a icons \ + -a iconsdir=$(iconsdir) \ + -a imagedir=$(imagedir) \ + -a version=$(commonapi_version) \ + -a tabsize=4 \ + -f pdf \ + --dblatex-opts "-P latex.output.revhistory=0 -P imagedata.default.scale=maxwidth=10cm,maxheight=8cm" \ + --icons \ + -D $(docgendir)/tutorial/pdf \ + Tutorial + +test_html: docgendir + mkdir -p $(docgendir)/tests + OUTPUT_DIRECTORY=$(docgendir)/tests \ + PROJECT_NAME=CommonAPITests \ + SRC_DIR='$(verification_project_path)/src ../doc/mainpagetests' \ + doxygen $(verification_project_path)/doxygen-test.cfg + +test_pdf: test_html + cd $(docgendir)/tests/latex; make > /dev/null + mkdir -p $(docgendir)/tests/pdf + cp $(docgendir)/tests/latex/refman.pdf $(docgendir)/tests/pdf/CommonAPITests.pdf + rm -rf $(docgendir)/tests/latex + +docgendir: + mkdir -p $(docgendir) + cp -rf images $(docgendir)/images + +clean: + rm -rf $(docgendir) diff --git a/doc/Tutorial b/doc/Tutorial new file mode 100644 index 0000000..73d7587 --- /dev/null +++ b/doc/Tutorial @@ -0,0 +1,705 @@ +CommonAPI C++ Tutorial +====================== +:author: Juergen Gehring - juergen.gehring@bmw.de +:doctitle: CommonAPI C++ Tutorial +:website: http://projects.genivi.org/commonapi/ +:version: +:date: +:toc: +:revdate: +:imagedir: +:cppstr: c++ + +Introduction +------------ + +This tutorial has the following content: + +- installation instructions for CommonAPI and CommonAPI-DBus including the tools +- a step by step tutorial on how you can write your first Hello World program +- some examples with description which show the usage of CommonAPI in conjunction with Franca IDL +- some special topics like deployment or the communication with legacy D-Bus applications + +Common API and its mechanism specific bindings (e.g. Common API D-Bus) provide a set of libraries and tools to work with RPC communication in a way independent of wich mechanism is used. Once you have implemented your services and clients and tested it with D-Bus you later can switch D-Bus for any other communication layer (provided it has Common API support) _without the need to touch your code or your binary at all!_. + +Further information on Common API and Common API D-Bus is provided in the individual README files accompanying both packages. + +Getting started +--------------- + +CommonAPI is a GENIVI project. Source code and latest news can be found at http://projects.genivi.org/commonapi/. + +For documentation please visit the GENIVI document page http://docs.projects.genivi.org/. + +CommonAPI currently consists of four subprojects: + +[width="80%",cols="3,10"] +|========================================================= + +|CommonAPI | +This is the base C++ library, which provides the application interface for users and can load runtime bindings such as dbus. + +|CommonAPI-Tools | +The eclipse based tools for CommonAPI. This is essentially the code generator for Franca -> Common API C++ code. (This is the current package.) + +|CommonAPI-D-Bus | +This is the D-Bus binding C++ library, which provides the necessary code to communicate over D-Bus. This is invisible to the application code, and simply needs to be linked against. + +|CommonAPI-D-Bus-Tools | +The eclipse based tools for CommonAPI D-Bus. This is the code generator for Franca -> Common API D-Bus C++ code. + +|========================================================= + +Closely related to CommonAPI is the yamaica project which provides a full integration of all Franca IDL and CommonAPI plugins and some more enhanced features like the import and export of Franca files to Enterprise Architect (see http://projects.genivi.org/yamaica/). The yamaica project provides eclipse update-sites for CommonAPI and yamaica (see http://docs.projects.genivi.org/yamaica-update-site/) ready for installation. + +Before we proceed you should clarifiy whether you are a user, in the sense that you want to write applications based on CommonAPI or whether you want to contribute to CommonAPI yourself or write your own middleware specific binding. + +Requirements +~~~~~~~~~~~~ +- Code generator and Franca tooling are based on Eclipse. Please make sure that you have an appropriate Eclipse version installed (see the compatibility table at the beginning of the document or the README file). +- Make sure all requirements to build the CommonAPI Runtime are installed and in the correct version. CommonAPI was developed using gcc 4.6 and gcc 4.7, but is feature compatible to gcc 4.5 and compiler compatible to gcc 4.4. + +Set up your environment as CommonAPI user +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +CommonAPI Tools +^^^^^^^^^^^^^^^ + +The CommonAPI Tools are available as Eclipse update-site or (if you prefer not to use Eclipse) as commandline tool. + +First we assume that you use an Eclipse CDT development environment. Please make sure that you have installed Franca IDL first before you continue with installing the CommonAPI Tools. Please find the installing instructions for Franca IDL at https://code.google.com/a/eclipselabs.org/p/franca/. + +The simplest way to use the CommonAPI Tools is to add the update site available on the GENIVI project servers to your Eclipse. This is available under: + +Help->Install New Software->Add Button + +Enter the following URL: http://docs.projects.genivi.org/yamaica-update-site/CommonAPI/updatesite/ and confirm. This provides CommonAPI, CommonAPI-D-Bus, CommonAPI Validator and all dependencies. Then select the newly added site in the site selection dropdown box, and in the Software selection window, select the entire "GENIVI CommonAPI Generators" Tree. Ignore all the other entries in the selection part of the "Available Software" window. + +After the software has been installed in Eclipse you can right-click on any .fidl file and generate C++ code for CommonAPI D-Bus by selecting the "CommonAPI->Generate Common API Code" option. + +[NOTE] +- The CommonAPI Validator must not necessarily be installed. But he recognizes Franca language constructs that Franca IDL permits, but result in non-executable or non-compilable code. An example is the use of C++ keywords in the interface specification. +- From Franca IDL, you will only need to install the sub-category "Franca Feature" for the Common API and Common API D-Bus generators to work. + + +If you want to use the command line version of the code generator, you can get the actual version at: + +http://docs.projects.genivi.org/yamaica-update-site/CommonAPI/generator/ + +where should be a link to the git repository: + +http://git.projects.genivi.org/yamaica-update-site.git/ + +For the usage of the command line version please consider the README file of the CommonAPI-Tools project. + +CommonAPI Runtime +^^^^^^^^^^^^^^^^^ + +Download the Common API runtime via git from the download site of http://projects.genivi.org/commonapi/, then compile and install the library on your computer: + +---- +$ git clone git://git.projects.genivi.org/ipc/common-api-runtime.git +$ cd common-api-runtime +$ autoreconf -i +$ ./configure +$ make +$ sudo make install (or alternative install process, eg. checkinstall on debian-based distributions, such as Ubuntu) +---- + +With this, the Common API runtime library will be installed in +/usr/local/lib+. The package is accessible for your application e.g. via pkgconfig. The pkgconfig data is located at /usr/local/lib/pkgconfig. + +To build Common API D-Bus, the Common API runtime and libdbus version 1.4.16 patched with the marshaling patch must be available through PkgConfig. The marshalling patch is provided within the Common API D-Bus package. + +Download the Common API D-Bus library via git from the download site of http://projects.genivi.org/commonapi/: + +---- +$ git clone git://git.projects.genivi.org/ipc/common-api-dbus-runtime.git +---- + +Download, patch and install version 1.4.16 of libdbus (*WARNING*: _Not_ following these instructions may result in corruption of the preinstalled libdbus library of your computer, thereby rendering your system unusable): + +---- +$ wget http://dbus.freedesktop.org/releases/dbus/dbus-1.4.16.tar.gz +$ tar -xzf dbus-1.4.16.tar.gz +$ cd dbus-1.4.16 +$ patch -p1 < </your/download/path>/common-api-dbus-runtime/dbus-DBusMessage-add-support-for-custom-marshaling.patch +$ ./configure --prefix=/usr/local +$ make -C dbus +$ sudo make -C dbus install +$ sudo make install-pkgconfigDATA +---- + +The path to CommonAPI and patched libdbus pkgconfig files must be added to the +PKG_CONFIG_PATH+ for the rest of the entire build process. +If you followed the instructions above, both will be located in +/usr/local/lib/pkgconfig+, so you can just type: + +---- +$ export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH" +---- + +[NOTE] +If you want to make sure that you do not destroy your linux installation then it is also possible not to install the patched lidbus. In this case you just have to set your package config path correctly. + +Now, compile and install the Common API D-Bus library on your computer + +---- +$ cd </your/download/path>/common-api-dbus-runtime +$ autoreconf -i +$ ./configure +$ make +$ sudo make install (or alternative install process, eg. checkinstall on debian-based distributions, such as Ubuntu) +---- + +With this, the libraries for Common API and Common API D-Bus are installed and ready for use. + +[NOTE] +- If you prefer to install CommonAPI from a tar file you can get the actual tar file from: +http://docs.projects.genivi.org/yamaica-update-site/CommonAPI/runtime/ +- In Linux please don't forget to add the installation path of your CommonAPI libraries to your LD_LIBRARY_PATH environment variable. + +Set up your environment as CommonAPI contributor +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Preliminary remarks +^^^^^^^^^^^^^^^^^^^ + +First get the code from the git: +---- +$ git clone +---- + +Get an overview of all branches: +---- +$ git branch +---- + +Switch to the branch you want to work on (master is the feature branch) and verify that it has switched (* changed) +---- +$ git checkout <your branch> +$ git branch +---- + +Best practice is to create a local branch based on the current branch: +---- +$ git branch working_branch +---- + +Start working, best practice is to commit smaller, compilable pieces during the development process that makes it easier to handle later on. If you want to commit you changes, send them to the author, you can create a patch like this: + +---- +$ git format-patch working_branch <your branch> +---- + +This creates a set of patches that are published via the mailing list.The patches will be discussed and then merged & uploaded on the git by the maintainer. + +Patches can be accepted either under GENIVI Cla or MPL 2.0 (see section License). Please be sure that the signed-off-by is set correctly. For more, check out http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html + +CommonAPI Tools +^^^^^^^^^^^^^^^ + +For the build instructions of the CommonAPI tools with maven see again the README file. + +Hello World +----------- + +The examples of the use of Franca IDL in conjunction with CommonAPI can be found in the folder CommonAPI-Examples in the subproject CommonAPI tools. The first example substantially contains the code for the Hello World example, which will be described below. But even if the code already exists, it is recommended to build the sample from scratch on for a better understanding of the individual steps. + +It is assumed that you have created a C++ project in your Eclipse in which all further development will happen. + +Creating the RMI interface definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The first step in developing a Common API application likely will be the definition of the RMI interface the client will use to communicate with the server. In the context of CommonAPI, the definition of this interface always happens via the Franca IDL, regardless of which communication mechanism you intend to use in the end. For this tutorial, create an arbitrarily namend file ending in _.fidl_ in your Eclipse project. It is +not relevant where in your project you have placed this file, as the the code generated from this file will always be put in the automatically created src-gen folder at the top level of the project hierarchy. + +Open your newly created _.fidl_-file, and type the following lines: + +[source,java] +---- +package commonapi.examples + +interface e01HelloWorld { + version { major 1 minor 0 } + + method sayHello { + in { + String name + } + out { + String message + } + } +} +---- + +[NOTE] +The _version_ parameter in every interface is mandatory! No code will be generated if it is malformed or not present! + + +Now, save the _.fidl_ file and right click it. As you have installed the Common API and Common API D-Bus generators, you will see a menu item saying _"Common API"_, with sub menu items for generating either the Common API level code only ("_Generate C\++ Code_") or for generating both the Common API level code and the glue code required to run applications with using Common API D-Bus ("_Generate D-Bus C++ Code_"). + +Generating code +~~~~~~~~~~~~~~~ + +We do want to use D-Bus as middleware, so we will need the D-Bus specific glue code as well as the Common API level code which we will +program agains. Therefore, you might want to chose the latter of the two options provided by the generator plugin ("_Generate D-Bus C++ Code_"). +After having done so, you will see the newly created src-gen folder and it's contents. The files will be created according to their +fully qualified names relative to src-gen as the top level folder, as defined in the _.fidl_-file: + +---- +E01HelloWorld.h +E01HelloWorldProxy.h +E01HelloWorldProxyBase.h +E01HelloWorldStub.h +E01HelloWorldStubDefault.cpp +E01HelloWorldStubDefault.h + +E01HelloWorldDBusProxy.cpp +E01HelloWorldDBusProxy.h +E01HelloWorldDBusStubAdapter.cpp +E01HelloWorldDBusStubAdapter.h +---- + +All files that have a "DBus" in their name are glue code required by the D-Bus binding and are not relevant while developing your application, they only need to be compiled with your application (there are ways to NOT compile these sources with your applications and include them at runtime instead; see the README of Common API D-Bus for details). + +All other files that have a _Proxy_ in their name are relevant for you if you develop a client, all other files that have a _Stub_ in their name are relevant for you if you develop a service. A proxy is a class that provides method calls that will result in remote method invocations on the service, plus registration methods for events that can be broadcasted by the service. + +A stub is the part of the service that will be called when a remote method invocation from a client arrives. It also contains methods to fire events (broadcasts) to several or all clients. The Stub comes in two flavors: One default stub that contains empty implementations of all methods, thereby allowing you to implement only the ones you are interested in, and a Stub skeleton where you have to implement everything yourself before you can use it. A service will have to implement a subclass of either of the two in order to make itself available to the outside world (or just use the default stub if your service should not be able to do anything except firing events). + +In this tutorial, we will create both a client and a service in order to be able to see some communication going on. + +Implement the Client +~~~~~~~~~~~~~~~~~~~~ + +Start by creating a new .cpp source file in your project (e.g. e01HelloWorldClient.cpp). Make sure you have a main method in order to start the client application. + +Here, you will need two includes in order to access the Common API client functionality: + +[source,{cppstr}] +---- +#include <iostream> + +#include <CommonAPI/CommonAPI.h> //Defined in the Common API Runtime library +#include <commonapi/examples/E01HelloWorldProxy.h> //Part of the code we just generated +---- + +The first thing each and every Common API application will do is to load a runtime: + +[source,{cppstr}] +---- +std::shared_ptr<CommonAPI::Runtime> runtime = CommonAPI::Runtime::load(); +---- + +If you link the Common API DBus library to and compile the generated DBus specific code with your executable, this runtime "magically" will be a runtime that provides access to the DBus communication infrastructure via a strictly CommonAPI level interface. If you link the library and add the generated code of another Common API middleware binding instead, this runtime will provide access to this other communication infrastructure. + +In order to be able to communicate with a specific service, we need a proxy. We can create a proxy by using a factory, which in turn we can get from the runtime we just created: + +[source,{cppstr}] +---- +std::shared_ptr<CommonAPI::Factory> factory = runtime->createFactory(); +const std::string& serviceAddress = "local:commonapi.examples.HelloWorld:commonapi.examples.HelloWorld"; +std::shared_ptr<E01HelloWorldProxy<>> myProxy = factory->buildProxy<E01HelloWorldProxy>(serviceAddress); +---- + +The parameter _serviceAddress_ is the address at which the service that shall be accessed will be available. This address will be translated internally to an actual DBus-Address - or whatever format fits the communication infrastructure you use. 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. For DBus use cases, only "local" makes any sense, as no services that are more remote than "on the same operating system" are accessible. + +|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. + +|========================================================= + +There are ways to influence the translation of the Common API address to the specific address (of course once again without the need to change your code). Please have a look at the README of Common API DBus if you want to know more about this possibility in the context of DBus, or the corresponding documentation of the other middleware binding you are using. + +With this, the client is set up and ready to use. We should wait for the service to be available, then we can start issuing calls: + +[source,{cppstr}] +---- +while (!myProxy->isAvailable()) { usleep(10); } + +const std::string name = "World"; +CommonAPI::CallStatus callStatus; +std::string returnMessage; + +myProxy->sayHello(name, callStatus, returnMessage); +if (callStatus != CommonAPI::CallStatus::SUCCESS) { + std::cerr << "Remote call failed!\n"; + return -1; +} +std::cout << "Got message: '" << returnMessage << "'\n"; +---- + +Implement the Service +~~~~~~~~~~~~~~~~~~~~~ + +Works about the same way as implementing the client. The includes that are required are the following: + +[source,{cppstr}] +---- +#include <iostream> +#include <thread> + +#include <CommonAPI/CommonAPI.h> +#include "E01HelloWorldStubImpl.h" +---- + +And we also need a stub that actually does something when the method we call in the client gets called: + +[source,{cppstr}] +---- +void E01HelloWorldStubImpl::sayHello(const std::shared_ptr<CommonAPI::ClientId> clientId, + std::string name, std::string& message) { + + std::stringstream messageStream; + + messageStream << "Hello " << name << "!"; + message = messageStream.str(); + std::cout << "sayHello('" << name << "'): '" << message << "'\n"; +}; +---- + +The rest looks quite similar to the client side, with the difference that we do not issue calls via a proxy, but instead register a service that then +will be provided to the outside world. The service is registered using the same Common API address, which allows the proxy to actually find the service. +Afterwards, we just wait for calls: + +[source,{cppstr}] +---- +std::shared_ptr<CommonAPI::Runtime> runtime = CommonAPI::Runtime::load(); +std::shared_ptr<CommonAPI::Factory> factory = runtime->createFactory(); +std::shared_ptr<CommonAPI::ServicePublisher> servicePublisher = + runtime->getServicePublisher(); + +const std::string& serviceAddress = + "local:commonapi.examples.HelloWorld:commonapi.examples.HelloWorld"; + +std::shared_ptr<E01HelloWorldStubImpl> myService = + std::make_shared<E01HelloWorldStubImpl>(); + +servicePublisher->registerService(myService, serviceAddress, factory); + +while(true) { + std::cout << "Waiting for calls... (Abort with CTRL+C)" << std::endl; + std::this_thread::sleep_for(std::chrono::seconds(60)); +} +---- + +Running the Demo +~~~~~~~~~~~~~~~~ + +Build the two applications using your favourite build system. If all worked well, you should see communication ongoing via DBus (e.g. via dbus-monitor), and you should get output from your client once, saying + +---- +"Got Message: 'Hello World'". +---- + +Advanced Topics +--------------- + +Special Franca Features +~~~~~~~~~~~~~~~~~~~~~~~ + +Selective +^^^^^^^^^ + +Selective broadcasts, indicated with the selective keword after the name of the broadcast in Franca can be sent to individual clients rather +than all participants. This is accomplished with the use of a ClientID parameter which can serve to identify the targets. Note if you wish to +identify clients absolutely you must do this on the application level. + +We can add a block to our interface for the selective broadcast: + +[source,java] +---- +broadcast saySomething selective { + out { + String message + } +} +---- + +We can the add some code to our stub implementation to handle this: + +[source,{cppstr}] +---- +virtual void onSaySomethingSelectiveSubscriptionChanged( + const std::shared_ptr<CommonAPI::ClientId> clientId, + const CommonAPI::SelectiveBroadcastSubscriptionEvent event) { + + if (event == CommonAPI::SelectiveBroadcastSubscriptionEvent::SUBSCRIBED) { + lastId = clientId; + } +} +---- + +and to the sayHello method: + +[source,{cppstr}] +---- +std::shared_ptr<CommonAPI::ClientIdList> receivers = + std::make_shared<CommonAPI::ClientIdList>(); + +if (lastId) { + receivers->insert(lastId); +} + +this->fireSaySomethingSelective("Broadcast to last ID", receivers); +---- + +and finally a member to the stub: + +[source,{cppstr}] +---- +private: + std::shared_ptr<CommonAPI::ClientId> lastId; +---- + +The onSaySomethingSelectiveSubscriptionChanged method is called when a subscription for this boroadcast changes. Is added, we set the memeber lastId to this value. Whenever sayHello is called we now also send a broadcast only to the last client which registered. The ClientIdList contains all the intended recipients, and the middleware will send the message to all memeber of this list who are registered for the broadcast. If NULL is passed instead the broadcast is sent to all clients. + +On the client side we can add this before the const std::string name = "World"; line: + +[source,{cppstr}] +---- +helloWorldProxy->getSaySomethingSelectiveEvent().subscribe( + [&](const std::string& message) { + std::cout << "Received broadcast message: " << message << "\n"; +}); +---- + +This casues a subscription to the broadcast, and the lambda function will be called whenever we receive a message. + +Managed Stubs +^^^^^^^^^^^^^ + +In Franca a relationship between two interfaces can be declared in the form "x manages y". This indicates that x has a number of y as childeren whose lifecycle is tied to and managed by x. This allows a an application to activare y stubs on an instance of x stubs. Similarily on the proxy side a manager for y interfaces is available on the x proxy, where we can be informed of appearing and disappearing instances, and interrogate the network about the state of instances. + +In our Franca file change the defenition of the HelloWorldInterface to: + +[source,java] +---- +interface HelloWorldInterface manages HelloWorldLeaf { +---- + +and after this interface block add: + +[source,java] +---- +interface HelloWorldLeaf { + version { major 1 minor 0 } + + method sayHelloLeaf { + in { + String name + } + out { + String message + } + } +} +---- + +This causes HelloWorldInterface to be able to manage HelloWorldLeaf instances. Note that HelloWorldLeaf instances can still be registered and accessed in the normal way via the service publisher and factory. To the stub application add to the top as a new class defenition: + +[source,{cppstr}] +---- +class MyHelloWorldLeafStub: public commonapi::examples::HelloWorldLeafStubDefault { + public: + virtual void sayHelloLeaf(std::string name, std::string& message) { + std::stringstream messageStream; + + messageStream << "Hello Leaf " << name << "!"; + message = messageStream.str(); + + std::cout << "sayHelloLeaf('" << name << "'): '" << message << "'\n"; + } +}; +---- + +To the bottom of the main function before the while loop add: + +[source,{cppstr}] +---- +auto helloWorldLeafStub = std::make_shared<MyHelloWorldLeafStub>(); + +const std::string leafInstance = "commonapi.examples.HelloWorld.Leaf"; + +const bool leafOk = helloWorldStub->registerManagedStubHelloWorldLeaf( + helloWorldLeafStub, leafInstance); + +if (!leafOk) { + std::cerr << "Error: Unable to register leaf service!\n"; + return -1; +} +---- + +To the client programm add to the bottom of the main function just before return 0: + +[source,{cppstr}] +---- +const std::string leafInstance = "commonapi.examples.HelloWorld.Leaf"; +CommonAPI::CallStatus callStatusAv; +CommonAPI::AvailabilityStatus availabilityStatus; +helloWorldProxy->getProxyManagerHelloWorldLeaf().getInstanceAvailabilityStatus( + leafInstance, callStatusAv, availabilityStatus); + +if (callStatusAv == CommonAPI::CallStatus::SUCCESS && + availabilityStatus == CommonAPI::AvailabilityStatus::AVAILABLE) { + + auto helloWorldLeafProxy = + helloWorldProxy->getProxyManagerHelloWorldLeaf(). + buildProxy<commonapi::examples::HelloWorldLeafProxy>(leafInstance); + + const std::string nameLeaf = "WorldLeaf"; + CommonAPI::CallStatus callStatusLeaf; + std::string helloWorldLeafMessage; + + std::cout << "Sending name: '" << nameLeaf << "'\n"; + helloWorldLeafProxy->sayHelloLeaf(nameLeaf, callStatusLeaf, helloWorldLeafMessage); + if (callStatusLeaf != CommonAPI::CallStatus::SUCCESS) { + std::cerr << "Remote call failed!\n"; + return -1; + } + + std::cout << "Got message: '" << helloWorldLeafMessage << "'\n"; + +} else { + std::cout << "Leaf Proxy not available\n"; + sleep(5); + return -1; +} +---- + +This instantiates and calls a managed leaf stub and proxy respectively. + +Attribute Extensions +~~~~~~~~~~~~~~~~~~~~ + +As described in the CommonAPI specification there is a general scheme to include individual extensions in order to provide any additional features for attributes. In principle Attribute Extensions work as follows: + +- Decide whether you want to implement a common attribute extension for all attributes of an interface or a specific extension for one attribute. +- Define a so-called templated extension class which inherits from +CommonAPI::AttributeExtension+ within a hpp-file. The example below defined in +AttributeCacheExtension.hpp+ shows an extension class for the caching of attributes on proxy side. +- Generate the proxy for your interface with the API method +buildProxyWithDefaultAttributeExtension+ if you want a common extension. For the specific extension call build proxy with the attribute extension as template parameter. +- Now you can call the implemented functions of your extension via a +getNameAttributeExtension()+ call (where +Name+ is the name of your attribute). + +Example of an extension class for caching attributes (file +AttributeCacheExtension.hpp+): +[source,{cppstr}] +---- +#include <CommonAPI/CommonAPI.h> + +template<typename _AttributeType> +class AttributeCacheExtension: public CommonAPI::AttributeExtension<_AttributeType> { + typedef CommonAPI::AttributeExtension<_AttributeType> __baseClass_t; + + public: + typedef typename _AttributeType::ValueType value_t; + typedef typename _AttributeType::AttributeAsyncCallback AttributeAsyncCallback; + + AttributeCacheExtension(_AttributeType& baseAttribute) : + CommonAPI::AttributeExtension<_AttributeType>(baseAttribute), + isCacheValid_(false) { + } + + ~AttributeCacheExtension() {} + + bool getCachedValue(value_t& value) { + + if (isCacheValid_) { + + value = cachedValue_; + } else { + + __baseClass_t::getBaseAttribute().getChangedEvent().subscribe(std::bind( + &AttributeCacheExtension<_AttributeType>::onValueUpdate, + this, + std::placeholders::_1)); + + CommonAPI::CallStatus callStatus; + __baseClass_t::getBaseAttribute().getValue(callStatus, value); + } + + return isCacheValid_; + } + + private: + + void onValueUpdate(const value_t& t) { + isCacheValid_ = true; + cachedValue_ = t; + } + + mutable bool isCacheValid_; + mutable value_t cachedValue_; +}; +---- + +In your main function you can call now: +[source,{cppstr}] +---- +#include "AttributeCacheExtension.hpp" +using your::namespace; // eg commonapi::examples + +... // Other code here + +const std::string& serviceAddress = "..."; + +// your proxy class is ProxyName +std::shared_ptr<CommonAPI::DefaultAttributeProxyFactoryHelper<ProxyName, + AttributeCacheExtension>::class_t> myProxy = + factory->buildProxyWithDefaultAttributeExtension<ProxyName, + AttributeCacheExtension>(serviceAddress); + +// and then if your attribute is x of type Int32: +int32_t valueCached = 0; +myProxy->getXAttributeExtension().getCachedValue(valueCached); +---- + +Examples +-------- + +include::../CommonAPI-Examples/README[] +include::../CommonAPI-Examples/e01HelloWorld/README[] +include::../CommonAPI-Examples/e02Attributes/README[] +include::../CommonAPI-Examples/e03Methods/README[] +include::../CommonAPI-Examples/e04PhoneBook/README[] +include::../CommonAPI-Examples/e05Manager/README[] +include::../CommonAPI-Examples/e06Unions/README[] + +FAQ +--- + +The middleware loading mechanism of Common API +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +CommonAPI::Runtime::load() returns no runtime object, why? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As it was mentioned before, when you call +CommonAPI::Runtime::load()+ you "magically" will have access to a specific middleware library. In a very basic case, the library and thereby communication mechanism you will have access to will be the only Common API middleware library you linked to your executable during compilation. + +However, this call to +load()+ most likely will *FAIL* if you have no generated middleware specific code that is compiled with your application. Why that? + +The reason is simple, once understood: Most linkers are lazy. They do not link libraries that seem to be unused. Due to the fact that there is no reference whatsoever from Common API (and therefore your application) to any of the middleware libraries, the linker considers any and all middleware libraries as unused if not referenced by middleware specific generated code, and therefore will not add them to the executable. + +You can disable this behavior by passing the linker flag +whole-archive+ during the build process. Note however that this behavior normally is a good optimization +without repercussions - except probably in the context of CommonAPI. + + +How can I use Using more than one middleware binding? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +CommonAPI provides the possibility to use more than one middleware binding at once. In this case, you should no longer use +CommonAPI::Runtime::load()+, +but instead +CommonAPI::Runtime::load("NameOfSomeMiddleware")+. + +The "NameOfSomeMiddleware" is the well known name of the middleware you want to load. It is defined and made public by each of the middlewares that support +Common API. For DBus, this name is simply "DBus". + + +Fully dynamic loading and additional information +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This topic is handled in-depth in the specification of Common API. Please refer to this file for any further information. + diff --git a/doc/images/CodeGenerationFrancaIDL.png b/doc/images/CodeGenerationFrancaIDL.png Binary files differnew file mode 100755 index 0000000..f90c135 --- /dev/null +++ b/doc/images/CodeGenerationFrancaIDL.png diff --git a/doc/images/Deployment.png b/doc/images/Deployment.png Binary files differnew file mode 100755 index 0000000..16d4404 --- /dev/null +++ b/doc/images/Deployment.png diff --git a/doc/images/Diag_Attributes.png b/doc/images/Diag_Attributes.png Binary files differnew file mode 100755 index 0000000..36e25f7 --- /dev/null +++ b/doc/images/Diag_Attributes.png diff --git a/doc/images/Diag_GeneratedProxy.png b/doc/images/Diag_GeneratedProxy.png Binary files differnew file mode 100755 index 0000000..2f7fc3b --- /dev/null +++ b/doc/images/Diag_GeneratedProxy.png diff --git a/doc/images/Diag_GeneratedStub.png b/doc/images/Diag_GeneratedStub.png Binary files differnew file mode 100755 index 0000000..8970c90 --- /dev/null +++ b/doc/images/Diag_GeneratedStub.png diff --git a/doc/images/E04PhoneBook.png b/doc/images/E04PhoneBook.png Binary files differnew file mode 100755 index 0000000..5cb2b40 --- /dev/null +++ b/doc/images/E04PhoneBook.png diff --git a/doc/images/E05Manager.png b/doc/images/E05Manager.png Binary files differnew file mode 100755 index 0000000..1538c0d --- /dev/null +++ b/doc/images/E05Manager.png diff --git a/doc/images/icons/important.png b/doc/images/icons/important.png Binary files differnew file mode 100755 index 0000000..3148adb --- /dev/null +++ b/doc/images/icons/important.png diff --git a/doc/images/icons/note.png b/doc/images/icons/note.png Binary files differnew file mode 100644 index 0000000..9859d6e --- /dev/null +++ b/doc/images/icons/note.png diff --git a/doc/mainpagetests/01_mainpage.dox b/doc/mainpagetests/01_mainpage.dox new file mode 100644 index 0000000..1cb65df --- /dev/null +++ b/doc/mainpagetests/01_mainpage.dox @@ -0,0 +1,27 @@ +/** + * Copyright (C) 2013 BMW AG + * * + * This file is part of GENIVI project IPC CommonAPI C++. + * + * Contributions are licensed to the GENIVI Alliance under one or more + * Contribution License Agreements. + * + * \author Juergen Gehring (juergen.gehring@bmw.de) + * \author Manfred Bathelt (manfred.bathelt@bmw.de) + * + */ + +/*! +\mainpage + +\par This document +This document provides a list of tests which are implemented in the project +org.genivi.commonapi.core.verification+ which is part of CommonAPI-Tools. These tests are middleware independent and can be used to verify the correct implementation of middleware specific bindings. + +\par About IPC CommonAPI C++ +IPC CommonAPI C++ is a C++ based abstraction API for communication stacks, which enables applications to +use different communication middleware - so called language bindings - as backend without any changes to the application code. + +\par More information +can be found at the <a href="http://projects.genivi.org/commonapi/">project homepage</a> \n +Please see the <a href="http://projects.genivi.org/commonapi/download">project download section</a> for available language bindings. +*/ |
