基于Embedded Linux的gSOAP的移植和裁剪

李永，俞輝

0 引言

現在的網絡服務中，客戶端和服務器之間的通信問題一般由HTTP協議完成，這是因為任何一款Web瀏覽器都支持HTTP協議。但是由于客戶端程序的可操作性往往不是那么好，例如多種語言開發環境以及各式各樣的文件管理形式，導致了在數據交互時有時不得不使用文件傳輸和分析或者消息隊列等方法來完成。因此應用程序通信標準應運而生。Web Service作為一款應用程序通信標準，獨立于平臺組建模型和編程語言，無論客戶端和服務器基于什么平臺或者語言，都可以通過它自由使用HTTP協議進行通信。

Web Services可以作為一個基于XML的可編程實體，向外提供被調用的API，也可以被理解為一個可互操作的分布式應用程序平臺，通過HTTP協議進行訪問。在網絡中服務方提供了一個Web Services平臺，該平臺不僅提供相關的網絡服務，而且會提供一種標準來描述它的服務；而客戶可以在網絡中其它任何一點調用該服務，并且可以得到足夠的信息來得知如何調用。另外為了達到互操作性，該服務遠程調用的實現方法必須與平臺和編程語言無關。為了滿足這幾個特點，Web Services采用可擴展的標記語言（XML）表示數據的基本格式[1]，這樣保證無論何種數據都可以被自動轉換成XSD類型而與平臺無關；訪問的RPC方法采用簡單對象訪問協議（SOAP）來調用遠程服務，SOAP協議定義了其消息格式，以及通過HTTP協議的使用方法；至于提供的文檔標準，則使用Web service描述語言（WSDL），用于描述Web service及其函數、參數和返回值。WSDL文檔基于XML構造，因此不僅適合機器和人類閱讀，而且還可以根據某些開發工具實現WSDL文檔和Web服務之間的互相生成。

嵌入式系統，即以應用為中心、以計算機技術為基礎、軟件硬件可裁剪、功能、可靠性、成本、體積、功耗嚴格要求的專用計算機系統。由于憑借嵌入式操作系統（EOS）的優勢，可以進行各個開源軟件在嵌入式平臺上的移植操作，從而實現嵌入式系統更強大的軟件功能；同時由于嵌入式系統有限的處理能力以及存儲資源相對缺乏的特點，在軟件移植過程中需要對相應的軟件進行裁剪。

本文即介紹一款開源的Web Services軟件gSOAP在嵌入式Linux上的移植和裁剪過程。

1 gSOAP的移植

1.1 gSOAP的介紹

gSOAP作為一款開源的Web Services軟件，具有相當多的優點。它利用編譯器提供了一組透明化的SOAP API，對于開發者而言無需了解 SOAP協議實現細節而只要調用這些API即可，因此非常方便；同時gSOAP能夠集成C/C++和Fortran代碼，跨越多個操作系統平臺和語言環境，使用范圍相當廣泛；另外gSOAP包含一個WSDL生成器用來生成web服務描述文檔。通過gSOAP的解釋器和導入器，開發者不需要分析 web服務的細節就可以實現一個客戶端或服務端程序。

gSOAP可以理解為一個C/C++的Web服務協議棧，該協議棧主要包括5部分：網絡傳輸、Web服務調用（消息傳輸）、Web服務描述與注冊（接口描述、發布與發現）、Web服務質量（安全性，可靠性，事務控制）、Web服務工作流（商業流程、事務等）。gSOAP結構如圖1所示。

圖1 gSOAP服務協議棧

1.2 gSOAP的運行過程

雖然gSOAP的服務協議棧比較復雜，但是用gSOAP開發卻非常方便。gSOAP工具包中提供了兩個可執行文件，wsdl2h和soapcpp2。wsdl2h用來解析wsdl文檔生成描述服務的C/C++頭文件，soapcpp2用來解析該頭文件并生成框架代碼。這些頭文件框架如表1所示，解壓gSOAP壓縮包如圖2所示。

表1 gSOAP的頭文件

圖2 gSOAP運行文件內容

除此之外，gSOAP工具包還包含兩個重要的文件：stdsoap2.h和stdsoap2.c/cpp。其中stdsoap2.h是stdsoap2.c/cpp運行時的頭文件，stdsoap2.c/cpp是運行時的C/C++ 庫，帶HTTP/SOAP 解析器和運行時支持例程。通過這兩個文件和上述的框架代碼，開發者可以很方便的進行客戶端/服務器端程序開發[2]。

