soap協議范文
時間：2023-03-17 02:28:28
導語：如何才能寫好一篇soap協議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
關鍵詞：J2ME soap XML嵌入式系統
1 引言
J2ME作為嵌入式系統應用平臺得到了迅速的發展，JAVA語言固有的平臺無關性使得基于J2ME平臺的嵌入式應用系統具有廣闊的前景。受限于嵌入式設備及消費類電器硬件條件的限制，J2ME平臺提供的功能有限，如何能夠在有限的資源下拓展J2ME的功能，使得J2ME平臺能夠處理SOAP協議是本文研究的重點。
目前企業應用正在向面向WEB服務的SOA架構轉變，嵌入式系統與企業應用系統的連接目前還處于TCP/IP協議、HTTP協議等比較初級的階段。隨著企業應用系統提供的WEB服務日益廣泛和成熟，需要J2ME平臺提供處理SOAP協議的需求也越來越多。
SOA架構是目前企業應用系統廣泛部署的架構，實現SOA的關鍵問題之一就是對SOAP協議的支持。本文分析了在J2ME平臺中實現SOAP協議處理遇到的問題，提出了相應的解決方案。
2 j2ME介紹[1] [2] [3]
J2ME（Java 2 Platform Micro Edition）是為無線電子市場所設計的JAVA平臺，包括JVM規范和API規范。J2ME 定義了一套類庫和虛擬機技術，這些技術可以使用戶、服務提供商和設備制造商通過物理（有線）連接或無線連接，按照需要隨時使用豐富的應用程序。J2ME同時提供了Java語言一貫的跨平臺性和安全性。
為了支持用戶和嵌入式市場提出的靈活性和可定制性要求，J2ME被設計得更加模塊化和可縮放化。J2ME在設備原有的操作系統上建造了3層軟件來實現這種要求：
1．JVM層：這層基于宿主操作系統，按照某一種J2ME的配置實現了JVM。
2．配置層：這層對于用戶可見度要低一些，但對簡表層非常重要。它針對不同市場的需求，定義了Java虛擬機的最小功能集合和Java類庫的最小集合。在J2ME設備中，JVM與配置層緊密相連，它們體現了每一類設備的基本功能。
3．簡表層：這層對于用戶和應用程序提供者來說是最常見的。它針對特定市場的需求，定義了Java虛擬機的最小功能集合和Java類庫的最小集合。
J2ME組件都圍繞一個中心，這些中心被稱為configuration（配置），它們中間的每一個都是用于消費電子和嵌入設備的特別的類。目前配置分為CLDC和CDC兩種。
Connected limited device configuration(有限連接設備配置，簡稱 CLDC)定義支持“devices that you hold in your hand（握在手中的設備）”的應用程序接口和技術，這類設備的代表是PDA。Connected device configuration(連接設備配置 CDC )定義支持“devices that you plug into plug into the wall（插入墻的設備）”的應用程序接口和技術，這類設備的代表是機頂盒。
這兩種配置不同的地方就在于它們應用于的裝置的能力，CLDC設備的處理器能力有限 (與臺式機系統比較 )，并且存儲器大小一般也只在128 KB到 512 KB之間。CDC系統不同，它可能有32位或64位處理器，以及有限的存儲容量，不過它的下限也得超過512K。
上圖解釋配置和簡表的體系結構。J2ME的體系結構被橫向地分成三層，縱向分成兩部分。配置包括一個控制配置核心類的虛擬機，具體的簡表位于每個配置之上。
簡表為相同消費電子設備的不同的生產商提供了標準化的 Java類庫，現在五個已知簡表已經有了規范：
Mobile information devices profile (MIDP) 移動電話和呼叫器 CLDC
Personal digital assistant profile Palm和Handspring的PDA 設備 CLDC
Foundation profile 用于所有不需要GUI的CDC設備的標準簡表 CDC
Personal profile 替代PersonalJava的Foundation完善的簡表 CDC
RMI profile 提供RMI的Foundation完善的簡表 CDC
3 SOAP協議介紹[4]
SOAP（簡單對象訪問協議）是一種利用XML編碼數據的數據傳輸協議。它是同類協議中要求最低的一個規范，只定義了協議所要求的最關鍵的部分，有意地忽略了垃圾收集、對象激活等方面的細節。像TCP/IP協議一樣，SOAP協議也包括客戶端和服務器兩個部分。
SOAP客戶端是一種創建XML文檔的程序，該XML文檔包含在分布式系統遠程調用方法所需的信息。SOAP客戶端不是傳統意義上的程序，它除了用作普通的桌面應用程序外，還可以是一種Web服務器或基于服務器的應用程序。來自SOAP客戶端的消息和請求一般是通過HTTP發送的。因而，SOAP文檔可以穿過幾乎所有的防火墻，從而能跨越不同的平臺交換信息。
SOAP服務器只是用于監聽SOAP消息的特殊代碼，它可用作SOAP文檔的分配器和解釋器。外部Web服務可以與基于J2EE技術的應用程序服務器交互，這種應用程序服務器可以處理多種客戶端的SOAP請求。
SOAP定義了數據編碼規則，稱為基準編碼或“Section 5（第5節）”編碼，它是出自SOAP規范中描述數據編碼規則的內容。SOAP編碼可以簡短地描述成簡單值或復合值的集合。簡單值可以是簡單類型，如整型、浮點型和字符型，或者是XML架構規范第2部中定義的內置類型，包括各種數據類型，如字節型數組和枚舉。復合值包括結構、數組和XML架構制定組定義的復雜類型。
SOAP在標準化消息格式環境中，可以做所有它能完成的工作。消息的主體部分是“text/xml”形式的MIME類型，并且包含一個SOAP封套。該封套是一個XML文檔。封套包含了報頭（可選的）和報文（必須有的）。封套的報文部分總是用于最終接收的消息，而報頭項目可以確定執行中間處理的目標節點。附件、二進制數字及其他項目可以附加到報文上。
SOAP提供了一種讓客戶端指定哪個中間處理節點必須處理報頭項目的方法。由于報頭與SOAP消息的主體內容是互不相關的，所以可用它們給消息添加信息，而不會影響對消息報文的處理。
4 SOAP協議在J2ME平臺中的實現
如何真正地將移動設備融入到Web Services中去呢？這就需要使得PDA、手機等成為Web Services的客戶端，因此這些設備至少應該具有處理XML信息的能力。在J2ME平臺中實現SOAP客戶端的功能，使得嵌入式設備能夠連接企業的WEB服務是企業應用中比較常見的需求。J2ME的基本類庫中沒有提供SOAP的支持，所以需要在J2ME平臺中開發實現SOAP的處理功能。
實現SOAP協議客戶端的關鍵問題分為兩個方面：J2ME不同配置的數據類型不一樣，導致與SOAP協議封裝的數據類型不匹配；J2ME平臺沒有提供對XML文件進行處理的功能。
針對第一個問題，需要注意只能使用基本類型，對不匹配的數據類型采用使用基本類型復合的方式進行處理。針對第二個問題需要在J2ME中擴展對XML文件處理的功能。目前有有兩種方法對XML文件進行解析。一種是采用DOM的方式，另外一種是采用SAX的方式。操作DOM是一個與XML相互作用的簡單方法，通常這個XML是一棵完整的XML樹，被解析成一個存放在存儲器中的節點結構，你可以遍歷這棵樹。它非常簡單易用，但是因為整棵樹存在于存儲器中造成存儲器的負擔，而對于嵌入式系統來說存儲器的資源是有限的，因此這種方法的使用具有一定局限性。第二種方法在捕捉語法分析事件中，每當語法分析程序遇到數據中的特定結構，它就會遍歷XML數據，然后把結果發回前面注冊的一個事件監聽器中。比如說，當語法分析程序遇到一個起始標記，如＜html＞，那么事件監聽器將接收一個事件，通知它這個情況，并且向它傳遞任何所需的信息。相對DOM方式的處理，SAX方法對存儲器的要求比較低，但是效率要比DOM方式低。
Enhydra的KXML是一個只占很小存儲空間的XML語法分析程序，對于J2ME應用程序非常適合。KXML支持DOM語法分析和操作，但是不支持SAX語法分析。取而代之，它使用一種稍微不同的稱為“Pull”的分析方法。
下面是KXML采用DOM的方式處理XML數據的例子：
1.Document doc = new Document();
2....
3.parser = new XmlParser(abc);
4.doc.parse( parser );
第一行創建了一個文檔對象，保存XML樹。第三行從一個名為abc的InputStreamReader中創建一個KXML語法分析程序。第四行傳送這個語法分析程序到文檔，然后讓文檔開始分析。XML被遞歸分析，直到到達文檔的結尾。當分析調用退出時，整個文檔被裝入內存，這時就可以對XML進行操作了。
1.Element root = doc.getRootElement();
2.int child_count = root.getChildCount();
3....
4.for (int i = 0; i ＜ child_count ; i++ ) {
5....
6. Element kid = root.getElement(i);
7.
8. if (!kid.getName().equals("abc")) {
9. continue;
10. }
＜abc＞元素是根元素的直接子元素，可以遍歷根元素的子元素，尋找abc標記，如果子元素不是一個abc 標記，則返回。
1.int address_item_count = kid.getChildCount();
2.
3. for (int j = 0; j ＜ abc_item_count ; j++) {
4....
如果找到了abc子元素，開始遍歷它的子元素，并把這些子元素的內容打印出來。
通過KXML對XML的處理，可以進一步實現對SOAP數據的處理，實現J2ME平臺對SOAP協議的支持。
J2ME Web Services規范（JSR172）的制訂給J2ME平臺增加兩大功能：一是使其能夠遠程訪問基于SOAP/XML的Web Services；二是使其具有解析XML數據的能力。目前JSR172的標準已經制定完成，為了實現這兩大功能，JSR172新定義了提供相應功能的兩個可選包。這兩個包占用內存非常少，XML-RPC部分大概需要25-30KB的空間，而XML解析器則需要35KB左右。
規范只對JAX-RPC的模型提供支持，也就是說僅支持同步的訪問方式，使用J2ME客戶端可以向服務器發送RPC請求和獲得RPC響應。在JSR 172中實現的是SAX模式的解析器。能夠解析XML之前首先需要創建SAXParser的實例，
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
接下來要獲得XML文件的輸入流，并把它作為其中一個參數傳遞給saxParser的parse方法，
InputStream is = this.getClass().getResourceAsStream("phone.xml");
SaxParser.parse(is，new BasicHandler(this));
DefaultHandler是SAX2默認的事件處理器基類，用于處理XML解析事件的方法如下：
startDocument()
startElement(java.lang.String uri，
java.lang.String localName， java.lang.String qName， Attributes attributes)
characters(char[] ch， int start， int length)
endElement(java.lang.String uri，
java.lang.String localName， java.lang.String qName)
endDocument()
默認情況下，DefaultHandler的上述方法什么也不做，因此必須自己擴展DefaultHandler并且覆蓋上述的方法。程序中提供了一個BasicHandler用來處理xml文件。class BasicHandler extends DefaultHandler在BasicHandler類中有兩個成員變量
private Vector phones = new Vector();
private Stack tagStack = new Stack();
phones用來存儲我們已經解析出來的Phone對象，tagStack則用來存放我們解析到的元素名稱，比如sonyericsson，phone，name，colour等。在文檔解釋結束后，也就是在endDocument()方法內我們把解析的結果顯示在手機屏幕上，BasicHandler的幾個重要方法如下：
public void startDocument() throws SAXException {}
public void startElement(String uri， String localName， String qName， Attributes attributes)
throws SAXException {
System.out.println("the qName is "+qName);
if(qName.equals("phone")) {
Phone phone = new Phone();
phones.addElement(phone);
}
tagStack.push(qName);
System.out.println("the tag stack's length is "+tagStack.size());
}
public void endElement(String uri， String localName， String qName) throws SAXException {
System.out.println("the end qName is "+qName);
tagStack.pop();
}
5 結束語
通過擴充J2ME平臺對XML數據的處理，完成了J2ME平臺對SOAP協議的支持。通過SOAP協議能夠使得基于J2ME平臺的嵌入式設備無縫的連接到企業現有的應用系統，解決了嵌入式設備數據來源不足的問題，擴展了嵌入式系統的應用范圍。本文從處理XML數據出發，深入探討了在J2ME平臺中實現SOAP客戶端的各種技術，對于企業應用系統的集成具有一定的推廣價值。
參考文獻
[1] Yuan，Michael Juntao. Enterprise J2ME. Pearson Education 2003
[2] 胡虛懷，楊志，李煥. J2ME移動設備程序設計. 清華大學出版社 2005
篇2
關鍵詞：Web Service； XML； SOAP； 嵌入式系統
中圖分類號：TN91934； TP311文獻標識碼：A文章編號：1004373X(2011)22006104
Implementation of Web Service Technology in Embedded Environment
WANG Haili, ZHOU Xingpeng
(School of Automation, Southeast University, Nanjing 210096, China)
Abstract： To cope with the interoperability and integration between embedded system and other heterogeneous systems, a new approach of applying Web Service technology in lowend embedded equipments is proposed. Based on ARM CortexM3 microcontroller, miniature realtime operating system and embedded TCP/IP protocol stack, the implementation process of Web Service is elaborated, including HTTP message reception, XML/SOAP protocol parse and service function bind. Special care is taken to minimize resource consumption in this resource constrained environment. Load test performed by dedicated test tool proved the good feasibility and stability of the proposed approach.
Keywords： Web Service; XML; SOAP; embedded system
收稿日期：201106070引言
近年來隨著網絡化概念的不斷推廣，嵌入式系統也擺脫了以往“信息孤島”的封閉局面，相互之間逐漸形成了分布式的協作關系。然而嵌入式系統在網絡的應用層上常常采用自定義的傳輸協議，加之各系統之間巨大的平臺差異性，給系統間的互訪以及企業級信息的集成帶來了困難［1］。Web Service技術具有良好的跨平臺和松耦合特性，能夠實現不同平臺的分布式系統之間的無縫集成，降低了企業進行設備升級和服務重組時的投入［2］。本文以32位微處理器ARM CortexM3為核心，借助于嵌入式TCP/IP協議棧和實時操作系統，在嵌入式環境下實現了Web Service技術。
1Web Service與SOAP協議
Web Service是網絡化應用的一種，可以將其看成一種函數調用，只不過這個函數的實體存在于某個服務器上，而對函數的調用在客戶端進行，客戶端只要接入裝有服務的機器所在的網絡即可調用函數。為了實現這種遠程調用，需要對傳輸的數據格式采取一些約定措施，簡單對象訪問協議（Simple Object Access Protocol，SOAP）很好地應對了這種需求［3］。SOAP協議以XML形式提供了一個簡單、輕量的機制，用于在分布環境中交換結構化信息。SOAP本身并沒有定義任何應用程序語義，如編程模型或特定語義的實現；實際上它通過提供一個模塊化的封包模型和在模塊中進行數據編碼的方法，定義了一個簡單的表示應用程序語義的機制［4］。
SOAP消息是由Envelope，Header和Body三部分組成的XML文檔，其中Envelope是SOAP消息的根元素，必須在SOAP消息中出現；可選的Header元素包含有關 SOAP 消息的應用程序專用信息；必需的Body元素包含打算傳送到消息最終端點的實際SOAP消息 ［5］。最后，為了進行基于SOAP的遠程調用，需要一種低級傳輸協議。SOAP規范允許使用HTTP，SMTP甚至原始的TCP/IP套接字，其中HTTP協議最為常用。
2Web Service在嵌入式環境下的實現
2.1底層軟硬件結構
本文中所使用的硬件基于ST公司推出的ARM CortexM3 32位微處理器STM32F107VC［6］。CortexM3是針對價格敏感但又有高系統效能需求的嵌入式應用而設計的ARM內核，作為ARM7的后繼者，大刀闊斧地改革了設計架構，顯著簡化了編程和調試的復雜度，處理能力也更加強大［7］。STM32F107VC工作頻率最高為72 MHz，帶有256 KB的片上FLASH和64 KB的SRAM，以及以太網MAC控制器，因此外接一片PHY芯片RTL8201，完成與以太網的物理通信。
為了達到實時任務管理，本文選用嵌入式實時操作系統FreeRTOS和輕量級TCP/IP協議棧lwIP組成底層軟件開發平臺。FreeRTOS作為一個免費開源的小型實時內核，主要用于建立和管理各個模塊的任務［8］；lwIP則為數據的TCP/IP封裝提供了一個良好的軟件基礎［9］。
2.2SOAP消息的處理
目前已經有許多成熟的SOAP工具，例如針對C++的gSOAP、針對Java的kSOAP等，但是這些實現方案均是為PC機或者帶有高級操作系統的嵌入式系統設計的，對資源的消耗較多。對于低端的嵌入式環境，需要更輕量型的處理方法。
由前文可知，SOAP可以簡單的理解為HTTP+XML+遠程調用規則，因此SOAP消息的處理也分為3步：HTTP協議的實現、XML解析、具體服務實現。其總體結構如圖1所示。
圖1總體實現框架SOAP在HTTP上的遠程調用的具體實現過程大致如下：客戶端通過SOAP工具生成基于XML文檔的SOAP消息，在該SOAP消息里包含有客戶請求的服務名稱及調用服務程序所需的參數，并使用HTTP POST方法通過網絡向應用程序所在的服務端發送 SOAP請求；另一方面，當服務端接到HTTP信息之后，又從中提取出SOAP 消息，啟動XML文檔解析器進行解析，獲取客戶需要調用的方法名及其參數，以此來調用相應的服務程序，之后以類似的方法將運行結果打包成SOAP消息返回給客戶，完成應用程序的遠程調用。
篇3
電子商務應用系統的安全要素通常包括數據的機密性、完整性、用戶授權、身份的可鑒別性和不可否認性等方面。將基于SOAP協議的WebServices[1]技術應用到電子商務，雖然很好地解決了電子商務的應用集成和分布式應用，但由于SOAP協議是一個基于XML的輕量級協議，其設計目標在于它的簡單性和可擴展性，在制定時并沒有過多考慮安全性要求，加之SOAP協議規范本身沒有提供安全解決方案，因此在不安全的公用網絡傳輸時，SOAP消息中的敏感信息很容易被人竊聽、篡改或偽造，從而造成數據的泄密和數據完整性的破壞。電子商務中整個WebServices的通信，都是通過SOAP消息來實現的，若不能很好地解決SOAP消息的安全問題，則將極大阻礙WebServices在電子商務領域的應用。
2SOAP消息安全性改進
在電子商務應用中，通信雙方常常通過交換商務文檔來進行電子商務交易。發送方會將一個或多個文檔包裝在一個請求消息中，然后發送給接收方；接收方處理該消息的內容后響應發送方。當一些業務應用被調用后，一個包含業務文檔的請求將從SOAP發送者發送給SOAP接收者，而位于SOAP接收者端的業務應用將處理這個請求并生成響應，這個響應被回送給發出該請求的SOAP發送者。商務文檔的網絡傳輸路徑上存在許多惡意的攻擊者，它們可以監視網絡中傳輸的消息，并可能按照傳輸消息的協議格式發送欺騙性的假消息或者對原消息的內容進行更改。比如攻擊者中途截取消息，對該消息進行處理之后再轉發，這對電子商務的安全構成極大的威脅。
通過對SOAP消息安全性研究發現，所有的攻擊都是對SOAP消息的修改，或者在SOAP消息的首部或實體刪除一些部分以及在后面附加一些內容，或者添加一些全新的元素[2]。SOAP消息中的XML元素可能被處理而導致一些意外的修改，這會使得原SOAP消息中某些元素的前驅后繼關系被改變。而且意外的修改還可能導致SOAP消息中各元素的前驅、后繼以及兄弟元素的數量被改變，這樣原SOAP消息元素的層次結構也被改變了。SOAP消息可以在傳送的過程中被擴展，而在SOAP首部中沒有包含與SOAP消息的結構相關的信息，而攻擊者利用最多的恰恰是SOAP的層次化結構。所以，本文引入一個稱為SOAPRECORDER的數據結構概念，它用來保存SOAP消息的動態結構信息。SOAPRECORDER的基本作用是在其中保存SOAP消息的各元素的結構（例如：首部元素的個數、簽名對象的個數以及簽名對象的層次信息等等）。這些信息可以在SOAP消息的發送程序創建該SOAP消息的同時進行計算，因此不會引起額外的開銷。
2.1SOAPRECORDER結構
SOAPRECORDER信息的結構如圖1所示。SOAPRECORDER中包括的內容有：根結構下的子元素的個數、首部元素的個數、簽名元素的參考項的個數、簽名對象之間的前驅、后繼以及兄弟關系和擴展的部分。電子商務文檔在網絡傳輸時所受到的攻擊主要是利用SOAP消息結構化語法的漏洞，所以解決這一問題的有效的手段就是在SOAP消息中添加SOAPRECORDER信息。消息的接收方在接收到SOAP消息的同時對消息的結構信息進行計算，然后與消息中的SOAPRECORDER信息進行比較，如果兩者出現差異，則說明SOAP消息在傳送的途中受到了篡改攻擊。SOAP消息的發送者如果在消息中添加了SOAPRECORDER信息，那么在發送消息前必須對SOAPRECORDER信息也進行簽名，以保證SOAPRECORDER信息在消息傳送途中不被篡改。
2.2SOAP消息加密傳輸
由于SOAP消息在網絡傳輸時受到威脅，所以要對其消息進行加密傳輸。本文采用一種加密和數字簽名技術保證SOAP信息在公開網絡上的安全傳輸[3]。SOAP消息請求者先用哈希函數從原始信息和擴展信息的組合信息中得到信息摘要SHash(M,W,Ex)，其中M為原始信息，W為需要嵌入的加密信息，Ex為擴展信息。并用自己的私密鑰對信息摘要加密'()userSKSES，接著利用自己的對稱密鑰對三者的組合信息加密'(,,)userSSKWEMWEx，然后用服務提供者的公開密鑰對請求者的對稱密鑰加密''()userPKserverWESSK，這樣數字簽名的正確性就可以由任何請求者公開密鑰的人來驗證；而加密后的對稱只有服務提供者能夠用私有密鑰解開，這樣就保證了SOAP信息在Internet傳輸過程中的安全。具體步驟如下：（l）數字簽名SHash(M,W,Ex)；'()userSKSES；（2）信息加密'(,,)userSSKWEMWEx；''()userPKserverWESSK；（3）數據傳輸''''UserServer:{S,W,W}；（4）Server信息解密''()serveruserSKSSKDW；（5）Server簽名驗證（用得到的組合信息與哈希函數計算信息摘要，與解密后的信息摘要比較）''SHash(M,W,Ex)；'()userPKSDS；''?SS（比較兩者是否完全一致，如果一致，說明簽名正確，反之說明簽名無效）；服務請求者構造SOAP消息，消息的Body部分包括上述三個方面的組合信息和服務的訪問參數。為保證消息不會被網絡上惡意破壞者篡改和偽造，對SOAP信息簽名和加密是必需的步驟。加密按照WS-Security中的XMLEncryption規范[4]，通過擴展SOAP消息的Header的方式來實現。消息接收端在收到加密的SOAP請求后，解析SOAP消息的Header部分，得到服務請求者的X.509證書并驗證其合法性。同時用私有密鑰解密SOAP消息中加過密的對稱密鑰W，并用對稱密鑰解密加過密的組合信息W，然后用哈希函數和得到的組合信息重新計算信息摘要，并與解密后的信息摘要比較。在成功判斷數字簽名的正確性后，從消息中取出原始數據。
3SOAP消息安全性實現
本文設計一個稱為SendSOAPRECORDER的模塊向在Web服務間進行交互的SOAP消息中加入SOAPRECORDER信息。每一個SOAP消息的處理節點也都有一個相應的CheckSOAPRECORDER模塊用來檢查接收到的SOAP消息的安全性。如圖2所示：當處理節點接收到SOAP消息時，先把該SOAP消息發送到本節點的CheckSOAPRECORDER模塊進行檢測，在經過節點的所有檢測之后還要把該消息發送到本節點的SendSOAPRECORDER模塊添加本處理節點的SOAPRECORDER信息。于是每經過一個處理節點，都會增加額外的兩條進行SOAPRECORDER處理的消息。在一個節點傳送SOAP消息前，首先計算出該消息的SOAPRECORDER信息，并在SOAP消息的首部或實體中將該信息添加到一個作為SOAP信封元素形式存在的首部下面，然后對它進行簽名和加密。SOAP消息傳送路徑上的每個中間節點也對SOAP消息做同樣的處理。SendSOAPRECORDER負責添加SOAPRECORDER信息。為了檢測網絡攻擊，CheckSOAPRECORDER模塊在接收到SOAP消息后會做一些常規的檢測。一旦有SOAP消息到達，CheckSOAPRECORDER模塊就會立即檢測SOAP消息中是否有作為SOAP首部存在的SOAPRECORDER首部。因為在新偽造的首部下拷貝的SOAPRECORDER信息已經不再是作為一個獨立的SOAP首部而存在，所以CheckSOAPRECORDER模塊會立即拋出一個異常，警告消息接收者SOAPRECORDER信息已經被人攻擊。如果包含該首部，CheckSOAPRECORDER模塊將校驗SOAPRECORDER的簽名。如果SOAP消息傳送途中經過了若干個中間處理節點，那么這些中間節點會在該消息中添加它們自己的SOAPRECORDER信息，這樣SOAPRECORDER的簽名可能出現嵌套的情況。如果簽名校驗不正確，就說明SOAP消息已經被惡意攻擊。
篇4
關鍵詞：Web服務 性能 優化
簡單易用是Web服務的一個重要設計目標。簡單易用性是通過對用戶屏蔽復雜性和更高層的抽象來達到的，這需要更多的計算資源開銷。因此，Web服務與傳統的分布式計算技術（如微軟的DOOM、Sun的Java RMI、CORBA）相比，性能具有一定的差距，最為突出的問題是Web服務的響應時間和吞吐率等。在多數應用中Web服務不會產生性能瓶頸，但是，在某些高負載、高吞吐率等對性能有較高要求的應用中，Web服務的性能成為決定其是否能進一步得到更加廣泛應用的關鍵因素之一。Web服務日益成為異構網絡環境下的主流分布式計算模式。基于XM L的數據傳輸格式在給Web服務帶來跨平臺性、松散耦合和良好的互操作性等優點的同時，也在一定程度上影響了其性能。本文在分析Web服務性能的基礎之上，針對Web服務的額外性能開銷問題，以NET平臺為例，提出了使用緩存技術、SOAP壓縮技術和異步Web技術等策略實現Web服務性能的優化。
一、Web服務的應用模式
Web服務的應用模式是一種基于SOAP、WS-DL、UDDI的面向服務的體系結構（Service Oriented Architecture，SOA）。Web服務所提供的最簡單級別的應用是使用SOAP協議和HTTP協議使Internet上的客戶端程序能夠使用Web服務。具體來說，一個客戶端請求是使用HTTP協議上的SOAP協議，然后經由Internet進行傳遞的Web服務發送響應給客戶端應用程序，該響應是作為HTTP上的一個SOAP消息被發送的?？蛻舳苏埱蠛蚖eb服務響應的SOAP消息主要是基于XM L格式的。由于Web服務主要使用HTTP和SOAP進行通信，并且主要的供應商都支持標準協議SOAP，避免了在CORBA、DOOM及其他協議之間進行轉換，從而使Web服務具有跨平臺性、松散藕合和良好的互操作性。
二、影響Web服務性能的主要技術因素
通過針對Web服務基本架構的分析，可知Web服務的運行機制是建立在基于XM L的統一消息交換機制的基礎之上，影響Web服務請求響應時間的主要因素是XM L消息的處理機制。因此，服務傳輸時間（即請求從客戶端到達服務端和響應從服務端到達客戶端所用的時間）和XM L消息處理時間（即XM L解析、服務調用以及最后的應答消息編碼所花的時間）是影響Web服務性能的主要因素。
第一，服務傳輸。在Web服務調用過程中，傳輸協議會對服務傳輸的性能造成重要的影響。SOAP協議大部分應用是與HTTP協議進行綁定的。HTTP采用一個無狀態的數據轉發機制，它只能處理單一方式的請求或應答，這既是優點也是缺點。一方面，由于缺少狀態使得HTTP累贅少，系統運行效率高，服務器應答快；另一方面，由于沒有狀態，協議對事務處理沒有記憶能力，若后續事務處理需要有關前面處理的信息，那么這些信息必須在協議外面保存。另外，缺少狀態意味著所需的前面信息必須重現，導致每次連接需要傳送較多的信息，造成了它的性能消耗。隨著電子商務的飛速發展，運行在網絡上的用戶和數據量日益增加，在有限帶寬和網絡資源的條件下，HTTP顯然是制約Web服務性能的一個瓶頸。
第二，由于SOAP自身的特點導致在所傳輸數據的封裝編碼、解碼方面存在嚴重的性能問題，這些問題主要表現在將浮點數轉化為相應的ASCII表示、將ASCII表示轉化為相應的數據及從緩存中讀寫轉化后的數據，這些過程占據了整個通訊過程大概90%的時間。SOAP是一個基于XM L文本格式的協議，XM L雖然可讀性比較好，但是比一進制實現的協議需要更多的帶寬、更大存儲能力和更長的處理時間，在很大程度上降低了Web服務的性能。此外，缺乏緩存或低效率緩存、低效的狀態處理錯誤的使用線程、繁瑣的調用等問題都會加劇Web服務性能問題的嚴重性。
三、Web服務的性能優化
第一，緩存技術。緩存（Cache）在計算機科學領域指的是一些數據副本的集合。當原始數據訪問速度較慢時，可以通過使用在高速存儲區域中保存原始數據的常用數據副本，從而提升訪問速度。常見的硬盤緩存、CPU緩存、網頁緩存等都是緩存概念的應用。由數據庫驅動的Web應用程序中，那些經常被調用的并且對實時性要求不是很高的服務，使用緩存技術是一個十分有效的提高性能的方法。.NET平臺的Web服務充分考慮了對Cache的擊求，只要簡單地設定即可啟用Cache。對Web服務的調用也啟用Cache的機制，可以減少服務器端不必要的開銷。利用緩存技術，必須面對數據過期的問題（這也是實時系統比較少用的原因）。最典型的情況是，如果將數據庫表中的數據內容緩存到服務器內存中，當數據庫表中的記錄發生更改時，Web應用程序則很可能顯示過期的、不準確的數據。這是不可接受的。解決這個問題的關鍵是在刪除或修改時根據Cache key來強制刪除該Cache項。綜上，對于一些經常被調用的并且對實時性要求不是很高的Web方法，我們可以應用這一屬性，設置一個合適的緩存時間用以減少調用的次數，從而減少服務器端的開銷。在一些不常調用，或者調用的參數是變換的Web方法，或者是實時性要求高的Web方法，可以減少Cache Duration屬性的使用，這將會減少服務器Cache的開銷。
第二，SOAP壓縮技術。由于Web服務主要使用SOAP協議作為標準通訊協議，因此，SOAP消息報文的解析、驗證、編碼安全處理等對Web服務性能有最直接的影響。SOAP是基于XM L編碼的，而XM L文檔其實就是文本文檔。因此，SOAP消息也能夠看作一個文本流。假如采用壓縮文本流的方法將會大大提高網絡傳輸的效率（減少傳輸的數據量，加速SOAP消息傳輸），從而也達到對Web服務性能的優化。當網絡傳輸的內容是文本的時候，通過壓縮，它的尺寸能夠減少70%左右（不同的壓縮技術，壓縮比例不同）。這就意味著在客戶端和服務器之間帶寬的需求也能夠減少類似的白分比。所以壓縮是提高傳輸效率的最有效的方法，當然為了壓縮和解壓縮，服務端和客戶端會增加自身CPU的負載。SOAP消息主要包括客戶端發出的SOAP請求消息和服務器端發出的SOAP響應消息。通常情況下，服務器端的SOAP響應消息要比客戶端的請求消息大。因此，壓縮服務器端的SOAP響應消息對于性能的優化的效果較為明顯。采用壓縮SOAP方式，特別是壓縮SOAP響應消息的方式，降低了網絡上的數據傳輸量，可以達到優化Web服務的性能，但同時也會帶來一個負面效果，如消息的壓縮和解壓縮需要額外的時間開銷，也會增加CPU的負載。
第三，異步Web技術。異步和同步的最主要的區分，簡單地講，就是異步沒有馬上返回結果，而同步則是馬上返回結果。常規的客戶端調用，當調用Web服務時，由于服務器處理速度、網絡傳輸速度等各種原因會使一個Web服務從請求開始到獲得響應結果之間等待一段時間，這時候線程會處于阻塞狀態，程序會等待請求結果導致客戶端無法進行其他的動作或處理。在.NET環境中，可以通過，asynchronism實現異步調用Web服務。即通過創建一個新的線程來執行新的Web服務請求，這對程序的主線程不會產生影響。
常規的服務器端同步Web方法：當從同步Web方法返回時，將發送對該方法的響應。如果需要較長的時間來完成清求，則處理請求的線程會一直被占用，直到方法調用結束。服務器端為響應多個請求，可能會建立多個線程，這樣可能會很快耗光系統資源。為了解決這個問題，就要考慮使用線程池技術。.NET運行時提供了線程池的實現。對于異步方法調用由系統將方法提交給線程池，由線程池中的線程執行。線程完成任務后，線程不會自行銷毀，而是以掛起狀態返回線程池。應用程序每次向線程池發出請求，線程池會將掛起的線程激活并執行任務，而不會創建新線程。當然，在一個復雜的應用程序中，用戶也許會同時請求多個Web服務，這時就得創建并控制多個線程。
綜上，客戶端的異步調用實現了請求和接收異步通信，解決了客戶端線程阻塞的問題。既滿足了調用多個Web服務的要求，又減少了響應時間。而服務器端的線程池技術也很好地解決了服務器端同步Web方法的問題。當然，多線程的控制雖然可以實現很好的應用程序，但難度是比較大的，而且很容易引起異常。
四、結束語
隨著電了商務、電了政務的迅速崛起，基于Web服務的應用模式己經成為主流架構，同時這也對Web服務的服務質量（QoS，如服務的可用性、功效性和性能等）提出了更高的要求。本文在對Web服務的性能進行分析的基礎上，針對Web服務的額外性能開銷問題，以.NET平臺為例，討論了使用緩存技術、SOAP壓縮技術和異步Web技術等策略在Web服務性能優化中的應用。Web服務性能優化本身就是一個復雜的議題。除了采用上述幾種優化的方法，還必須多方面地考慮優化的問題，從系統設計到部署實現都需要考慮如何優化改善其性能。如在Web服務接口設計時要充分考慮服務的粒度，配套開發工具（如、數據庫優化）的優化。
（作者單位：湖北工業大學計算機學院）
【參考文獻】
1、鄧海生,李軍懷,劉紅英.基于的Web服務性能優化[J].計算機技術與發展,2007(10).
篇5
電力經濟活動分析系統是利用基于XML的WebService技術,集成企業的現有系統。通過利用Web服務,獲取電力企業的財務系統和生產系統中的已有數據進行分析,完成情況分析、生產分析、經營分析和綜合效益評價等項功能,從而為發電公司的生產經營決策提供智力支持。通過提供Web服務,支持用戶其他系統使用電力經濟活動分析系統的分析結果和數據,例如,為企業網站提供發電量、營業額等統計信息。Web服務在電力經濟活動分析軟件中起到關鍵性的作用,生產系統和財務系統所提供的Web服務,涉及生產、財務系統里的重要數據,關系到企業的安全生產和運營。所以如何在電力經濟活動分析軟件中構建安全的Web服務,使實施該項目需要重點考慮的問題。下面將從Web服務和其安全規范出發,來介紹在電力經濟活動分析系統項目實施中,實現安全的Web服務。
1.Web服務和其安全性規范
(1)什么是Web服務
Web服務是一種完全建立在現有互聯網標準之上、松散耦合的、跨語言和平臺的應用程序之間通信的標準方法。XMLWebService體系結構的主要優點之一是:允許在不同平臺上、以不同語言編寫的各種程序以基于標準的方式相互通信。雖然Web服務一經出現,便為各廠商接受和支持,但并沒有一個關于Web服務的統一的定義。廣泛接受的一個XMLWebService定義是:通過SOAP在Web上提供的軟件服務,使用WSDL文件進行說明,并通過UDDI進行注冊。要實現一個完整的Web服務體系需要一系列的協議規范來支撐,如圖1所示:其中,第1、2層是已經定義好的并且被廣泛使用的傳輸層和網絡層的標準:IP、IITTP、SMTP等。而第3、4、5層是目前開發的Web服務的相關標準協議。SOAP(SimpleObjectAc-cessProtocol)是一個協議規范,定義了傳遞XML-encoded的數據時的統一方式,它還定義了使用HTTP作為底層通信協議時執行遠程調用(RPC)的方法。UDDI為客戶提供了動態查找其它Web服務的機制。WSDL為服務提供了描述構建在不同協議或編碼方式之上的Web服務請求基本格式的方法。
(2)Web服務的調用過程
利用Web服務可以建立面向服務的集成系統。即不用改變現有的各種應用,也不關心它們技術的不同(比如是Java,還是.NET),利用Web服務的消息驅動機制,讓它們協同工作和交互。Web服務體系最基礎的支柱是XML消息傳遞。XM消息傳遞的標準是SOAP,服務的請求者通過在傳輸層協議之上綁定SOAP消息來發送Web服務的請求。假設SOAP綁定在http之上,那么它就會利用http的請求/響應消息模型,將SOAP請求放在http請求里面,服務的提供者將SOAP響應的結果放在http響應里面返回給Web服務的請求著。
(3)Web-Security規范
Web的基礎是簡單對象訪問協議(SOAP),它是在分布式環境中交換信息的簡單的XML文本協議,本身不涉及安全范疇。隨著各種基于Web服務應用的發展,如電子商務、網上銀行等等,引出了人們對Web服務安全性的關注。WS-Security規范是構建安全的Web服務應用的基礎。該規范主要提供了三種機制:安全性令牌傳輸、消息完整性和消息機密性。通過提供安全性令牌來實現Web服務的授權訪問,安全性令牌包括普通的用戶名/密碼令牌以及X.509等證書令牌。后兩者是通過引入XML數字簽名和XML加密協議實現的。這些機制可以單獨使用,也可以組合使用,以實現不同強度的安全性。
2.Web服務關鍵安全手段
(1)加密技術
任何Web服務考慮其安全性,首先需要的一項重要安全技術,就是在敏感數據通過開放網絡傳輸時提供保護。加密技術可以加密消息,從而保護敏感數據免遭暴露。加密技術還能保障消息的完整性。加密技術分為兩種:①秘密密鑰加密。又稱為“對稱密鑰加密”,通信雙方使用同一個加密密鑰來加密和解密消息。②公鑰加密。使用兩種不同但是在數學上相關的密鑰。使用公鑰加密技術時,用公鑰來加密數據,私鑰來解密數據,也成為“不對稱加密”。公鑰密碼技術也可以用來創建以用戶的私鑰為基礎的不可偽造的數字簽名。正確標示公鑰是公鑰證書的推動因素。
(2)驗證模型
Web服務安全性首先在于對用戶合法性的驗證,也是Web服務授權和訪問控制的基礎。Web安全模型并沒有指明任何驗證協議。用戶可采用任何認為合適的方法來驗證用戶。就目前的技術而言,驗證主要可分為三類:①直接驗證客戶端在使用Web服務時,直接提交憑據,例如用戶名和密碼,用作驗證。②X.509證書驗證用戶身份時,另一個選擇足發送X.509證書。X.509證書確切地告訴web服務提供者用戶的身份。您可以使用PKI將此證書映射到應用程序中的現有用戶。③Kerberos驗證Kerberos驗證包含客戶端向服務證明身份以及服務向客戶端證明身份的機制。要使用Kerberos,用戶需要提供一組憑據(例如用戶名/密碼或X.509證書)。如果所有內容檢驗合格,安全系統將授予用戶一個TGT(TicketGrantingTicket)。TGT是一個隱藏的數據,用戶無法讀取,但必須提供它才能訪問其他資源。
(3)保護連接安全
保護XMLWebService安全的最簡單的一種方法就是確保XMLWebService客戶端與服務器之間的連接安全。根據網絡的范圍和交互操作的活動配置文件,可以通過多種技術來達到這一目的。最流行也最廣泛使用的三種技術為:基于防火墻的規則、安全套接字層(SSL)和虛擬專用網絡(VPN)。
3.電力經濟活動分析系統Web服務安全功能的分析
(1)系統介紹
在給某發電企業實施的電力經濟活動分析系統中,該系統使用已有生產系統、財務系統的Web服務獲取基礎數據,為用戶提供生產指標統計分析、財務指標統計分析、成本分析、利潤分析、歷史比較分析等功能。用戶即可通過瀏覽器、也可通過Web服務開發其它的用戶應用來訪問這些功能。該系統功能結構如圖2所示:對于使用Internet瀏覽器訪問的用戶,電力經濟活動分析軟件通過WebForm網頁作為用戶接口。用戶其他應用程序獲取電力經濟活動分析系統的各種分析數據,電力經濟活動分析系統獲取生產系統、財務系統的基礎數據也都是通過訪問生產系統、財務系統的Web服務實現的。
(2)消息流分析
電力經濟活動分析、生產系統、財務系統所有Web服務都是基于XML,提供WSDL(WebServiceDescriptionLanguage)定義的接口。用戶應用使用這些Web服務是通過建立在HTTP協議之上的SOAP(SimpleObjectAccessProtocol)消息來訪問。圖3為電力經濟活動分析軟件中消息流圖。①用戶應用通過HTTPS向電力經濟活動分析軟件發送一個SOAP請求。這個SOAP請求的header元素里包含用戶的用戶名和密碼。②電力經濟活動分析軟件成為了Web服務的請求方,發送SOAP消息給生產系統或財務系統。SOAP消息的header元素包含有自定義的二進制令牌(一個X.509證書)。使用了X.509證書的公鑰來加密和簽名SOAP消息。③生產系統(財務系統)給電力經濟活動分析軟件返回消息。SOAP的消息體使用了X.509證書的公鑰加密。④電力經濟活動分析軟件返回用戶的消息。在用戶和電力經濟活動分析軟件之間的SOAP消息交換,考慮到用戶都為企業內員工,通過局域網訪問應用,并結合響應速度效率的因素,并沒有使用簽名和加密技術。我們對傳輸層使用SSL方式,來保證消息的一致性和完整性。利用SOAP消息的header元素包含用戶名和密碼來對用戶驗證。由于生產系統、財務系統的安全對企業生產經營至關重要,它們采用更嚴格的安全策略來對Web服務驗證、保護。這兩個系統的Web服務都采用了X.509證書驗證,數字簽名和加密技術保證Web服務的安全性。我們通過在生產系統和財務系統Web服務器的配置文件中,設置電力經濟活動分析軟件的證書和公鑰,便可實現電力經濟活動分析系統對生產和財務兩個系統的Web服務安全訪問。
篇6
關鍵詞：SOA；Web服務
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)23-958-02
Research about Web Service Based on SOA
PENG Bo1,2
(1.School of Computer and Information,Hefei University of Technology, Hefei 230009, China; 2.Anhui Medical University,Hefei230032, China)
Abstract:First gives the concept of SOA as a whole. Then analyses the architecture of WebService,
at last discuss the development methods of WebService.
Key words: SOA; WebService
1 SOA概述
1.1 SOA的基本概念
SOA(Service Oriented Architecture)是包含運行環境、編程模型、架構風格和相關方法論等在內的一整套新的分布式軟件系統構造方法和環境，涵蓋服務的整個生命周期：建模－開發－整合－部署－運行－管理。SOA是分布式軟件系統構造方法和環境的新發展階段。
其基本要素是：
1）松散耦合：包括服務之間的松散耦合、接口和實現之間的松散耦合、業務組件和傳輸協議之間的松散耦合。
2）粗粒度：SOA服務接口應比面向對象編程的API要大一些，更接近用戶的實際操作。
3）位置和傳輸協議透明：位置透明是指不論服務組件的實際位置URL如何變化，客戶的調用程序的URL都不需改變。傳輸協議的透明，就是指不管服務組件的傳輸協議如何變化，客戶端的調用程序的傳輸協議都不需要改變。
SOA的基本思想是面向服務，服務的本質是業務和技術的分離，它超越于一切具體的技術，又包含一切具體的技術。SOA三個基本要素能消除目前IT系統集成的障礙，從而達到SOA的目標：敏捷的，不受限制的業務集成。
1.2 SOA 和 Web Service 的根本區別
SOA是在 WebService 的基礎上發展起來的；而 WebServices 實現了松散耦合的服務和粗粒度的服務。雖然兩者都提供服務、服務接口都是基于開發的、接口與服務的具體實現都是分離的，但 Web Service 服務接口需要綁定具體實現服務的服務組件來實現服務，它對具體的服務實現完成了封裝，如圖1所示，實現了服務的透明化，客戶端不需知道服務是如何實現的，但客戶端調用 Web Service 組件時，還需要知道Web Service 的具置和傳輸協議，這將造成一定的不靈活性，因此它只是實現了一定程度上的抽象。
而SOA架構平臺只和服務接口進行綁定，對服務接口實現了封裝，如圖2所示，實現了服務接口的透明化，服務位置的透明化，傳輸協議的透明化。SOA 本身也不知道服務具體是如何實現的。當客戶端通過SOA調用服務時，不需要知道真正的服務提供者是誰，具體的服務位置在哪里和具體的傳輸協議是什么。因此SOA實現了最高程度的抽象化，為實現具有最高靈活性的服務建立了架構基礎。
2Web Service體系結構
Web 服務是一種部署在 Web 上的對象或組件，Web 服務是基于 Web 服務提供者、Web 服務請求者、Web 服務中介者三個角色和、發現、綁定三個動作構建的。
服務提供者就是 Web 服務的擁有者，它向其他服務和用戶提供自己已有的功能；服務請求者就是Web服務功能的使用者，它利用 SOAP 消息向 Web 服務提供者發送請求以獲得服務；Web 服務中介者的作用是把一個 Web 服務請求者與合適的服務者聯系在一起，充當管理者角色，一般是 UDDI。在這些角色之間使用了三種操作：、發現、綁定。
1）服務提供者(ServiceProvider)可以自己的服務，并對請求使用服務進行響應；
2）服務注冊中心(Service Registry)用于注冊已經的ServiceProvider，對其進行分類，并提供搜索服務；
3）服務請求者(ServiceRequester)利用服務注冊中心查找所需服務，然后使用該服務。
所謂的WebService就是定義了一套標準的調用過程：
1）服務器端首先用一套標準的方法向外界描述它所提供的服務內容，這屬于 WSDL；
2）客戶端需要以一種標準的協議來調用此服務，這屬于 SOAP (這也是WebService不同與其他組件如EJB的根本之處)
3）服務提供者將服務內容放在一個公共的網址讓大家查詢，這屬于 UDDI。
3Web Service 三個組成部分
1）WSDL(WebServiceDescriptionLanguage)是一種基于XML格式的關于Web服務的描述語言，其主要目的在于提供者將自已的Web服務相關內容，如服務傳輸方式、服務方法接口、接口參數、服務路徑等，生成相應的文檔，給使用者。使用者通過這個WSDL文檔，創建相應的 SOAP 請求，通過 HTTP 傳遞給提供者；Web 服務在完成服務請求后，將 SOAP 返回(response)消息傳回請求者，服務請求者再根據 WSDL 文檔將 SOAP 返回消息解析成自已能理解的內容。
WSDL 的目的就是告訴外界我有什么樣的服務，這類似Java的Interface。
2）SOAP(SimpleObjectApplicationPropotol)是WebService的標準通信協議，是一種標準化的傳輸消息的XML消息格式，以便大家都用同一種格式來講話，大家可以相互完全理解。SOAP請求(request)消息將客戶端的服務請求發給服務器，例如：需要調用什么樣的服務接口，以及接口參數值等。SOAP答復(respone)消息是從服務器返回給客戶端的消息，如服務接口實現后的結果返回值或調用服務時的錯誤信息等。
3）UDDI(Universal Description Discovery and Integeration)是一種創建注冊表服務的規范，以便大家將自已的 WebService 進行注冊供使用者查找。當服務提供者想將自己的 WebService 注冊到相應的UDDI商用注冊網站時，如IBM的/。服務提供者可以 SOAP 消息格式將自已的服務到這些網站。由于WSDL文件已給定了WebService 的地址URL，外部可直接通過WSDL 提供的 URL 進行相應的 WebService 調用。所以 UDDI 并不是一個必需的WebService 組件，服務方完全可以不進行 UDDI 注冊。
4Web服務的開發方式
完整的Web服務開發包括3個階段：開發、部署、。
1）開發階段：此階段包括邏輯模塊(Java Bean或EJB)的開發與部署，WSDL 定義文件的設計或生成。
2）部署階段：指定 Web 服務的傳輸協議(綁定)，明確服務的終端地址，創建 Web 的附屬文件，以平臺可識別的方式將 Web 服務注冊到相應服務描述部署文件。
3）階段：將 Web 服務的接口和調用地址公開給客戶端調用，常用的方式為提供WDSL鏈接，也可選擇 UDDI。
在開發階段，有兩種可以實施的方案：自上而下(top-down)方式，即先設計WSDL，即服務接口定義，然后生成服務邏輯代碼。自底向上(bottom-up)方式，即先完成業務邏輯代碼的開發或使用已經存在的邏輯代碼，再根據代碼暴露出服務的接口WSDL,包裝Web服務。這兩種方式都可以實施，現階段，自底向上的模式更常見，大多數的SOA應用都是基于當前的應用創建Web服務。
參考文獻：
[1] IBM Co.Service-oriented modeling and architecture[EB/OL].[2008-04-16]./developerworks/webservices/library/ws-soa-design1/.
篇7
本文對基于移動互聯網的WebService開發設計中的關鍵技術進行了深入的研究，其中包括WebService功能介紹與特點分析、支持手機調用的WebService服務端和客戶端開發設計，同時針對目前較為流行的兩大手機操作系統Andriod系統和IOS系統分別給出了客戶端設計思路，提出了一整套可以支持智能手機、平板電腦友好、高效訪問WebService的技術方法。實驗表明，本文提出的關鍵技術解決方案具有較好的實際操作性，能夠支持大部分基于WebService的移動網絡服務，對各類移動終端系統具有良好的兼容性。
【關鍵詞】移動互聯網 WebService 網絡服務端 Andriod系統 IOS系統
1 引言
隨著社會進程的加快和現代化水平的提高，程序間甚至部門間的應用與數據交換需求日益顯得迫切。而WebService通過web的方式向外界提供接口庫API，使得外部程序和應用能夠通過標準化的方法和結構進行友好調用，為跨平臺的數據交換和內部多業務的集成提供了通用機制。
與此同時，伴隨移動互聯網和智能手機大潮的來襲，移動應用的概念應運而生。移動應用對于解決業務處理的時效性，降低管理成本，方便用戶使用等各方面都具備突出優勢，能夠隨時、隨地、隨手獲取各類數據和服務，及時獲取重要的信息并處理工作。
因此，研究如何建立一套可行的基于移動互聯網的WebService開發設計方案，就有其現實意義。根據這一思想，本文從WebService特性分析、支持移動應用的服務端設計、Android客戶端設計和IOS客戶端設計等多個角度進行深入研究，著重解決WebService支持移動互聯網平臺中的關鍵問題。
2 WebService技術
WebService是的核心功能是實現程序在不同編程語言和運行平臺下輕松交換數據。WebService定位成接口的形式，基于XML消息封裝操作、執行指令和傳輸數據。WebService體系中有規范和相對嚴格的技術棧，包括信息傳輸和服務的標示、部署、實現等。以下是WebService的關鍵技術：
2.1 XML和HTTP
WebService以HTTP協議為基礎，在廣域網上實現信息的傳輸和對防火墻設備的穿透；而XML作為網絡數據傳輸的新標準，提供了可供擴展的標記功能。
簡單對象訪問協議SOAP （Simple Object Access Protocol）能夠在離散環境或者分布式系統中遠程執行命令同時完成數據交互，它以XML協議為基礎。SOAP規范由四部分組成：
（1）SOAP封裝體（envelop）：包含數據的收發對象和處理流程。
（2）SOAP數據編碼（encoding rules）：通過數據類型的描述來驅動應用。
（3）SOAP表達（RPC representation）：約定一種機制來執行遠程調用并返回應答。
（4）SOAP底層綁定（binding），通過底層的協議來約束交換信息的類型。
2.2 Web服務描述語言WSDL
Web服務描述語言應用XML結構來描述WebService的標準，成為了Web服務的接口定義語言，通過WSDL能夠描述WebService的三個基本屬性：
（1）服務提供的功能――提供哪些接口和操作形式
（2）服務的訪問方式――通過哪種協議和哪類結構交換數據
（3）服務的調用地址――服務提供的具體URL信息
2.3 通用描述、發現和集成協議UDDI
通用描述、發現和集成協議UDDI既作為WebService的信息注冊規范，同時也作為一種規范的編程接口。開發者能夠通過UDDI將自己的WebService出去。同時，其他用戶能夠通過查詢到特定服務的具體描述信息，通過動態綁定的方式連接該服務，從而進行遠程查詢和調用。
3 WebService服務端
WebService服務端的作用是提供一系列方法的集合（接口），供外部用戶和應用程序進行方便的交互。例如需要從某個部門獲取一些業務數據，服務提供者能夠通過編寫接口向用戶提供一套方法，從而達到數據共享的目的，而不用提供數據庫的使用權限。
開發WebService服務端流程如下：
（1）編寫一個對外接口。
（2）完成該接口的實現類。
（3）通過命令產生服務信息，并完成服務接口的整體描述。
隨著web容器的啟動，由以上配置形成的WebService應用就能夠為用戶提供對應的服務。
3.1 基于手機客戶端的WebService服務端開發
在計算機平臺的java客戶端中，普遍使用成熟的SOAP庫（比如CXF、XFire和Axis2，）提供創建服務器端、客戶端和網關SOAP操作的基本框架，但是對于效能較低的手機客戶端使用卻有很多問題。本文通過使用KSOAP類庫編寫webService服務端，可以支持手機客戶端完成webService調用。另外，對于企業級應用，webService服務端也可以采用hibernate和spring框架進一步增加效能。
3.1.1 編寫webservice代碼
在代碼中加入"@WebService"這個注釋，將類方法封裝成為一個webservice接口： @WebService
public interface CellClientService{
public String userLogin（@WebParam（name = "opPhone"） String opPhone， @WebParam（name = "loginPwd"） String loginPwd）；}
此過程中，手機端通過webservice參數中@WebParam（name = "***"）獲取服務。
為了提高傳輸的質量和效率，將服務器端返回的請求數據的數據先使用pojo類包裝，最后轉換為一個XML對象。
3.1.2 WebService接口實現類
接口的實現類，要加上相應注解。下面是關鍵代碼：
@WebService（endpointInterface = ".ws.CellClientService"）
public class CellClientServiceImpl implements CellClientService {
public String userLogin（String opPhone， String loginPwd） {
}}
3.1.3 WebService接口
設置接口配置清單中的address為該服務的的真實地址。在Tomcat下創建Web應用，將類為WebService，完成之后再訪問http：//host：port/webservice/services，能夠在列表中發現對應的服務。
3.1.4 測試的WebService接口
推薦使用soapUI軟件，它能從配置文件中解析生成對應的客戶端和服務端模擬，還具有負載等全程監控功能。
3.2 基于android平臺的客戶端開發
首先下載KSOAP包：ksoap2-android-assembly-2.5.5-jar-with-dependencies.jar包然后新建android項目，加入對該包的編譯引用，然后按照如下步驟調用：
（1）生成SoapObject 對象，根據WSDL的說明設置webService的命名空間，同時設定對應調用方法。如：
SoapObject request=new Soap Object （serviceNameSpace， getCity）；
（2）設置調用方法參數request.add Property（"參數名稱"，"參數值"）：
添加Web端Tomcat生成的接口地址與方法說明，手機確保能夠通過WIFI等手段連接至服 務器端。
（1）配置SOAP的請求相關信息：Soap Serialization Envelope envelope=new Soap Serialization Envelope（VER11）；
（2）注冊Envelope：（new MarshalBase 64（））.register（envelope）；
構建傳輸對象，并指定WSDL文檔存在的URL：
AndroidHttpTransport transport=new AndroidHttpTransport（serviceURL）；
（1）調用WebService：transport.call（serviceNameSpace+getWeatherbyCityName， envelope）；
（2）解析返回數據：最后從應用功能出發完成數據交互的具體方法，以XML格式進行數據的交互傳輸。以天氣預報為例，打開天氣預報服務（WSDL）的地址可以看到可供調用的方法，參照函數說明獲取城市列表：getSupportProvice，啟動調用并返回xml文檔，通過 listview來顯示。運行結果如圖1所示：
圖1：android客戶端演示
3.3 基于IOS的客戶端開發
同樣使用天氣預報的wsdl：
http：//.cn/WebServices/WeatherWebService.asmx？wsdl
然后根據wsdl生成SOAP消息體：
（1）添加一個類擴展，如圖2DDXMLElement+WSDL.h和DDXMLElement+WSDL.m。
在配置文件設置中，提供以下幾個方法：（見圖3）。
（2）SoapUtility 文件用來封裝soap消息。SoapUtility調用DDXMLElement+WSDL來實現。
（3）完成Soap消息的封裝準備，嘗試調用服務。這里分兩種調用方式：同步和異步。
if （isSync） {//同步方法
ResponseData *result= [soaprequest PostSync：postData]；
[self.result setText：result.Content]；}
else{//異步請求
[soaprequest PostAsync：postData Success：^（NSString *response） {
[self.result setText：response]；
} falure：^（NSError *response） {
[self.result setText：response.description]；}]；}
（4）解析XML。由于ios自帶的類解析xml比較繁瑣，本文使用的是GDataXML這個類庫。先添加libxml2.dylib類庫，然后對GDataXml進行配置
soap調用返回的數據經常放在：XXX中[6]，在webservice調用中可以直接提取出來一個xml，然后通過xml解析類進行解析：
1.讀取XXX的內容。
2.遍歷xml的所有內容返回數組。
至此，IOS客戶端能夠成功顯示服務返回的數據。
參考文獻
[1]蔡月茹，柳西玲等.Web Service基礎教程[M].北京：清華大學出版社，2005，1（26）.
[2]Scott Seely.SOAP：Cross Platform Web Service Development Using XML [M]. PH PTR，2002.
[3]Eric Armstrong. Java Web Service教程[M]. 北京：高等教育出版社，2006 （12）.
[4] 馬興錄.嵌入式軟件開發-基于Web Service的云端應用軟件開發[M].北京：化學工業出版社，2012.
[5]Gail Rahn Frederick， Rajesh Lal.智能手機Web標準開發實戰[M].北京：清華大學出版社，25-38，2010.
[6]饒俠，張堅，趙莉萍.徹底研究Android/iOS跨平臺Web [Z].上奇科技股份有限公司，88-95，2013.
作者簡介
呂梁（1983-），男，浙江省衢州市人。碩士研究生學歷。現為浙江省氣象信息網絡中心工程師，從事信息網絡和辦公自動化方面的研究。
胡永亮（1984-），男，浙江省溫州市人。大學本科學歷?，F為浙江省氣象信息網絡中心工程師，從事信息網絡和數據庫方面的研究。
肖云（1961-），男，浙江省杭州市人。大學本科學歷?，F為浙江省氣象信息網絡中心高級工程師，從事信息網絡和網絡安全方面的研究。
篇8
關鍵詞：Web Services 網絡在線出版
中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9416（2013）04-0053-01
1 Web Services的體系架構及核心技術
Web Services是用來描述一系列操作的接口，通過XML消息傳遞，網絡訪問這些接口。即通過WSDL描述及SOAP訪問，在商業注冊中心（UDDI），使得開發人員和相關的應用程序可以搜索并定位該服務。主要包括三大角色和三個操作：服務提供者（Service provider），服務（Service broker）和服務請求者（Service requester）通過（publish）、查找（find） 和綁定（bind）三類操作來將三大角色關聯起來。如（圖1）所示。
目前Web services的核心技術包括：XML，SOAP，WSDL與UDDI。
XML可擴展性標記語言（Extensible Markup Language）：它是Web Services技術的基礎，XML作為信息描述和交換的標準格式進行Web Services的調用、界面描述和Web Services的發現。
SOAP（Simple Object Access Protocol）簡單對象訪問協議：它是以XML編碼，包含請求服務器的方法調用和返回客戶端的數據。它基于XML的簡單協議，實現各種交換結構化的信息和類型信息。
WSDL（Web Services Description Language）Web Services 描述語言：使用XML進行Web Services描述?？梢詫⑵淇醋饕唤M服務訪問點，客戶端通過這些訪問點對這些服務進行訪問。
UDDI（Universal Description，Discovery and Integration）統一描述、發現和集成協議：是Web Services的服務注冊規范，以便被需要該服務的用戶發現和使用，可將UDDI視為Web服務的搜索引擎。
2 基于Web services網絡在線出版系統服務的實現
網絡在線出版系統中實現的最重要的服務就是實現系統的出版發行服務，關鍵技術是需要網絡客戶端與數據庫進行大量的數據交互操作。隨著Web Services技術的提出和不斷發展，Web Services技術為網絡在線出版系統的服務實現帶來了巨大改變，在客戶端和數據庫之間建立一種Web Service中間層，形成三層次的結構，客戶端通過SOAP協議只需要訪問和調用Web Service服務，就可以與應用程序數據庫連接起來?；赪eb Service的網絡在線出版系統，不僅增強了整個應用程序的安全性和可維護性，還簡化了客戶端的開發編程工作，縮短了開發周期，減少了客戶端代碼的冗余復雜度，方便了數據在客戶端和數據庫之間的數據交換。
因此，本系統是基于Web Service理念和技術而建立的多層次結構的網絡在線出版系統，實現了客戶端、中間層、服務器數據庫的三層模型?？蛻舳撕椭虚g層之間通過XML形式的SOAP消息的請求和響應實現通信：客戶端通過網頁交互界面向中間層的Web Service發送SOAP消息請求，中間層的Web Service接受請求后，調用相應的Web Service方法，連接訪問服務器中的數據庫，獲得有關數據或者對數據做進一步處理，然后通過Web Service把數據或者處理后的結果，以XML的形式保存并且返回給客戶端界面。其中，中間層的Web Service定義的方法只是提供相應的服務，它并不關心調用服務的用戶是作者、讀者、還是出版商，而是一個可重復使用的方法庫。
該系統實現的主要功能包括出版服務和系統的發行服務。出版服務包括：數字資源作者（或資源提供者）注冊、登錄功能；向網絡在線出版系統提交出版申請、按照作者ID號或申請單號查詢、修改申請單的功能；在申請單被出版商審核通過后，資源作者實現資源上傳，并查看、修改上傳的資源的功能；資源上傳后與出版商簽訂出版合同，并使用作者ID或者合同編號查詢合同的功能。發行服務包括：讀者用戶的注冊、登錄功能；讀者用戶按照資源名稱、價格、編號、出版時間等條件查詢、瀏覽網絡資源的功能；用戶將資源放入購物車，并提交購買、訂單查詢的功能，網絡電子資源在線下載的功能。
在整個系統服務中，客戶端的網頁提供了作者出版申請和資源上傳的操作界面和讀者瀏覽資源與購買、下載資源的操作界面，而實際功能的完成方法的是處于中間層的負責數據訪問和處理的Web Service服務。客戶端的網站給Web Service服務端發送相應的SOAP請求，然后調用Web Service中的相應服務方法，讀取和處理后端數據庫中數據，最后把處理結果以SOAP消息返回客戶端界面，從而實現網絡在線出版系統服務。
參考文獻
篇9
目前，12306電子商務平臺的建成投入，對鐵路貨運的發展起到了彌足輕重的作用，即簡化了客戶辦理托運的過程，更省去了托運人營業廳辦理業務的繁瑣手續。尤其是“五定班列”等貨運專列推出后，托運人可以選取自己的發貨日期、運輸車型等，對于“門到門”服務托運人來說更是可以做到“人在家中坐，收發天下貨”。但隨著12306的出現也為鐵路貨物的運輸組織、營銷帶來了新的問題：（1）五定班列滿載率低，有些甚至接近于零；（2）列車回空率高；（3）內部審查認定、最新班列計劃更新慢。這“一低、一高、一慢”主要就是由于推出鐵路貨運商務平臺后，鐵路原有的信息服務系統無法滿足平臺快速的信息交互的需求造成的。表1列出了目前鐵路貨物主要的信息服務系統。由此可知，由于各信息系統是在不同時期分別由不同設計人員設計實現的，其開發工具和數據庫系統各不相同，因此在信息整合上存在一定的難度。傳統的IT公司在處理企業信息系統融合方面，先后經歷了點到點的集成、第1代企業應用集成技術（公共對象請求體系結構/分布式組件對象模型、面向消息的中間件等技術）和基于業務流程管理/業務流程改進的第2代企業應用集成技術[1]。然而，對于鐵路運輸這樣一個信息傳輸量大、遺留信息系統多、后期新建或改建信息系統任務重的企業來說顯然無法滿足?；赟OA架構的信息服務系統，以其獨特的松耦合結構可以滿足鐵路貨運系統的需求。
2“門到門”電子商務信息服務系統分析
目前，鐵路的信息系統主要存在的問題有：（1）部分信息系統“孤島”化，嚴重影響了信息的暢通性，更造成了大量數據的重復輸入。（2）信息流轉速度緩慢，無法為鐵路的調度指揮、組織等決策提供最新的數據支持，造成了決策的滯后性。（3）信息接口“死板化”，外部預留接口少。如鐵水聯運，需要鐵路總公司商務平臺與港口的商務平臺擁有同步或異步的通信?！伴T到門”服務的實現需要信息流通道暢通、數據更新及時，這就需要一個統一的“平臺”整合來自12306電子商務平臺、內部運輸管理與運力保障等眾多信息服務系統，形成一個可在各原有模塊間跨應用、跨開發語言、跨數據格式的擁有推拉結合功能的信息中間通道。圖1列出了鐵路內部實現“門到門”運輸時的相關信息服務系統，在提供門到門服務期間這些系統各司其職又要通力合作。其中，貨運服務系統主要負責“門到門”服務客戶關系管理、對外信息及外部信息的匯總；運輸組織主要負責在貨物承運的車底安排、運行計劃安排、裝卸表1主要鐵路貨物服務系統系統名稱開發工具數據庫系統列車調度指揮系統TDCSVCOracle運輸調度管理系統TDMSC、JavaOracle貨物運輸管理系統FTMSC、VC、JavaDB2，Oracle，SQLServer集裝箱運輸管理信息系統C、C++、VB、VC、JavaOracle貨運營銷輔助決策系統FMDSC、DelphiOracle辦公信息系統OMISASP、.netOracle、Access車、貨物短程集卡拉運等；12306電子商務平臺則是一個網絡信息平臺，托運人通過它獲取各個路局子公司的貨運安排情況、預定車底，平臺收集托運人車底預定情況上報后對批復結果進行回復；貨運保障是鐵路內部的后勤保障系統，負責承運所需的基礎條件（電力、機車等）的保障。要保障“門到門”服務的實施需要綜合各系統的數據，如行車組織策劃系統需要結合貨運服務系統中的客戶季度貨運需求及貨運保障系統中的空閑車底狀況等制定月計劃與日計劃；12306平臺要根據日計劃與月計劃情況，計劃班列情況。要真正實現“門到門”，需要以12306為交易平臺，提供方便快捷的網絡服務；以車輛為中心構建業務管理系統，精確掌握車輛信息，調配運力資源；以客戶為中心構建貨運管理系統，提供更加人性化的貨運服務產品；結合預防為主的信息安全系統，保障鐵路信息高安全級別的需求及網絡電子交易的安全[2]。面向服務架構（SOA）運用開放的標準，把企業的業務功能包裝成標準的服務，通過透明的、與實現無關的接口來定義，服務被松散綁定，并且可以通過強調位置透明性和互操作性的通信協議進行調用[3]。SOA沒有包括特定的協議和調用服務的格式，可以應用于各種不同領域的數據整合及信息共享[4]。
3基于SOA的信息服務系統設計
企業應用集成經歷了從最初的點到點連接到基于消息的中間件再到基于SOA和ESB的發展歷程[5]。SOA架構在國內發展還處于起步階段，但在國外已成為企業IT整合的首選，也已有很多的成熟的產品，如Microsoft的Indigo平臺、IBM的企業服務總線（ESB，EnterpriseServicesBus）平臺、SUN的“SOAPath”（SOA路徑）服務導向架構。綜合考慮各種SOA特點與使用場景，本文采用的是IBM的ESB平臺。在SOA架構中將各系統功能封裝為可重用的服務，并在企業總線上進行注冊；當服務請求者需要調用服務時，總線偵聽請求信息，解釋并翻譯為服務提供者的信息格式與數據結構，路由請求信息；服務提供者完成其提供的服務后，總線回調服務結果，解釋并翻譯為服務請求者的信息格式與數據結構，路由信息至原服務請求者，這樣一個完整的服務調用才算完成。圖2所示是一種典型的服務體系結構圖。在新的“門到門”信息服務系統中，不需對原遺留系統做過多的改變，這些系統依然作為“門到門”信息服務系統的底層服務系統，負責底層的信息采集和現場的管理；12306電子商務平臺基本不需要做改變，進行原先的信息與結果回復操作，所不同的只是在SOA架構下，隨著信息交互效率的提高、速度的增加，可以提供給托運人更多更人性化的服務，貨物位置信息、預確報等信息更新也更加快捷?！伴T到門”信息服務系統以鐵路原有運輸服務系統為基礎，利用分布式結構組合已有系統的數據庫和應用系統，作為SOA架構的底層信息系統。運用服務描述語言（WSDL，WebServicesDescriptionLanguage）將數據應用層的系統（鐵路內部原有系統）功能封裝為服務，并在通用描述發現和集成（UDDI，UniversalDescriptionDiscoveryandIntegration）注冊表中進行注冊。此外，在預留系統的處理上，應注意系統劃分為服務時的粒度，劃分的粒度過粗會影響服務調用的靈活性，粒度過細則會增加后期服務封裝與調用時的任務量。服務層管理所有在注冊表里注冊過的服務，對相關的服務進行組合、刪除或合并等操作。此外，服務層中的ESB企業總線還負責當表現層調用應用層的功能模塊時，不同系統或應用程序之間的協議轉換、格式變換、數據傳輸及智能路由等功能；數據應用層不同服務之間的通信、數據應用層向應用層信息也由企業總線完成。應用層劃分的一些相對獨立的功能塊是服務層對底層服務進行封裝后，在UDDI中心注冊的服務接口，這些接口可以供表現層的平臺調用，也方便服務之間的彼此調用。12306平臺仍作為SOA架構下的表現層，其本身也可理解為一種特殊服務，負責信息，接收應用層的預確報等信息并顯示，同時也是托運人查詢信息時與表現層的接口，提供同步與異步的通信查詢與反饋。在服務層企業總線的功能實現上，國內外有很多成熟的基于XML的技術，對于我國這樣在鐵路內部以XML為消息傳輸語言的信息系統尤其適合。比如進行協議轉換時，運用名為橋接器的通道適配器將簡單對象訪問協議（SOAP，SimpleObjectAccessProtocal）消息連接；數據格式轉換方面可選擇XSLT語言，將不同格式的服務請求方的數據轉換為XML語言，再翻譯為注冊表中對應的服務提供者的數據格式；智能路由方面目前運用較多的是基于地址的WS-Routing（無狀態協議）和基于內容的WS-Notification（有關Web服務通知的規范）；此外，還可利用WS-BPEL（標準流程定義語言）對一些常用的造作流程或數據流程進行定義[8]；至于安全方面，可選擇WS-Security規范，在SOAP的擴展報頭寫入例如數字簽名的信息，再利用加密技術以HTTP協議傳輸。下文是一個簡單的在服務調用時，在消息源（即消息的核心內容）報頭前添加UsernameToken標簽，利用用戶名（Username）和密碼（Password）作為服務調用時的驗證依據的例子：<soap:Envelopexmlns:soap=“/2013/12/soap-envelope”soap:eneodingStyle=“/2013/12/soap-eneoding”><soap:Header><wsse:Securityxmlns:wsse="/ws/2013/12/secext"><wsse:UsernameToken><wsse:Username>JACK</wsse:Username><wsse:Password>Rose520</wsse:Password></wsse:UsernameToken></wsse:Security>//利用WS-Security規范在SOAP擴展表頭寫入驗證信息……//消息頭</soap:Header></soap:Body>……//消息本體，即內容</soap:Body></soap:Envelope>對于“門到門”服務來說，還要涉及很多與鐵路外部企業的接口，如集卡公司、防疫安儉等國家監管部門。在實際應用中，可以將這些部門的需要與鐵路交互的數據封裝為一個數據應用服務：鐵路可以通過ESB總線獲取集卡公司的貨物實時信息、監管部門的審批信息等；集卡公司可以取得需轉運貨物信息、監管部門也可以方便地實施監管。考慮到鐵路數據的高安全級別，在外部接口與內部網絡之間應設立足以滿足鐵路信息安全級別的物理防火墻，并實行嚴格的IP地址、身份認證。
4結束語
篇10
關鍵詞：Web服務；SSL；安全模型
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2011)13-3050-02
Discusses the Problem of Safety in Web Services
HE Ting1， HUANG Dong2
(1.Guizhou University Vocational and Technical College, Guiyang 550003, China; 2.China Nuclear Power Engineering Co., Ltd, Zhengzhou 450052, China)
Abstract: This paper mainly discussed the safety problems of web, in traditional web security problems are put forward on the basis of a reliable web service security model.
Key words: web service; SSL; security model
Web服務是Internet中最重要的服務之一，根據web訪問的結構，可以將web服務的安全威脅分為3類：web服務器的安全威脅、web瀏覽器的安全威脅以及服務器和瀏覽器之間通信的安全威脅。其中，web服務器和瀏覽器的安全問題是計算機系統自身的安全性問題，傳統的web安全性問題指的是服務器和瀏覽器之間通信的安全，本文主要討論了傳統的web安全性問題，并在此基礎上提出了構建一種可靠的Web服務的安全模型。
1 傳統的web服務安全解決方案
提供web服務安全的方法一種方法是使用IPSec，網絡層的IPSec對于Web 服務安全來說，是一個很重要的標準。同SSL/TLS一樣，它也提供主機審計認證，數據完整性和數據機密性的功能，使用IPSec的好處是它對終端用戶和應用是透明的，并能提供一種一般性的解決方案；另一種更一般的解決方案僅在TCP上實現安全，這種解決方案主要是安全套接字層（SSL）和傳輸層安全(TLS)協議，它們被用來提供傳輸層的Web服務安全，SSL/TLS在點對點（point-to-point）的會話中,可以完成包括審計，數據完整性，機密性這樣的要求。
SSL可以嵌入到特殊的軟件包中，例如Netscape和Microsoft Explorer瀏覽器都配置了SSL，大部分服務器也都實現了該協議。
1.1 SSL體系結構
SSL使用TCP提供一種可靠的端對端的安全服務。SSL不是單個協議，它由兩層協議組成。SSL中定義的三個較高層次協議分別是：握手協議、密碼變更規格協議和報警協議。SSL協議中兩個重要的問題是SSL會話和SSL連接，會話是客戶與服務器之間的一種關聯，連接是一種能夠提供合適服務類型的傳輸。
1.2 SSL記錄協議的運行流程
SSL記錄協議對各種更高層協議提供基本的安全服務。尤其是，超文本傳輸協議是為Web客戶端/服務器的交互提供傳輸服務的協議，它可以在SSL的頂層運行。記錄協議要傳輸應用消息是，先將數據分段成一些可操作的塊，然后選擇壓縮或不壓縮數據，再生成MAC、加密、添加頭并將最后的結果作為一個TCP分組送出。對收到的數據，首先解密，然后做完完整性驗證、解壓縮、重組，最后把數據遞送到更高層用戶。
1.3 握手協議
SSL最重要的部分是握手協議。這一協議允許客戶端和服務器相互認證，并協商加密和MAC算法以及用于保護SSL記錄中所發送數據加密密鑰。握手協議在任何應用數據被傳輸之前使用，由客戶端和服務器之間的一系列消息交換組成。
1.4 密碼計算
我們主要關注兩個問題：
1) 通過密鑰交換創建一個共享主密鑰。共享主密鑰是通過安全密鑰交換方式為本次會話創建的一個一次性48字節的值。創建過程分兩步完成。第一步：交換預備主密鑰。第二步：雙方計算主密鑰?？蛻舳撕头掌鞫及凑障旅娣椒ㄓ嬎阒髅荑€：
Master_secrect=Md5(pre_ Master_secrectOOSHA('A' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) OO
Md5(pre_ Master_secrectOOSHA('BB' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) OO
Md5(pre_ Master_secrectOOSHA('CC' OO
pre_ Master_secrectOOClientHello.randomOO
ServerHello.random)) O
其中，ClientHello.random和ServerHello.random是在初始hello消息中交換的兩個現時值。
2) 密碼參數產生。其方法是主密鑰利用散列函數來產生安全字節序列，字節序列足夠長以便生成所有需要的參數。
然而，僅有傳輸層和網絡層的這些安全機制是遠遠不夠的，Web服務的安全性是提供一種綜合的，全方位的安全保障。
2 構建一種可靠的Web服務的安全模型
2.1 Web服務的協議棧
Web服務體系架構中不同操作與交互的實現，則需要有一系列分層的協議規范，具體協議棧如表1所示。
Web服務能夠被服務請求者調用，則必須是能通過網絡進行訪問的，由于HTTP的普遍性，使它成為了Internet中Web服務的標準網絡協議。Web服務還能夠支持其它Internet協議，包括FTP與SMTP等。
2.2 Web服務的基本工作過程
要建立面向服務的集成系統可以利用Web服務。我們不用改變現有的各種應用，當然也不需要關心它們技術的不同(比如是java，還是.net),可以利用Web服務的消息驅動機制，使它們協同工作和交互。XML 消息傳遞是Web服務體系結構最重要的基礎，XML 消息傳遞的行業標準協議是SOAP，服務的調用者通過在傳輸層協議之上綁定SOAP消息來請求服務。Web服務的基本工作過程是通過發送SOAP消息到一個由URI來鑒別的服務點（由一個SOAP server來接受消息），來請求特定的Web服務(操作)，接收到消息的響應結果或者錯誤提示。在傳輸層之外，當消息數據被接受和中轉的時候，數據的完整性以及其他的安全信息就可能泄漏或者丟失。這要求Web服務的請求者/提供者必須信任那些中間節點對消息的獲得和處理（那些中間節點可能需要處理消息，生成新的消息）。
2.3 Web服務的安全模型
我們把Web服務的安全模型建立在三個層次上：傳輸層的點對點安全、應用服務級的安全和策略和端對端的安全性。在這三個層次的基礎上我們構建的Web服務的安全模型的工作流程是：
1） 服務方可以要求請求者的消息證明一組聲明（例如，名稱、許可、密鑰、性能等等）。這一組聲明和相關的信息就是端點策略。
2）請求方可以通過把安全令牌與消息關聯起來發送，使得消息既證明了發送者具有要求該操作又可以要求特定的操作的聲明。
3）如果請求者無法給出必需的聲明，那么請求者或它們的代表可以通過與其它Web服務聯系設法獲得必需的聲明。這里其它的Web 服務，指的是安全性令牌服務（security token service），我們接下來可以要求它們自己的一組聲明。安全性令牌服務通過簽發安全性令牌不同信任域之間的信任。
傳統的web服務安全性中的傳輸層的安全協議（如SSL/TLS），只能對全部的信息進行加密，而不能選擇性地對部分信息進行加密，導致在傳送大量數據的時將引發嚴重的性能問題。我們提出的web服務安全模型中的Web服務支持對SOAP消息的指定部分進行加密或簽名可以減少因安全處理而導致的性能損失，這是提高性能的另一個關鍵。我們可以把安全模型應用于基于Web服務的信息系統中，以期在保證安全的同時提高系統性能。
參考文獻：
[1] Stallings W.網絡安全基礎應用與標準[M].白國強,譯.3版.北京:清華大學出版社,2007:175-189.