嵌入式環(huán)境下Web Service技術的實現(xiàn)

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

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

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

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

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

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

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

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