嵌入式环境下Web Service技术的实现

摘要：为了解决嵌入式系统与其他异构系统之间互联和集成的难题，提出了Web Seivice技术在低端嵌入式设备上的实现方法。以ARM Cort ex-M3微处理器为核心，基于小型实时操作系统和嵌入式TCP／IP协议栈，详细阐述了Web Service的实现过程，包括HTTP接收．XML与SOAP协议的解析，以及同具体服务实现的绑定，并针对嵌入式环境下资源受限的特点。给出了相应的优化方法。使用专用测试软件进行的压力测试表明，该实现运行稳定，具有良好的可行性。
关键词：Web Service；XML；SOAP；嵌入式系统

0 引言
    近年来随着网络化概念的不断推广，嵌入式系统也摆脱了以往“信息孤岛”的封闭局面，相互之间逐渐形成了分布式的协作关系。然而嵌入式系统在网络的应用层上常常采用自定义的传输协议，加之各系统之间巨大的平台差异性，给系统间的互访以及企业级信息的集成带来了困难。Web Service技术具有良好的跨平台和松耦合特性，能够实现不同平台的分布式系统之间的无缝集成，降低了企业进行设备升级和服务重组时的投入。本文以32位微处理器ARM Cortex-M3为核心，借助于嵌入式TCP／IP协议栈和实时操作系统，在嵌入式环境下实现了Web Ser vice技术。

1 Web Service与SOAP协议
    Web Service是网络化应用的一种，可以将其看成一种函数调用，只不过这个函数的实体存在于某个服务器上，而对函数的调用在客户端进行，客户端只要接入装有服务的机器所在的网络即可调用函数。为了实现这种远程调用，需要对传输的数据格式采取一些约定措施．简单对象访问协议(Simple Object Access Protocol，SOAP)很好地应对了这种需求。SOAP协议以XML形式提供了一个简单、轻量的机制，用于在分布环境中交换结构化信息。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个模块化的封包模型和在模块中进行数据编码的方法，定义了一个简单的表示应用程序语义的机制。
    SOAP消息是由Envelope，Header和Body三部分组成的XML文档，其中Envelope是SOAP消息的根元素，必须在SOAP消息中出现；可选的Hea der元素包含有关SOAP消息的应用程序专用信息；必需的Body元素包含打算传送到消息最终端点的实际SOAP消息。最后，为了进行基于SOAP的远程调用，需要一种低级传输协议。SOAP规范允许使用HTTP，SMTP甚至原始的TCP／IP套接字，其中HTTP协议最为常用。

2 Web Service在嵌入式环境下的实现
2．1 底层软硬件结构
    本文中所使用的硬件基于ST公司推出的ARMCortex-M3 32位微处理器STM32F107VC。Cortex-M3是针对价格敏感但又有高系统效能需求的嵌入式应用而设计的ARM内核，作为ARM7的后继者，大刀阔斧地改革了设计架构，显著简化了编程和调试的复杂度，处理能力也更加强大。ST M32F107VC工作频率最高为72 MHz，带有256 KB的片上FLASH和64 KB的SRAM，以及以太网MAC控制器，因此外接一片PHY芯片RTL8201，完成与以太网的物理通信。
    为了达到实时任务管理，本文选用嵌入式实时操作系统FreeRTOS和轻量级TCP／IP协议栈1wIP组成底层软件开发平台。FreeRTOS作为一个免费开源的小型实时内核，主要用于建立和管理各个模块的任务；1wIP则为数据的TCP／IP封装提供了一个良好的软件基础。
2．2 SOAP消息的处理
    目前已经有许多成熟的SOAP工具，例如针对C++的gSOAP、针对Java的kSOAP等，但是这些实现方案均是为PC机或者带有高级操作系统的嵌入式系统设计的，对资源的消耗较多。对于低端的嵌入式环境，需要更轻量型的处理方法。
    由前文可知，SOAP可以简单的理解为HTTP+XML+远程调用规则，因此SOAP消息的处理也分为3步：HTTP协议的实现、XML解析、具体服务实现。其总体结构如图1所示。

[!--empirenews.page--]
    SOAP在HTTP上的远程调用的具体实现过程大致如下：客户端通过SOAP工具生成基于XML文档的SOAP消息，在该SOAP消息里包含有客户请求的服务名称及调用服务程序所需的参数，并使用HTTPPOST方法通过网络向应用程序所在的服务端发送SOAP请求；另一方面，当服务端接到HTTP信息之后，又从中提取出SOAP消息，启动XML文档解析器进行解析，获取客户需要调用的方法名及其参数，以此来调用相应的服务程序，之后以类似的方法将运行结果打包成SOAP消息返回给客户，完成应用程序的远程调用。
2．2．1 HTTP协议的简单实现
    HTTP是基于请求／响应模式的协议，客户端的通信过程一般分为4个步骤：建立连接、发送请求消息、接收响应信息、关闭连接。HTTP定义了众多请求方法(Method)，如GET，POST，HEAD，DELETE等，由于SOAP主要使用POST方法来发送请求，因此HTTP的实现集中在POST方法上。SOAP协议中规定POST请求至少包含两个HTTP头，Content-Type(定义MIME类型)和Content-Length(定义消息的长度)。
