摘要：為了解決嵌入式系統(tǒng)與其他異構(gòu)系統(tǒng)之間互聯(lián)和集成的難題，提出了Web Seivice技術(shù)在低端嵌入式設(shè)備上的實(shí)現(xiàn)方法。以ARM Cort ex-M3微處理器為核心，基于小型實(shí)時(shí)操作系統(tǒng)和嵌入式TCP／IP協(xié)議棧，詳細(xì)闡述了Web Service的實(shí)現(xiàn)過(guò)程，包括HTTP接收．XML與SOAP協(xié)議的解析，以及同具體服務(wù)實(shí)現(xiàn)的綁定，并針對(duì)嵌入式環(huán)境下資源受限的特點(diǎn)。給出了相應(yīng)的優(yōu)化方法。使用專用測(cè)試軟件進(jìn)行的壓力測(cè)試表明，該實(shí)現(xiàn)運(yùn)行穩(wěn)定，具有良好的可行性。
關(guān)鍵詞：Web Service；XML；SOAP；嵌入式系統(tǒng)

0 引言
    近年來(lái)隨著網(wǎng)絡(luò)化概念的不斷推廣，嵌入式系統(tǒng)也擺脫了以往“信息孤島”的封閉局面，相互之間逐漸形成了分布式的協(xié)作關(guān)系。然而嵌入式系統(tǒng)在網(wǎng)絡(luò)的應(yīng)用層上常常采用自定義的傳輸協(xié)議，加之各系統(tǒng)之間巨大的平臺(tái)差異性，給系統(tǒng)間的互訪以及企業(yè)級(jí)信息的集成帶來(lái)了困難。Web Service技術(shù)具有良好的跨平臺(tái)和松耦合特性，能夠?qū)崿F(xiàn)不同平臺(tái)的分布式系統(tǒng)之間的無(wú)縫集成，降低了企業(yè)進(jìn)行設(shè)備升級(jí)和服務(wù)重組時(shí)的投入。本文以32位微處理器ARM Cortex-M3為核心，借助于嵌入式TCP／IP協(xié)議棧和實(shí)時(shí)操作系統(tǒng)，在嵌入式環(huán)境下實(shí)現(xiàn)了Web Ser vice技術(shù)。

1 Web Service與SOAP協(xié)議
    Web Service是網(wǎng)絡(luò)化應(yīng)用的一種，可以將其看成一種函數(shù)調(diào)用，只不過(guò)這個(gè)函數(shù)的實(shí)體存在于某個(gè)服務(wù)器上，而對(duì)函數(shù)的調(diào)用在客戶端進(jìn)行，客戶端只要接入裝有服務(wù)的機(jī)器所在的網(wǎng)絡(luò)即可調(diào)用函數(shù)。為了實(shí)現(xiàn)這種遠(yuǎn)程調(diào)用，需要對(duì)傳輸?shù)臄?shù)據(jù)格式采取一些約定措施．簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(Simple Object Access Protocol，SOAP)很好地應(yīng)對(duì)了這種需求。SOAP協(xié)議以XML形式提供了一個(gè)簡(jiǎn)單、輕量的機(jī)制，用于在分布環(huán)境中交換結(jié)構(gòu)化信息。SOAP本身并沒(méi)有定義任何應(yīng)用程序語(yǔ)義，如編程模型或特定語(yǔ)義的實(shí)現(xiàn)；實(shí)際上它通過(guò)提供一個(gè)模塊化的封包模型和在模塊中進(jìn)行數(shù)據(jù)編碼的方法，定義了一個(gè)簡(jiǎn)單的表示應(yīng)用程序語(yǔ)義的機(jī)制。
    SOAP消息是由Envelope，Header和Body三部分組成的XML文檔，其中Envelope是SOAP消息的根元素，必須在SOAP消息中出現(xiàn)；可選的Hea der元素包含有關(guān)SOAP消息的應(yīng)用程序?qū)Ｓ眯畔?；必需的Body元素包含打算傳送到消息最終端點(diǎn)的實(shí)際SOAP消息。最后，為了進(jìn)行基于SOAP的遠(yuǎn)程調(diào)用，需要一種低級(jí)傳輸協(xié)議。SOAP規(guī)范允許使用HTTP，SMTP甚至原始的TCP／IP套接字，其中HTTP協(xié)議最為常用。

