基于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.