例如：
    POST／test HTTP／1.1
    Content-Type:application／soap+xml；
    Content-Length：250
    如图2所示，程序利用1wIP提供的API创建一个监听连接，绑定到HTTP的80号熟知端口上，当接收到POST请求时检查必要的HTTP头，之后开始接收HTTP正文(SOAP请求)，并将接收到的请求存放在预先开辟的缓冲区中，再交由XML解析器处理。为了节省资源，将SOAP消息解析和HTTP接收放在同一线程，一次只处理一个SOAP请求，因此整个解析过程只需要一个缓冲区。同时开启连接超时机制，如果客户端连接后长时间无动作，接收程序将切断连接，避免后续请求无法得到响应。

[!--empirenews.page--]
2．2．2 XML解析
    SOAP消息是由XML语言组成的，因此对XML的解析是处理SOAP消息的一个重点。当今有2种流行的XML解析API，它们是DOM(Document Obj ect Model)和SAX(Simple API for XML)，尽管这两种方法都能用来解析XML数据，但相互间却有很多本质的不同：DOM一次性把整个XML文档读入内存并建立完整的树结构，而SAX则基于事件驱动模型，一次只读取一个XML元素，每当遇到一个读取事件时就会触发一个事件处理器。两种方法各有优缺点：DOM在处理单个元素之前必须把其他所有的元素都读入内存建立树结构，这既费时间又费内存，在这方面SAX的性能
更为优异，但DOM一旦建立树结构之后，就可以方便地处理文档中的任意元素，因为整个XML结构都在内存里，而SAX则必须从头逐个解析XML文档每一个元素，直到需要的那个元素。
    考虑到SOAP消息的解析是一次性的过程，不需要进行元素的随机访问，而且嵌入式环境下资源有限，为此采用SAX做为XML的解析方式。定义以下结构体用来存储节点结构。
   
    另外建立一个列表用来存储XML文档中声明的命名空间，避免XML文档里的元素名或属性名相互之间可能会发生的语义冲突。在XML文档的解析过程中，保留当前节点及其父节点的结构体，除此之外的节点在读取完毕后立即释放其占用的资源，必要时还可以关闭对节点属性的解析，进一步降低内存消耗。当遇到新的读取事件时(节点开始、节点结束、发现节点值)，将此次事件的相关信息作为参数传入回调函数，在回调函数中对节点信息进行处理：
   
2．2．3 具体服务实现
    为了方便查找服务，程序里将所有支持的服务函数的名称以及对应的命名空间预先保存在一个列表中。当进入XML解析的回调函数后，根据XML节点的节点名称以及命名空间，首先试图从列表中搜索本次SOAP消息所请求的服务，如果所请求的服务函数存在，则将XML节点信息传入该服务函数对应的初始化函数，完成对服务函数的参数列表的初始化，为之后的服务函数执行做好准备。图3给出了该过程的程序框图。XML解析完毕后退出XML解析器，此时服务函数也已经完成初始化，直接调用服务函数的执行部分，并将结果打包成SOAP格式发送回客户端。鉴于动态生成XML文档需要耗费较多的资源，程序中为每个服务函数预存了一个模板，模板中已经定义好了回复消息的整体结构，仅需在服务函数被实际调用后往模板中填入结果即可，另外可以在发送回复消息的过程中复用之前的接收缓冲区，这样一来同时节省了处理时间和资源消耗。

[!--empirenews.page--]
2．3 性能测试
    由于Web Service函数是被其他程序调用的，一般不会提供界面让用户或测试人员直接使用，这造成了测试上的困难。由eviware公司推出的Web Service测试软件soapUI极大的改变了这一局面，在soapUI中通过简单的操作即可完成复杂的测试，不需要了解底层的通讯细节，大大减轻了工作量。为了测试系统的性能，将STM32F107VC接入局域网之中，并开启A／D采样，客户端通过Web Service函数ReadValue获取指定通道的A／D采样值(最大值、最小值、平均值)。SOAP消息的具体请求和响应示例如下：
   
     在soapUI中模拟多个用户线程对系统进行90 min的压力测试，每个线程每次的请求间隔随机分布在0．5～1 s之间，图4给出了10个用户线程下系统的平均响应时间曲线，其中横轴表示经过的时间(单位：s)，纵轴表示线程个数以及SOAP请求平均响应时间(单位：ms)。由于系统同一时间只处理一个SOAP请求，当多个用户线程同时连接时，未处理的请求会被排队，其处理时间也会相应延长。受网络环境变化和连接并发情况的影响，平均响应时间会出现波动，在10个线程的情况下平均响应时间介于30～50 ms之间，整个系统保持稳定，没有内存泄露或者连接丢失现象发生。

3 结语
    本文基于32位微处理器ARM Cortex-M3以及小型实时操作系统FreeRTOS，在资源极其受限的情况下完成了XML语言的解析以及SOAP和HTTP协议的绑定，实现了不易实现的嵌入式Web Service技术。XML语言强大的表达能力和SOAP协议的灵活性，有效地解决了嵌入式设备与异构平台间的信息交换问题，大大降低了系统集成的难度。随着网络化思想的进一步深入以及硬件成本的逐步下降，面向服务的编程思想所代表的新一代软件架构技术会逐渐渗透到越来越多的嵌入式系统当中。