2 Web Service在嵌入式環(huán)境下的實(shí)現(xiàn)
2．1 底層軟硬件結(jié)構(gòu)
    本文中所使用的硬件基于ST公司推出的ARMCortex-M3 32位微處理器STM32F107VC。Cortex-M3是針對(duì)價(jià)格敏感但又有高系統(tǒng)效能需求的嵌入式應(yīng)用而設(shè)計(jì)的ARM內(nèi)核，作為ARM7的后繼者，大刀闊斧地改革了設(shè)計(jì)架構(gòu)，顯著簡(jiǎn)化了編程和調(diào)試的復(fù)雜度，處理能力也更加強(qiáng)大。ST M32F107VC工作頻率最高為72 MHz，帶有256 KB的片上FLASH和64 KB的SRAM，以及以太網(wǎng)MAC控制器，因此外接一片PHY芯片RTL8201，完成與以太網(wǎng)的物理通信。
    為了達(dá)到實(shí)時(shí)任務(wù)管理，本文選用嵌入式實(shí)時(shí)操作系統(tǒng)FreeRTOS和輕量級(jí)TCP／IP協(xié)議棧1wIP組成底層軟件開(kāi)發(fā)平臺(tái)。FreeRTOS作為一個(gè)免費(fèi)開(kāi)源的小型實(shí)時(shí)內(nèi)核，主要用于建立和管理各個(gè)模塊的任務(wù)；1wIP則為數(shù)據(jù)的TCP／IP封裝提供了一個(gè)良好的軟件基礎(chǔ)。
2．2 SOAP消息的處理
    目前已經(jīng)有許多成熟的SOAP工具，例如針對(duì)C++的gSOAP、針對(duì)Java的kSOAP等，但是這些實(shí)現(xiàn)方案均是為PC機(jī)或者帶有高級(jí)操作系統(tǒng)的嵌入式系統(tǒng)設(shè)計(jì)的，對(duì)資源的消耗較多。對(duì)于低端的嵌入式環(huán)境，需要更輕量型的處理方法。
    由前文可知，SOAP可以簡(jiǎn)單的理解為HTTP+XML+遠(yuǎn)程調(diào)用規(guī)則，因此SOAP消息的處理也分為3步：HTTP協(xié)議的實(shí)現(xiàn)、XML解析、具體服務(wù)實(shí)現(xiàn)。其總體結(jié)構(gòu)如圖1所示。

[!--empirenews.page--]
    SOAP在HTTP上的遠(yuǎn)程調(diào)用的具體實(shí)現(xiàn)過(guò)程大致如下：客戶端通過(guò)SOAP工具生成基于XML文檔的SOAP消息，在該SOAP消息里包含有客戶請(qǐng)求的服務(wù)名稱及調(diào)用服務(wù)程序所需的參數(shù)，并使用HTTPPOST方法通過(guò)網(wǎng)絡(luò)向應(yīng)用程序所在的服務(wù)端發(fā)送SOAP請(qǐng)求；另一方面，當(dāng)服務(wù)端接到HTTP信息之后，又從中提取出SOAP消息，啟動(dòng)XML文檔解析器進(jìn)行解析，獲取客戶需要調(diào)用的方法名及其參數(shù)，以此來(lái)調(diào)用相應(yīng)的服務(wù)程序，之后以類似的方法將運(yùn)行結(jié)果打包成SOAP消息返回給客戶，完成應(yīng)用程序的遠(yuǎn)程調(diào)用。
2．2．1 HTTP協(xié)議的簡(jiǎn)單實(shí)現(xiàn)
    HTTP是基于請(qǐng)求／響應(yīng)模式的協(xié)議，客戶端的通信過(guò)程一般分為4個(gè)步驟：建立連接、發(fā)送請(qǐng)求消息、接收響應(yīng)信息、關(guān)閉連接。HTTP定義了眾多請(qǐng)求方法(Method)，如GET，POST，HEAD，DELETE等，由于SOAP主要使用POST方法來(lái)發(fā)送請(qǐng)求，因此HTTP的實(shí)現(xiàn)集中在POST方法上。SOAP協(xié)議中規(guī)定POST請(qǐng)求至少包含兩個(gè)HTTP頭，Content-Type(定義MIME類型)和Content-Length(定義消息的長(zhǎng)度)。