在服務器端開發中，由開發者輸入C/C++頭文件，并由gSoap編譯器編譯后生成RPC服務框架和數據類型序列化代碼，這些代碼鏈接到服務應用程序之后可以作為提供的Web服務在網上發布。同時gSoap編譯器生成一個WSDL文檔用以描述相應的服務。具體流程如圖3所示。

圖3 gSOAP服務端開發過程

在客戶端開發過程中，gSoap編譯器解析得到的WSDL文檔并創建RPC存根代碼。客戶應用程序則可利用RPC存根和gSoap通信模塊在網絡上觸發SOAP/XML服務函數。具體流程如圖4所示。

圖4 gSOAP客戶端開發過程

gSOAP開發的Web Service服務器端和客戶端的交互模型如圖5所示[3]。其中soapC.c是序列化器和反序列化器，stdsoap2.c是gSOAP工具包提供的HTTP/SOAP解析器。

1.3 gSOAP的移植

（1）下載并解壓gSOAP包

從網站下載壓縮包gsoap_linux_2.7.9e.tar.gz，之后執行解壓命令如下：

（2）修改服務器文件[4]

解壓縮后的文件夾是gsoap-linux-2.7，之后進入該文件夾下samples/calc/目錄。準備將目錄下的服務器程序calcserver移植到ARM嵌入式平臺上。由于ARM平臺IP地址為192.168.0.121，因此對calcserver.c文件作如下修改。將

（3）交叉編譯

由于需要將服務器程序在ARM平臺上移植，因此這里用到交叉編譯。交叉編譯器為armv4l-unknown-linux-gcc，版本為2.95。這里對Makefile文件的calcserver部分作如下修改：

之后執行make命令即可以完成服務器端程序calcserver和客戶端程序calcclient的編譯。

（4）執行

在嵌入式開發板上運行服務器程序：

之后在宿主機上運行客戶端程序，之后可以看到服務器發來的信息：result=15，同時可以看到開發板上信息收到應答：

至此，一個簡單的gSOAP服務應用移植完成。

2 gSOAP的裁剪

嵌入式系統的處理能力較有限且資源相對缺乏，因此對于在其系統平臺上移植的軟件除了功能完備之外也要盡可能精簡。裁剪gSOAP是為了將Web服務協議棧移植到嵌入式系統中，這類似于向嵌入式系統移植TCP/IP協議棧。普通操作系統可支持完整的TCP/IP協議族，但嵌入式系統一般不需要，而是根據其特點及功能來選擇保留部分協議。對于Web服務協議棧來說，其底層通信部分是依靠TCP/IP協議棧的，因此gSOAP也一樣可以裁剪[5]。

裁剪軟件并不是要求裁剪之后的軟件越精簡越好，而是要求從設計的實際產品出發。對于沒有被使用的協議，可以考慮裁剪掉。但需要用到的功能一定要保留或優化。裁剪gSOAP的過程如下所示。

2.1 網絡傳輸層中HTTP協議的裁剪

gSOAP的網絡傳輸層包含多種協議傳輸，如HTTP、FTP和SMTP等。裁剪之后的的web服務只提供網頁瀏覽而不涉及其他內容，因此除了HTTP之外的協議都裁剪掉，而且對于HTTP協議也要進行一定的優化。

超文本傳輸協議（HTTP）是一種為分布式，合作式，多媒體信息系統服務，面向應用層的協議。它是一種通用的，不分狀態（stateless)的協議，除了諸如名稱服務和分布對象管理系統之類的超文本用途外，還可以通過擴展它的請求方式，錯誤代碼和報頭來完成諸多任務。由于HTTP的使用極為廣泛，使得SOAP常常采用HTTP作為底層通訊協議。下面是HTTP協議被裁剪的功能：

（1）HTTP Cookie

HTTP Cookie是在HTTP連接期間瀏覽器與CGI程序之間傳遞的信息。在系統中沒有涉及到瀏覽器與CGI程序之間的通信，因此該功能可以被裁剪。

（2）HTTP Chunked編碼

