99久久香蕉国产线看观看,亚洲欧美自偷自拍另类小说,亚洲一本大道中文在线

我們已經可以基于vsomeip實現(xiàn)SOME/IP應用，并且服務端和客戶端之間進行消息的通信，消息的內容稱為Payload。
但是設想一下，如果當我們需要傳遞的消息內容是一個比較復雜的數(shù)據結構，比如一個結構體，一兩個倒也沒事，多了以后，Payload的打包、解析和聯(lián)調都會是件麻煩的事。

這時，我們會想到序列化，比如用Google Protocol Buffer之類的，是不是可以解決問題呢？

對于非AUTOSAR設備之間的通信，是可以解決的，但對于與AUTOSAR設備之間的通信，恐怕就行不通了，因為Payload是需要遵循AUTOSAR規(guī)范的，如圖：

于是，我們又會想到，如果有人能把序列化這一步也幫我們做好那就更好了，這就是RPC(Remote Procedure Call，遠程過程調用)可以做到的事了。

GENIVI的CommonAPI C++是基于vsomeip實現(xiàn)的RPC框架，今天就讓我們一起看一下它是怎么用的吧～

搭建CommonAPI的開發(fā)環(huán)境，有點費勁的，除了依賴于boost和vsomeip，還有CommonAPI和CommonAPI-SomeIP，以及C++代碼生成工具，這里就不一一說明了，我已經整理好，放在Github上，關注公眾號，回復“演示代碼”，可以獲得項目鏈接。

環(huán)境OK了以后，我們可以就創(chuàng)建第一個HelloWorld工程了，按照如圖所示CommonAPI的工作流程：

其中，F(xiàn)rancaIDL是一種接口描述語言，和編程語言無關。fidl文件是用IDL寫的，它描述了服務提供的接口信息，包括類型(比如method、broadcast、attribute等)、參數(shù)、返回值。

創(chuàng)建HelloWorld.fidl文件：

package commonapi


interface HelloWorld {
  version {major 1 minor 0}
  method sayHello {
    in {
      String name
    }
    out {
      String message
    }
  }
}

fdepl文件描述了服務的部署信息，包括Service ID、Instance ID、Method ID、Event ID等。

創(chuàng)建HelloWorld.fdepl文件：

import "platform:/plugin/org.genivi.commonapi.someip/deployment/CommonAPI-SOMEIP_deployment_spec.fdepl"
import "HelloWorld.fidl"


define org.genivi.commonapi.someip.deployment for interface commonapi.HelloWorld {
  SomeIpServiceID = 4660


  method sayHello {
    SomeIpMethodID = 123
  }
}


define org.genivi.commonapi.someip.deployment for provider as MyService {
  instance commonapi.HelloWorld {
    InstanceId = "test"
    SomeIpInstanceID = 22136
  }
}

CommonAPI代碼生成工具幾乎支持Franca的全部功能。

用準備好的工具生成代碼：

commonapi-core-generator-linux-x86_64 -sk ./fidl/HelloWorld.fidl
commonapi-someip-generator-linux-x86_64 ./fidl/HelloWorld.fdepl

在src-gen/v1/commonapi目錄里，可以看到如下這些生成的代碼文件：

萬事俱備，可以開發(fā)應用程序咯～

對于服務端，主程序代碼如下：

std::shared_ptr

其中，HelloWorldStubImpl是繼承于工具生成的HelloWorldStubDefault：

class HelloWorldStubImpl: public v1_0::commonapi::HelloWorldStubDefault {
public:
    HelloWorldStubImpl();
    virtual ~HelloWorldStubImpl();
    virtual void sayHello(const std::shared_ptr;
};

HelloWorldStubImpl實現(xiàn)了sayHello接口，正如fidl定義的，當客戶端發(fā)送name，回復“Hello name !”：

void HelloWorldStubImpl::sayHello(const std::shared_ptr
{
    std::stringstream messageStream;
    messageStream << "Hello " << _name << "!";
    std::cout << "sayHello('" << _name << "'): '" << messageStream.str() << "'\\n";
    _reply(messageStream.str());
};

對于客戶端，主程序如下：

std::shared_ptr < CommonAPI::Runtime > runtime = CommonAPI::Runtime::get();
std::shared_ptr

客戶端不需要實現(xiàn)接口，直接使用工具生成的HelloWorldProxy就可以了。

編譯運行的結果如下：

現(xiàn)在再看一下應該選擇CommonAPI還是vsomeip呢？用vsomeip的話，依賴的東西少，Payload的打包和解析要自己寫，工作量大，自由發(fā)揮的空間也大，用CommonAPI的話，依賴的東西多，環(huán)境搭建相對復雜，接口可以用IDL描述，這在SOA中非常有用，很多代碼由工具生成，基本通信幾乎不需要聯(lián)調，主要的開發(fā)工作是實現(xiàn)服務的接口，相當于填充業(yè)務邏輯，工作量少，同時可以發(fā)揮的空間也小。很多事都是這樣吧，獲得便利的同時也會損失一些自由，如何選擇還是要具體分析。

通過這個示例，我們看到使用RPC通信和上一篇中基于消息的通信是截然不同的編程體驗，RPC讓客戶端可以像調用本地函數(shù)一樣調用服務端的函數(shù)，很顯然它們并不在同一個進程中，這是如何做到的呢？

下面，我們結合一張經典的RPC原理框圖來看一下客戶端的sayHello到底是怎么調到服務端的sayHello的：