例如：
    POST／test HTTP／1.1
    Content-Type:application／soap+xml；
    Content-Length：250
    如圖2所示，程序利用1wIP提供的API創(chuàng)建一個(gè)監(jiān)聽(tīng)連接，綁定到HTTP的80號(hào)熟知端口上，當(dāng)接收到POST請(qǐng)求時(shí)檢查必要的HTTP頭，之后開(kāi)始接收HTTP正文(SOAP請(qǐng)求)，并將接收到的請(qǐng)求存放在預(yù)先開(kāi)辟的緩沖區(qū)中，再交由XML解析器處理。為了節(jié)省資源，將SOAP消息解析和HTTP接收放在同一線程，一次只處理一個(gè)SOAP請(qǐng)求，因此整個(gè)解析過(guò)程只需要一個(gè)緩沖區(qū)。同時(shí)開(kāi)啟連接超時(shí)機(jī)制，如果客戶端連接后長(zhǎng)時(shí)間無(wú)動(dòng)作，接收程序?qū)⑶袛噙B接，避免后續(xù)請(qǐng)求無(wú)法得到響應(yīng)。

[!--empirenews.page--]
2．2．2 XML解析
    SOAP消息是由XML語(yǔ)言組成的，因此對(duì)XML的解析是處理SOAP消息的一個(gè)重點(diǎn)。當(dāng)今有2種流行的XML解析API，它們是DOM(Document Obj ect Model)和SAX(Simple API for XML)，盡管這兩種方法都能用來(lái)解析XML數(shù)據(jù)，但相互間卻有很多本質(zhì)的不同：DOM一次性把整個(gè)XML文檔讀入內(nèi)存并建立完整的樹(shù)結(jié)構(gòu)，而SAX則基于事件驅(qū)動(dòng)模型，一次只讀取一個(gè)XML元素，每當(dāng)遇到一個(gè)讀取事件時(shí)就會(huì)觸發(fā)一個(gè)事件處理器。兩種方法各有優(yōu)缺點(diǎn)：DOM在處理單個(gè)元素之前必須把其他所有的元素都讀入內(nèi)存建立樹(shù)結(jié)構(gòu)，這既費(fèi)時(shí)間又費(fèi)內(nèi)存，在這方面SAX的性能
更為優(yōu)異，但DOM一旦建立樹(shù)結(jié)構(gòu)之后，就可以方便地處理文檔中的任意元素，因?yàn)檎麄€(gè)XML結(jié)構(gòu)都在內(nèi)存里，而SAX則必須從頭逐個(gè)解析XML文檔每一個(gè)元素，直到需要的那個(gè)元素。
    考慮到SOAP消息的解析是一次性的過(guò)程，不需要進(jìn)行元素的隨機(jī)訪問(wèn)，而且嵌入式環(huán)境下資源有限，為此采用SAX做為XML的解析方式。定義以下結(jié)構(gòu)體用來(lái)存儲(chǔ)節(jié)點(diǎn)結(jié)構(gòu)。
   
    另外建立一個(gè)列表用來(lái)存儲(chǔ)XML文檔中聲明的命名空間，避免XML文檔里的元素名或?qū)傩悦嗷ブg可能會(huì)發(fā)生的語(yǔ)義沖突。在XML文檔的解析過(guò)程中，保留當(dāng)前節(jié)點(diǎn)及其父節(jié)點(diǎn)的結(jié)構(gòu)體，除此之外的節(jié)點(diǎn)在讀取完畢后立即釋放其占用的資源，必要時(shí)還可以關(guān)閉對(duì)節(jié)點(diǎn)屬性的解析，進(jìn)一步降低內(nèi)存消耗。當(dāng)遇到新的讀取事件時(shí)(節(jié)點(diǎn)開(kāi)始、節(jié)點(diǎn)結(jié)束、發(fā)現(xiàn)節(jié)點(diǎn)值)，將此次事件的相關(guān)信息作為參數(shù)傳入回調(diào)函數(shù)，在回調(diào)函數(shù)中對(duì)節(jié)點(diǎn)信息進(jìn)行處理：
   