有時服務器生成HTTP回應是無法確定消息大小的，此時服務器一般采用Chunked編碼，需要實時生成消息長度。而在嵌入式系統中，HTTP回應的消息長度是可以確定的而且比較小，因此可以不支持HTTP的Chunked編碼方式。

（3）HTTP Proxy

主要功能是用戶通過網上的代理服務器獲取網絡信息。嵌入式系統一般在客戶與服務器勿需設置代理服務器，因此可以取消代理。

（4）HTTP Keep-Alive

Keep-Alive功能使客戶端到服務器端的連接持續有效，客戶端為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP要在客戶端和服務器端分配TCP緩沖區并維持TCP變量。當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。但對于嵌入式設備來說，系統資源非常有限，因此每次通信完成后應立即釋放連接，盡量避免長期占用系統資源。

2.2 消息傳輸層中XML協議的裁剪

gSOAP的消息傳輸層包括XML協議和SOAP協議以及其他一些服務。這里裁剪掉除XML和SOAP的其他協議，并對XML和SOAP進行一定的優化。對XML的優化如下：

XML（eXtensible Markup Language，可擴展標記語言）是Internet上數據表示和數據交換的新標準。它是ISO的通用標記語言標準的一個簡化子集。XML關注信息本身，是Web上表示結構化信息的一種標準文本格式。與傳統的注重頁面信息顯示的HTML（Hypertext Markup Language,超文本鏈接標示語言）相比，關注于內容的XML具有以下諸多優點：良好的可擴展性，語言簡單有效，可自行定義標記；內容與形式的分離，主要刻畫數據內容，不考慮顯示效果；有嚴格的語法要求，便于分析統一和與數據庫信息轉換；便于傳輸，為純文本形式，可通過Http協議直接傳輸，可跨越防火墻等等。gSOAP工具包中提供了XML解析器，但是對于具體的應用而言，不必對XML協議完全解析，經過分析gSOAP源代碼，可以對XML協議作如下的精簡：

（1）精簡編碼方式

XML文檔一般采用UTF-8編碼方式，UTF-8可以處理目前世界上使用的每一種文字。對于嵌入式系統而言采用UTF-8編碼方式已經足夠了。因此對于其他的編碼方式，解析器可以不支持。

（2）CDATA部件

如果一個xml元素的文本中包含了大量非法的xml字符如"＜"和"&"字符，那么這個XML元素就可以被定義為一個CDATA部件。在CDATA部件之內的文本會被解析器忽略，從而避免了大量的實體引用。然而對本系統而言，SOAP消息中的XML文檔是由gSOAP生成的，通過分析soapcpp2生成的*.req.xml和*.res.xml可以看出該文檔中并沒有包括CDATA部件，所以XML解析器不必解析CDATA部件。

2.3 消息傳輸層中SOAP協議的裁剪

SOAP（Simple Object Access Protocol）簡單對象訪問協議，是在分散或分布式的環境中交換信息的簡單的協議。SOAP 協議定義了用于在系統之間進行通訊的標準 XML消息的格式。由于該消息格式已標準化并基于 XML 標準，因此可使用 SOAP 在多種計算機體系結構、語言和操作系統之間進行通訊。SOAP協議包括四個部分：SOAP封裝(envelop)，封裝定義了一個描述消息中的內容是什么、是誰發送的、誰應當接受并處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用于表示應用程序需要使用的數據類型的實例；SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定；SOAP綁定（binding），使用底層協議交換信息。對于某種具體應用而言，不可能運用了SOAP的所有特性。此時有必要屏蔽掉多余的特性，具體精簡的內容如下：

（1）可選的SOAP頭

SOAP協議規范說明SOAP消息包括 3 部分：一個必須的根元素＜Envelope＞、一個可選的SOAP頭＜Header＞和一個必須的SOAP體＜Body＞。SOAP頭的作用就是，提供一個可伸縮的機制，用于在分散的模塊化的環境下擴展SOAP消息，而通訊雙方并不需要有預先的約定。對于嵌入式系統來說既然SOAP頭是可選的，因此可以將SOAP頭裁剪掉。

（2）數據編碼規則

SOAP編碼可以簡短地描述成簡單值和復合值的集合。簡單值可以是簡單類型，如整型、浮點型和字符型，或者是XML架構規范第2部中定義的內置類型。復合值包括結構、數組和XML架構制定組定義的復雜類型。gSOAP提供了對上述數據類型的序列化和反序列化規則。在本系統中使用到的數據類型包括整型、枚舉和結構。因此在gSOAP中保留以上類型的序列化和反序列化規則，而對于其他的數據類型諸如浮點型、數組等不支持其序列化和反序列化。