2．2．3 具體服務(wù)實(shí)現(xiàn)
    為了方便查找服務(wù)，程序里將所有支持的服務(wù)函數(shù)的名稱以及對(duì)應(yīng)的命名空間預(yù)先保存在一個(gè)列表中。當(dāng)進(jìn)入XML解析的回調(diào)函數(shù)后，根據(jù)XML節(jié)點(diǎn)的節(jié)點(diǎn)名稱以及命名空間，首先試圖從列表中搜索本次SOAP消息所請(qǐng)求的服務(wù)，如果所請(qǐng)求的服務(wù)函數(shù)存在，則將XML節(jié)點(diǎn)信息傳入該服務(wù)函數(shù)對(duì)應(yīng)的初始化函數(shù)，完成對(duì)服務(wù)函數(shù)的參數(shù)列表的初始化，為之后的服務(wù)函數(shù)執(zhí)行做好準(zhǔn)備。圖3給出了該過(guò)程的程序框圖。XML解析完畢后退出XML解析器，此時(shí)服務(wù)函數(shù)也已經(jīng)完成初始化，直接調(diào)用服務(wù)函數(shù)的執(zhí)行部分，并將結(jié)果打包成SOAP格式發(fā)送回客戶端。鑒于動(dòng)態(tài)生成XML文檔需要耗費(fèi)較多的資源，程序中為每個(gè)服務(wù)函數(shù)預(yù)存了一個(gè)模板，模板中已經(jīng)定義好了回復(fù)消息的整體結(jié)構(gòu)，僅需在服務(wù)函數(shù)被實(shí)際調(diào)用后往模板中填入結(jié)果即可，另外可以在發(fā)送回復(fù)消息的過(guò)程中復(fù)用之前的接收緩沖區(qū)，這樣一來(lái)同時(shí)節(jié)省了處理時(shí)間和資源消耗。

[!--empirenews.page--]
2．3 性能測(cè)試
    由于Web Service函數(shù)是被其他程序調(diào)用的，一般不會(huì)提供界面讓用戶或測(cè)試人員直接使用，這造成了測(cè)試上的困難。由eviware公司推出的Web Service測(cè)試軟件soapUI極大的改變了這一局面，在soapUI中通過(guò)簡(jiǎn)單的操作即可完成復(fù)雜的測(cè)試，不需要了解底層的通訊細(xì)節(jié)，大大減輕了工作量。為了測(cè)試系統(tǒng)的性能，將STM32F107VC接入局域網(wǎng)之中，并開(kāi)啟A／D采樣，客戶端通過(guò)Web Service函數(shù)ReadValue獲取指定通道的A／D采樣值(最大值、最小值、平均值)。SOAP消息的具體請(qǐng)求和響應(yīng)示例如下：
   
     在soapUI中模擬多個(gè)用戶線程對(duì)系統(tǒng)進(jìn)行90 min的壓力測(cè)試，每個(gè)線程每次的請(qǐng)求間隔隨機(jī)分布在0．5～1 s之間，圖4給出了10個(gè)用戶線程下系統(tǒng)的平均響應(yīng)時(shí)間曲線，其中橫軸表示經(jīng)過(guò)的時(shí)間(單位：s)，縱軸表示線程個(gè)數(shù)以及SOAP請(qǐng)求平均響應(yīng)時(shí)間(單位：ms)。由于系統(tǒng)同一時(shí)間只處理一個(gè)SOAP請(qǐng)求，當(dāng)多個(gè)用戶線程同時(shí)連接時(shí)，未處理的請(qǐng)求會(huì)被排隊(duì)，其處理時(shí)間也會(huì)相應(yīng)延長(zhǎng)。受網(wǎng)絡(luò)環(huán)境變化和連接并發(fā)情況的影響，平均響應(yīng)時(shí)間會(huì)出現(xiàn)波動(dòng)，在10個(gè)線程的情況下平均響應(yīng)時(shí)間介于30～50 ms之間，整個(gè)系統(tǒng)保持穩(wěn)定，沒(méi)有內(nèi)存泄露或者連接丟失現(xiàn)象發(fā)生。

3 結(jié)語(yǔ)
    本文基于32位微處理器ARM Cortex-M3以及小型實(shí)時(shí)操作系統(tǒng)FreeRTOS，在資源極其受限的情況下完成了XML語(yǔ)言的解析以及SOAP和HTTP協(xié)議的綁定，實(shí)現(xiàn)了不易實(shí)現(xiàn)的嵌入式Web Service技術(shù)。XML語(yǔ)言強(qiáng)大的表達(dá)能力和SOAP協(xié)議的靈活性，有效地解決了嵌入式設(shè)備與異構(gòu)平臺(tái)間的信息交換問(wèn)題，大大降低了系統(tǒng)集成的難度。隨著網(wǎng)絡(luò)化思想的進(jìn)一步深入以及硬件成本的逐步下降，面向服務(wù)的編程思想所代表的新一代軟件架構(gòu)技術(shù)會(huì)逐漸滲透到越來(lái)越多的嵌入式系統(tǒng)當(dāng)中。