（3）附件的機制

利用SOAP消息傳輸圖像等二進制數據時，一種最簡單的方法是使用類似Base64的方式對其進行編碼，把它轉變成對XML安全的一串字符然后放入一條基于XML的消息中傳送。然后這并不是一個有效的方法，因為對二進制數據進行編碼和解碼會造成相當大的處理開銷，從而影響了應用程序的性能。一般嵌入式系統，會涉及到了二進制圖像數據的傳輸，起初嘗試用MTOM和XOP進行附件傳輸，但后來發現基于SOAP消息的附件傳輸，始終不如用socket傳輸的速度快。對于一個要求獲取實時視頻數據的系統而言，采用基于SOAP消息的附件傳輸，并不是一個好的選擇。因此裁剪了gSOAP中對SOAP附件機制的實現。

2.4 其他各層的裁剪

對于除了網絡傳輸層和Web服務調用層之外的其他 3個層，要求裁剪之后的系統就不用很支持了。例如在Web服務描述和注冊層中，除了保留WSDL協議之外，對于UDDI模塊則可以考慮取消。并不需要將Web服務發布到UDDI注冊中心，而是采用簡單的分布式發現方式（WS-Inspection），由客戶端直接向服務提供者請求一個服務描述的副本，根據此副本進行Web Service客戶端開發；Web服務質量層在本系統中不需要，因此可以全部裁剪掉；而Web服務工作流層也相應的有所裁剪。精簡后的Web服務協議棧如圖6所示。之后移植gSOAP實際上是將精簡之后的Web服務協議棧移植到嵌入式系統中，移植方法同1.3節。

除此之外，gSOAP還提供了一些額外的功能，如支持多種系統平臺、DOM解析庫、利用zlib庫壓縮數據功能、Plug-in擴展功能、FastCGI以及支持SSL(安全套接層協議)等。在移植的過程中可以裁掉。裁剪前后關于stdsoap2.c文件大小的比較如圖7所示。之后通過交叉編譯器對同一工程編譯生成的可執行程序也會有所差別，例如對直流電機服務器程序dcmserver.c編譯前后比較如圖8所示。

圖6 精簡后的gSOAP服務協議棧

圖7 裁剪前后stdsoap2.c文件比較

圖8 裁剪前后生成程序比較

通過比較可以發現經過裁剪后減小了可執行程序的存儲空間，更好的滿足嵌入式系統的需求。而構建于精簡Web服務協議棧之上的應用系統正常運行，沒有發現任何異常。

3 總結

隨著網絡技術、電子商務技術的發展，以及可擴展標記語言XML作為一種標準的數據格式被廣泛的接受，一種新的技術構架Web Service技術已迅速成為應用集成發展的重點。由于Web Service技術建立在標準性與開放性基礎之上，從而徹底打破了以前封閉式的實現方法。通過Web Service技術，使用不同語言開發、運行在不同平臺上的客戶可以無縫的獲取所需的應用，從而達到資源效率的最大化。

本文以gSOAP這款比較流行的Web Service軟件作為研究對象，詳細講述了其基于Embedded Linux的裁剪和移植過程。由于嵌入式系統特定的應用和資源相對貧乏的特點，對gSOAP進行了有針對性地裁剪。裁剪之后的gSOAP軟件不僅占用存儲空間小，且提高了應用系統的性能。

[1]Robert van Engelen.An XML Web Services Development Environment for Embedded[OL].http://websrv.CS.fsu/edu/enge1en/casesO3.htm1.

[2]夏亮,祖一康等.基于嵌入式Web Services的系統集成方案[J].單片機與嵌入式系統應用,2008(3):7-9.

[3]Robert van Engelen.Code Generation Techniques for Developing LightWeight XML Web Services for EmbeddedDevices[OL].http://websrv.CS.fsu.edu/～engelen/.

[4]北京博創興業科技有限公司.UP-NETARM2410-S(Linux)嵌入式系統實驗指導書[K].2 0 0 6.http://www.up-tech.com.

[5]許佑駿,王力生.嵌入式Service系統應用研究[J].計算機研究,2004(1):100-102.