導(dǎo)語：如何才能寫好一篇soap協(xié)議，這就需要搜集整理更多的資料和文獻(xiàn)，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

關(guān)鍵詞：J2ME soap XML嵌入式系統(tǒng)

1 引言

J2ME作為嵌入式系統(tǒng)應(yīng)用平臺(tái)得到了迅速的發(fā)展，JAVA語言固有的平臺(tái)無關(guān)性使得基于J2ME平臺(tái)的嵌入式應(yīng)用系統(tǒng)具有廣闊的前景。受限于嵌入式設(shè)備及消費(fèi)類電器硬件條件的限制，J2ME平臺(tái)提供的功能有限，如何能夠在有限的資源下拓展J2ME的功能，使得J2ME平臺(tái)能夠處理SOAP協(xié)議是本文研究的重點(diǎn)。

目前企業(yè)應(yīng)用正在向面向WEB服務(wù)的SOA架構(gòu)轉(zhuǎn)變，嵌入式系統(tǒng)與企業(yè)應(yīng)用系統(tǒng)的連接目前還處于TCP/IP協(xié)議、HTTP協(xié)議等比較初級(jí)的階段。隨著企業(yè)應(yīng)用系統(tǒng)提供的WEB服務(wù)日益廣泛和成熟，需要J2ME平臺(tái)提供處理SOAP協(xié)議的需求也越來越多。

SOA架構(gòu)是目前企業(yè)應(yīng)用系統(tǒng)廣泛部署的架構(gòu)，實(shí)現(xiàn)SOA的關(guān)鍵問題之一就是對(duì)SOAP協(xié)議的支持。本文分析了在J2ME平臺(tái)中實(shí)現(xiàn)SOAP協(xié)議處理遇到的問題，提出了相應(yīng)的解決方案。

2 j2ME介紹[1] [2] [3]

J2ME（Java 2 Platform Micro Edition）是為無線電子市場所設(shè)計(jì)的JAVA平臺(tái)，包括JVM規(guī)范和API規(guī)范。J2ME 定義了一套類庫和虛擬機(jī)技術(shù)，這些技術(shù)可以使用戶、服務(wù)提供商和設(shè)備制造商通過物理（有線）連接或無線連接，按照需要隨時(shí)使用豐富的應(yīng)用程序。J2ME同時(shí)提供了Java語言一貫的跨平臺(tái)性和安全性。

為了支持用戶和嵌入式市場提出的靈活性和可定制性要求，J2ME被設(shè)計(jì)得更加模塊化和可縮放化。J2ME在設(shè)備原有的操作系統(tǒng)上建造了3層軟件來實(shí)現(xiàn)這種要求：

1．JVM層：這層基于宿主操作系統(tǒng)，按照某一種J2ME的配置實(shí)現(xiàn)了JVM。

2．配置層：這層對(duì)于用戶可見度要低一些，但對(duì)簡表層非常重要。它針對(duì)不同市場的需求，定義了Java虛擬機(jī)的最小功能集合和Java類庫的最小集合。在J2ME設(shè)備中，JVM與配置層緊密相連，它們體現(xiàn)了每一類設(shè)備的基本功能。

3．簡表層：這層對(duì)于用戶和應(yīng)用程序提供者來說是最常見的。它針對(duì)特定市場的需求，定義了Java虛擬機(jī)的最小功能集合和Java類庫的最小集合。

J2ME組件都圍繞一個(gè)中心，這些中心被稱為configuration（配置），它們中間的每一個(gè)都是用于消費(fèi)電子和嵌入設(shè)備的特別的類。目前配置分為CLDC和CDC兩種。

Connected limited device configuration(有限連接設(shè)備配置，簡稱 CLDC)定義支持“devices that you hold in your hand（握在手中的設(shè)備）”的應(yīng)用程序接口和技術(shù)，這類設(shè)備的代表是PDA。Connected device configuration(連接設(shè)備配置 CDC )定義支持“devices that you plug into plug into the wall（插入墻的設(shè)備）”的應(yīng)用程序接口和技術(shù)，這類設(shè)備的代表是機(jī)頂盒。

這兩種配置不同的地方就在于它們應(yīng)用于的裝置的能力，CLDC設(shè)備的處理器能力有限 (與臺(tái)式機(jī)系統(tǒng)比較 )，并且存儲(chǔ)器大小一般也只在128 KB到 512 KB之間。CDC系統(tǒng)不同，它可能有32位或64位處理器，以及有限的存儲(chǔ)容量，不過它的下限也得超過512K。

上圖解釋配置和簡表的體系結(jié)構(gòu)。J2ME的體系結(jié)構(gòu)被橫向地分成三層，縱向分成兩部分。配置包括一個(gè)控制配置核心類的虛擬機(jī)，具體的簡表位于每個(gè)配置之上。

簡表為相同消費(fèi)電子設(shè)備的不同的生產(chǎn)商提供了標(biāo)準(zhǔn)化的 Java類庫，現(xiàn)在五個(gè)已知簡表已經(jīng)有了規(guī)范：

Mobile information devices profile (MIDP) 移動(dòng)電話和呼叫器 CLDC

Personal digital assistant profile Palm和Handspring的PDA 設(shè)備 CLDC

Foundation profile 用于所有不需要GUI的CDC設(shè)備的標(biāo)準(zhǔn)簡表 CDC

Personal profile 替代PersonalJava的Foundation完善的簡表 CDC

RMI profile 提供RMI的Foundation完善的簡表 CDC

3 SOAP協(xié)議介紹[4]

SOAP（簡單對(duì)象訪問協(xié)議）是一種利用XML編碼數(shù)據(jù)的數(shù)據(jù)傳輸協(xié)議。它是同類協(xié)議中要求最低的一個(gè)規(guī)范，只定義了協(xié)議所要求的最關(guān)鍵的部分，有意地忽略了垃圾收集、對(duì)象激活等方面的細(xì)節(jié)。像TCP/IP協(xié)議一樣，SOAP協(xié)議也包括客戶端和服務(wù)器兩個(gè)部分。

SOAP客戶端是一種創(chuàng)建XML文檔的程序，該XML文檔包含在分布式系統(tǒng)遠(yuǎn)程調(diào)用方法所需的信息。SOAP客戶端不是傳統(tǒng)意義上的程序，它除了用作普通的桌面應(yīng)用程序外，還可以是一種Web服務(wù)器或基于服務(wù)器的應(yīng)用程序。來自SOAP客戶端的消息和請(qǐng)求一般是通過HTTP發(fā)送的。因而，SOAP文檔可以穿過幾乎所有的防火墻，從而能跨越不同的平臺(tái)交換信息。

SOAP服務(wù)器只是用于監(jiān)聽SOAP消息的特殊代碼，它可用作SOAP文檔的分配器和解釋器。外部Web服務(wù)可以與基于J2EE技術(shù)的應(yīng)用程序服務(wù)器交互，這種應(yīng)用程序服務(wù)器可以處理多種客戶端的SOAP請(qǐng)求。

SOAP定義了數(shù)據(jù)編碼規(guī)則，稱為基準(zhǔn)編碼或“Section 5（第5節(jié)）”編碼，它是出自SOAP規(guī)范中描述數(shù)據(jù)編碼規(guī)則的內(nèi)容。SOAP編碼可以簡短地描述成簡單值或復(fù)合值的集合。簡單值可以是簡單類型，如整型、浮點(diǎn)型和字符型，或者是XML架構(gòu)規(guī)范第2部中定義的內(nèi)置類型，包括各種數(shù)據(jù)類型，如字節(jié)型數(shù)組和枚舉。復(fù)合值包括結(jié)構(gòu)、數(shù)組和XML架構(gòu)制定組定義的復(fù)雜類型。

SOAP在標(biāo)準(zhǔn)化消息格式環(huán)境中，可以做所有它能完成的工作。消息的主體部分是“text/xml”形式的MIME類型，并且包含一個(gè)SOAP封套。該封套是一個(gè)XML文檔。封套包含了報(bào)頭（可選的）和報(bào)文（必須有的）。封套的報(bào)文部分總是用于最終接收的消息，而報(bào)頭項(xiàng)目可以確定執(zhí)行中間處理的目標(biāo)節(jié)點(diǎn)。附件、二進(jìn)制數(shù)字及其他項(xiàng)目可以附加到報(bào)文上。

SOAP提供了一種讓客戶端指定哪個(gè)中間處理節(jié)點(diǎn)必須處理報(bào)頭項(xiàng)目的方法。由于報(bào)頭與SOAP消息的主體內(nèi)容是互不相關(guān)的，所以可用它們給消息添加信息，而不會(huì)影響對(duì)消息報(bào)文的處理。

4 SOAP協(xié)議在J2ME平臺(tái)中的實(shí)現(xiàn)

如何真正地將移動(dòng)設(shè)備融入到Web Services中去呢？這就需要使得PDA、手機(jī)等成為Web Services的客戶端，因此這些設(shè)備至少應(yīng)該具有處理XML信息的能力。在J2ME平臺(tái)中實(shí)現(xiàn)SOAP客戶端的功能，使得嵌入式設(shè)備能夠連接企業(yè)的WEB服務(wù)是企業(yè)應(yīng)用中比較常見的需求。J2ME的基本類庫中沒有提供SOAP的支持，所以需要在J2ME平臺(tái)中開發(fā)實(shí)現(xiàn)SOAP的處理功能。

實(shí)現(xiàn)SOAP協(xié)議客戶端的關(guān)鍵問題分為兩個(gè)方面：J2ME不同配置的數(shù)據(jù)類型不一樣，導(dǎo)致與SOAP協(xié)議封裝的數(shù)據(jù)類型不匹配；J2ME平臺(tái)沒有提供對(duì)XML文件進(jìn)行處理的功能。

針對(duì)第一個(gè)問題，需要注意只能使用基本類型，對(duì)不匹配的數(shù)據(jù)類型采用使用基本類型復(fù)合的方式進(jìn)行處理。針對(duì)第二個(gè)問題需要在J2ME中擴(kuò)展對(duì)XML文件處理的功能。目前有有兩種方法對(duì)XML文件進(jìn)行解析。一種是采用DOM的方式，另外一種是采用SAX的方式。操作DOM是一個(gè)與XML相互作用的簡單方法，通常這個(gè)XML是一棵完整的XML樹，被解析成一個(gè)存放在存儲(chǔ)器中的節(jié)點(diǎn)結(jié)構(gòu)，你可以遍歷這棵樹。它非常簡單易用，但是因?yàn)檎脴浯嬖谟诖鎯?chǔ)器中造成存儲(chǔ)器的負(fù)擔(dān)，而對(duì)于嵌入式系統(tǒng)來說存儲(chǔ)器的資源是有限的，因此這種方法的使用具有一定局限性。第二種方法在捕捉語法分析事件中，每當(dāng)語法分析程序遇到數(shù)據(jù)中的特定結(jié)構(gòu)，它就會(huì)遍歷XML數(shù)據(jù)，然后把結(jié)果發(fā)回前面注冊(cè)的一個(gè)事件監(jiān)聽器中。比如說，當(dāng)語法分析程序遇到一個(gè)起始標(biāo)記，如＜html＞，那么事件監(jiān)聽器將接收一個(gè)事件，通知它這個(gè)情況，并且向它傳遞任何所需的信息。相對(duì)DOM方式的處理，SAX方法對(duì)存儲(chǔ)器的要求比較低，但是效率要比DOM方式低。

Enhydra的KXML是一個(gè)只占很小存儲(chǔ)空間的XML語法分析程序，對(duì)于J2ME應(yīng)用程序非常適合。KXML支持DOM語法分析和操作，但是不支持SAX語法分析。取而代之，它使用一種稍微不同的稱為“Pull”的分析方法。

下面是KXML采用DOM的方式處理XML數(shù)據(jù)的例子：

1.Document doc = new Document();

2....

3.parser = new XmlParser(abc);

4.doc.parse( parser );

第一行創(chuàng)建了一個(gè)文檔對(duì)象，保存XML樹。第三行從一個(gè)名為abc的InputStreamReader中創(chuàng)建一個(gè)KXML語法分析程序。第四行傳送這個(gè)語法分析程序到文檔，然后讓文檔開始分析。XML被遞歸分析，直到到達(dá)文檔的結(jié)尾。當(dāng)分析調(diào)用退出時(shí)，整個(gè)文檔被裝入內(nèi)存，這時(shí)就可以對(duì)XML進(jìn)行操作了。

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標(biāo)記，如果子元素不是一個(gè)abc 標(biāo)記，則返回。

1.int address_item_count = kid.getChildCount();

2.

3. for (int j = 0; j ＜ abc_item_count ; j++) {

4....

如果找到了abc子元素，開始遍歷它的子元素，并把這些子元素的內(nèi)容打印出來。

通過KXML對(duì)XML的處理，可以進(jìn)一步實(shí)現(xiàn)對(duì)SOAP數(shù)據(jù)的處理，實(shí)現(xiàn)J2ME平臺(tái)對(duì)SOAP協(xié)議的支持。

J2ME Web Services規(guī)范（JSR172）的制訂給J2ME平臺(tái)增加兩大功能：一是使其能夠遠(yuǎn)程訪問基于SOAP/XML的Web Services；二是使其具有解析XML數(shù)據(jù)的能力。目前JSR172的標(biāo)準(zhǔn)已經(jīng)制定完成，為了實(shí)現(xiàn)這兩大功能，JSR172新定義了提供相應(yīng)功能的兩個(gè)可選包。這兩個(gè)包占用內(nèi)存非常少，XML-RPC部分大概需要25-30KB的空間，而XML解析器則需要35KB左右。

規(guī)范只對(duì)JAX-RPC的模型提供支持，也就是說僅支持同步的訪問方式，使用J2ME客戶端可以向服務(wù)器發(fā)送RPC請(qǐng)求和獲得RPC響應(yīng)。在JSR 172中實(shí)現(xiàn)的是SAX模式的解析器。能夠解析XML之前首先需要?jiǎng)?chuàng)建SAXParser的實(shí)例，

SAXParserFactory factory = SAXParserFactory.newInstance();

SAXParser saxParser = factory.newSAXParser();

接下來要獲得XML文件的輸入流，并把它作為其中一個(gè)參數(shù)傳遞給saxParser的parse方法，

InputStream is = this.getClass().getResourceAsStream("phone.xml");

SaxParser.parse(is，new BasicHandler(this));

DefaultHandler是SAX2默認(rèn)的事件處理器基類，用于處理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()

默認(rèn)情況下，DefaultHandler的上述方法什么也不做，因此必須自己擴(kuò)展DefaultHandler并且覆蓋上述的方法。程序中提供了一個(gè)BasicHandler用來處理xml文件。class BasicHandler extends DefaultHandler在BasicHandler類中有兩個(gè)成員變量

private Vector phones = new Vector();

private Stack tagStack = new Stack();

phones用來存儲(chǔ)我們已經(jīng)解析出來的Phone對(duì)象，tagStack則用來存放我們解析到的元素名稱，比如sonyericsson，phone，name，colour等。在文檔解釋結(jié)束后，也就是在endDocument()方法內(nèi)我們把解析的結(jié)果顯示在手機(jī)屏幕上，BasicHandler的幾個(gè)重要方法如下：

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 結(jié)束語

通過擴(kuò)充J2ME平臺(tái)對(duì)XML數(shù)據(jù)的處理，完成了J2ME平臺(tái)對(duì)SOAP協(xié)議的支持。通過SOAP協(xié)議能夠使得基于J2ME平臺(tái)的嵌入式設(shè)備無縫的連接到企業(yè)現(xiàn)有的應(yīng)用系統(tǒng)，解決了嵌入式設(shè)備數(shù)據(jù)來源不足的問題，擴(kuò)展了嵌入式系統(tǒng)的應(yīng)用范圍。本文從處理XML數(shù)據(jù)出發(fā)，深入探討了在J2ME平臺(tái)中實(shí)現(xiàn)SOAP客戶端的各種技術(shù)，對(duì)于企業(yè)應(yīng)用系統(tǒng)的集成具有一定的推廣價(jià)值。

參考文獻(xiàn)

[1] Yuan，Michael Juntao. Enterprise J2ME. Pearson Education 2003

[2] 胡虛懷，楊志，李煥. J2ME移動(dòng)設(shè)備程序設(shè)計(jì). 清華大學(xué)出版社 2005

篇2

關(guān)鍵詞：Web Service； XML； SOAP； 嵌入式系統(tǒng)

中圖分類號(hào)：TN91934； TP311文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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引言

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

1Web Service與SOAP協(xié)議

Web Service是網(wǎng)絡(luò)化應(yīng)用的一種，可以將其看成一種函數(shù)調(diào)用，只不過這個(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ù)格式采取一些約定措施，簡單對(duì)象訪問協(xié)議（Simple Object Access Protocol，SOAP）很好地應(yīng)對(duì)了這種需求［3］。SOAP協(xié)議以XML形式提供了一個(gè)簡單、輕量的機(jī)制，用于在分布環(huán)境中交換結(jié)構(gòu)化信息。SOAP本身并沒有定義任何應(yīng)用程序語義，如編程模型或特定語義的實(shí)現(xiàn)；實(shí)際上它通過提供一個(gè)模塊化的封包模型和在模塊中進(jìn)行數(shù)據(jù)編碼的方法，定義了一個(gè)簡單的表示應(yīng)用程序語義的機(jī)制［4］。

SOAP消息是由Envelope，Header和Body三部分組成的XML文檔，其中Envelope是SOAP消息的根元素，必須在SOAP消息中出現(xiàn)；可選的Header元素包含有關(guān) SOAP 消息的應(yīng)用程序?qū)Ｓ眯畔?；必需的Body元素包含打算傳送到消息最終端點(diǎn)的實(shí)際SOAP消息 ［5］。最后，為了進(jìn)行基于SOAP的遠(yuǎn)程調(diào)用，需要一種低級(jí)傳輸協(xié)議。SOAP規(guī)范允許使用HTTP，SMTP甚至原始的TCP/IP套接字，其中HTTP協(xié)議最為常用。

2Web Service在嵌入式環(huán)境下的實(shí)現(xiàn)

2.1底層軟硬件結(jié)構(gòu)

本文中所使用的硬件基于ST公司推出的ARM CortexM3 32位微處理器STM32F107VC［6］。CortexM3是針對(duì)價(jià)格敏感但又有高系統(tǒng)效能需求的嵌入式應(yīng)用而設(shè)計(jì)的ARM內(nèi)核，作為ARM7的后繼者，大刀闊斧地改革了設(shè)計(jì)架構(gòu)，顯著簡化了編程和調(diào)試的復(fù)雜度，處理能力也更加強(qiáng)大［7］。STM32F107VC工作頻率最高為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é)議棧lwIP組成底層軟件開發(fā)平臺(tái)。FreeRTOS作為一個(gè)免費(fèi)開源的小型實(shí)時(shí)內(nèi)核，主要用于建立和管理各個(gè)模塊的任務(wù)［8］；lwIP則為數(shù)據(jù)的TCP/IP封裝提供了一個(gè)良好的軟件基礎(chǔ)［9］。

2.2SOAP消息的處理

目前已經(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可以簡單的理解為HTTP+XML+遠(yuǎn)程調(diào)用規(guī)則，因此SOAP消息的處理也分為3步：HTTP協(xié)議的實(shí)現(xiàn)、XML解析、具體服務(wù)實(shí)現(xiàn)。其總體結(jié)構(gòu)如圖1所示。

圖1總體實(shí)現(xiàn)框架SOAP在HTTP上的遠(yuǎn)程調(diào)用的具體實(shí)現(xiàn)過程大致如下：客戶端通過SOAP工具生成基于XML文檔的SOAP消息，在該SOAP消息里包含有客戶請(qǐng)求的服務(wù)名稱及調(diào)用服務(wù)程序所需的參數(shù)，并使用HTTP POST方法通過網(wǎng)絡(luò)向應(yīng)用程序所在的服務(wù)端發(fā)送 SOAP請(qǐng)求；另一方面，當(dāng)服務(wù)端接到HTTP信息之后，又從中提取出SOAP 消息，啟動(dòng)XML文檔解析器進(jìn)行解析，獲取客戶需要調(diào)用的方法名及其參數(shù)，以此來調(diào)用相應(yīng)的服務(wù)程序，之后以類似的方法將運(yùn)行結(jié)果打包成SOAP消息返回給客戶，完成應(yīng)用程序的遠(yuǎn)程調(diào)用。

篇3

電子商務(wù)應(yīng)用系統(tǒng)的安全要素通常包括數(shù)據(jù)的機(jī)密性、完整性、用戶授權(quán)、身份的可鑒別性和不可否認(rèn)性等方面。將基于SOAP協(xié)議的WebServices[1]技術(shù)應(yīng)用到電子商務(wù)，雖然很好地解決了電子商務(wù)的應(yīng)用集成和分布式應(yīng)用，但由于SOAP協(xié)議是一個(gè)基于XML的輕量級(jí)協(xié)議，其設(shè)計(jì)目標(biāo)在于它的簡單性和可擴(kuò)展性，在制定時(shí)并沒有過多考慮安全性要求，加之SOAP協(xié)議規(guī)范本身沒有提供安全解決方案，因此在不安全的公用網(wǎng)絡(luò)傳輸時(shí)，SOAP消息中的敏感信息很容易被人竊聽、篡改或偽造，從而造成數(shù)據(jù)的泄密和數(shù)據(jù)完整性的破壞。電子商務(wù)中整個(gè)WebServices的通信，都是通過SOAP消息來實(shí)現(xiàn)的，若不能很好地解決SOAP消息的安全問題，則將極大阻礙WebServices在電子商務(wù)領(lǐng)域的應(yīng)用。

2SOAP消息安全性改進(jìn)

在電子商務(wù)應(yīng)用中，通信雙方常常通過交換商務(wù)文檔來進(jìn)行電子商務(wù)交易。發(fā)送方會(huì)將一個(gè)或多個(gè)文檔包裝在一個(gè)請(qǐng)求消息中，然后發(fā)送給接收方；接收方處理該消息的內(nèi)容后響應(yīng)發(fā)送方。當(dāng)一些業(yè)務(wù)應(yīng)用被調(diào)用后，一個(gè)包含業(yè)務(wù)文檔的請(qǐng)求將從SOAP發(fā)送者發(fā)送給SOAP接收者，而位于SOAP接收者端的業(yè)務(wù)應(yīng)用將處理這個(gè)請(qǐng)求并生成響應(yīng)，這個(gè)響應(yīng)被回送給發(fā)出該請(qǐng)求的SOAP發(fā)送者。商務(wù)文檔的網(wǎng)絡(luò)傳輸路徑上存在許多惡意的攻擊者，它們可以監(jiān)視網(wǎng)絡(luò)中傳輸?shù)南?，并可能按照傳輸消息的協(xié)議格式發(fā)送欺騙性的假消息或者對(duì)原消息的內(nèi)容進(jìn)行更改。比如攻擊者中途截取消息，對(duì)該消息進(jìn)行處理之后再轉(zhuǎn)發(fā)，這對(duì)電子商務(wù)的安全構(gòu)成極大的威脅。

通過對(duì)SOAP消息安全性研究發(fā)現(xiàn)，所有的攻擊都是對(duì)SOAP消息的修改，或者在SOAP消息的首部或?qū)嶓w刪除一些部分以及在后面附加一些內(nèi)容，或者添加一些全新的元素[2]。SOAP消息中的XML元素可能被處理而導(dǎo)致一些意外的修改，這會(huì)使得原SOAP消息中某些元素的前驅(qū)后繼關(guān)系被改變。而且意外的修改還可能導(dǎo)致SOAP消息中各元素的前驅(qū)、后繼以及兄弟元素的數(shù)量被改變，這樣原SOAP消息元素的層次結(jié)構(gòu)也被改變了。SOAP消息可以在傳送的過程中被擴(kuò)展，而在SOAP首部中沒有包含與SOAP消息的結(jié)構(gòu)相關(guān)的信息，而攻擊者利用最多的恰恰是SOAP的層次化結(jié)構(gòu)。所以，本文引入一個(gè)稱為SOAPRECORDER的數(shù)據(jù)結(jié)構(gòu)概念，它用來保存SOAP消息的動(dòng)態(tài)結(jié)構(gòu)信息。SOAPRECORDER的基本作用是在其中保存SOAP消息的各元素的結(jié)構(gòu)（例如：首部元素的個(gè)數(shù)、簽名對(duì)象的個(gè)數(shù)以及簽名對(duì)象的層次信息等等）。這些信息可以在SOAP消息的發(fā)送程序創(chuàng)建該SOAP消息的同時(shí)進(jìn)行計(jì)算，因此不會(huì)引起額外的開銷。

2.1SOAPRECORDER結(jié)構(gòu)

SOAPRECORDER信息的結(jié)構(gòu)如圖1所示。SOAPRECORDER中包括的內(nèi)容有：根結(jié)構(gòu)下的子元素的個(gè)數(shù)、首部元素的個(gè)數(shù)、簽名元素的參考項(xiàng)的個(gè)數(shù)、簽名對(duì)象之間的前驅(qū)、后繼以及兄弟關(guān)系和擴(kuò)展的部分。電子商務(wù)文檔在網(wǎng)絡(luò)傳輸時(shí)所受到的攻擊主要是利用SOAP消息結(jié)構(gòu)化語法的漏洞，所以解決這一問題的有效的手段就是在SOAP消息中添加SOAPRECORDER信息。消息的接收方在接收到SOAP消息的同時(shí)對(duì)消息的結(jié)構(gòu)信息進(jìn)行計(jì)算，然后與消息中的SOAPRECORDER信息進(jìn)行比較，如果兩者出現(xiàn)差異，則說明SOAP消息在傳送的途中受到了篡改攻擊。SOAP消息的發(fā)送者如果在消息中添加了SOAPRECORDER信息，那么在發(fā)送消息前必須對(duì)SOAPRECORDER信息也進(jìn)行簽名，以保證SOAPRECORDER信息在消息傳送途中不被篡改。

2.2SOAP消息加密傳輸

由于SOAP消息在網(wǎng)絡(luò)傳輸時(shí)受到威脅，所以要對(duì)其消息進(jìn)行加密傳輸。本文采用一種加密和數(shù)字簽名技術(shù)保證SOAP信息在公開網(wǎng)絡(luò)上的安全傳輸[3]。SOAP消息請(qǐng)求者先用哈希函數(shù)從原始信息和擴(kuò)展信息的組合信息中得到信息摘要SHash(M,W,Ex)，其中M為原始信息，W為需要嵌入的加密信息，Ex為擴(kuò)展信息。并用自己的私密鑰對(duì)信息摘要加密'()userSKSES，接著利用自己的對(duì)稱密鑰對(duì)三者的組合信息加密'(,,)userSSKWEMWEx，然后用服務(wù)提供者的公開密鑰對(duì)請(qǐng)求者的對(duì)稱密鑰加密''()userPKserverWESSK，這樣數(shù)字簽名的正確性就可以由任何請(qǐng)求者公開密鑰的人來驗(yàn)證；而加密后的對(duì)稱只有服務(wù)提供者能夠用私有密鑰解開，這樣就保證了SOAP信息在Internet傳輸過程中的安全。具體步驟如下：（l）數(shù)字簽名SHash(M,W,Ex)；'()userSKSES；（2）信息加密'(,,)userSSKWEMWEx；''()userPKserverWESSK；（3）數(shù)據(jù)傳輸''''UserServer:{S,W,W}；（4）Server信息解密''()serveruserSKSSKDW；（5）Server簽名驗(yàn)證（用得到的組合信息與哈希函數(shù)計(jì)算信息摘要，與解密后的信息摘要比較）''SHash(M,W,Ex)；'()userPKSDS；''?SS（比較兩者是否完全一致，如果一致，說明簽名正確，反之說明簽名無效）；服務(wù)請(qǐng)求者構(gòu)造SOAP消息，消息的Body部分包括上述三個(gè)方面的組合信息和服務(wù)的訪問參數(shù)。為保證消息不會(huì)被網(wǎng)絡(luò)上惡意破壞者篡改和偽造，對(duì)SOAP信息簽名和加密是必需的步驟。加密按照WS-Security中的XMLEncryption規(guī)范[4]，通過擴(kuò)展SOAP消息的Header的方式來實(shí)現(xiàn)。消息接收端在收到加密的SOAP請(qǐng)求后，解析SOAP消息的Header部分，得到服務(wù)請(qǐng)求者的X.509證書并驗(yàn)證其合法性。同時(shí)用私有密鑰解密SOAP消息中加過密的對(duì)稱密鑰W，并用對(duì)稱密鑰解密加過密的組合信息W，然后用哈希函數(shù)和得到的組合信息重新計(jì)算信息摘要，并與解密后的信息摘要比較。在成功判斷數(shù)字簽名的正確性后，從消息中取出原始數(shù)據(jù)。

3SOAP消息安全性實(shí)現(xiàn)

本文設(shè)計(jì)一個(gè)稱為SendSOAPRECORDER的模塊向在Web服務(wù)間進(jìn)行交互的SOAP消息中加入SOAPRECORDER信息。每一個(gè)SOAP消息的處理節(jié)點(diǎn)也都有一個(gè)相應(yīng)的CheckSOAPRECORDER模塊用來檢查接收到的SOAP消息的安全性。如圖2所示：當(dāng)處理節(jié)點(diǎn)接收到SOAP消息時(shí)，先把該SOAP消息發(fā)送到本節(jié)點(diǎn)的CheckSOAPRECORDER模塊進(jìn)行檢測(cè)，在經(jīng)過節(jié)點(diǎn)的所有檢測(cè)之后還要把該消息發(fā)送到本節(jié)點(diǎn)的SendSOAPRECORDER模塊添加本處理節(jié)點(diǎn)的SOAPRECORDER信息。于是每經(jīng)過一個(gè)處理節(jié)點(diǎn)，都會(huì)增加額外的兩條進(jìn)行SOAPRECORDER處理的消息。在一個(gè)節(jié)點(diǎn)傳送SOAP消息前，首先計(jì)算出該消息的SOAPRECORDER信息，并在SOAP消息的首部或?qū)嶓w中將該信息添加到一個(gè)作為SOAP信封元素形式存在的首部下面，然后對(duì)它進(jìn)行簽名和加密。SOAP消息傳送路徑上的每個(gè)中間節(jié)點(diǎn)也對(duì)SOAP消息做同樣的處理。SendSOAPRECORDER負(fù)責(zé)添加SOAPRECORDER信息。為了檢測(cè)網(wǎng)絡(luò)攻擊，CheckSOAPRECORDER模塊在接收到SOAP消息后會(huì)做一些常規(guī)的檢測(cè)。一旦有SOAP消息到達(dá)，CheckSOAPRECORDER模塊就會(huì)立即檢測(cè)SOAP消息中是否有作為SOAP首部存在的SOAPRECORDER首部。因?yàn)樵谛聜卧斓氖撞肯驴截惖腟OAPRECORDER信息已經(jīng)不再是作為一個(gè)獨(dú)立的SOAP首部而存在，所以CheckSOAPRECORDER模塊會(huì)立即拋出一個(gè)異常，警告消息接收者SOAPRECORDER信息已經(jīng)被人攻擊。如果包含該首部，CheckSOAPRECORDER模塊將校驗(yàn)SOAPRECORDER的簽名。如果SOAP消息傳送途中經(jīng)過了若干個(gè)中間處理節(jié)點(diǎn)，那么這些中間節(jié)點(diǎn)會(huì)在該消息中添加它們自己的SOAPRECORDER信息，這樣SOAPRECORDER的簽名可能出現(xiàn)嵌套的情況。如果簽名校驗(yàn)不正確，就說明SOAP消息已經(jīng)被惡意攻擊。

篇4

關(guān)鍵詞：Web服務(wù) 性能 優(yōu)化

簡單易用是Web服務(wù)的一個(gè)重要設(shè)計(jì)目標(biāo)。簡單易用性是通過對(duì)用戶屏蔽復(fù)雜性和更高層的抽象來達(dá)到的，這需要更多的計(jì)算資源開銷。因此，Web服務(wù)與傳統(tǒng)的分布式計(jì)算技術(shù)（如微軟的DOOM、Sun的Java RMI、CORBA）相比，性能具有一定的差距，最為突出的問題是Web服務(wù)的響應(yīng)時(shí)間和吞吐率等。在多數(shù)應(yīng)用中Web服務(wù)不會(huì)產(chǎn)生性能瓶頸，但是，在某些高負(fù)載、高吞吐率等對(duì)性能有較高要求的應(yīng)用中，Web服務(wù)的性能成為決定其是否能進(jìn)一步得到更加廣泛應(yīng)用的關(guān)鍵因素之一。Web服務(wù)日益成為異構(gòu)網(wǎng)絡(luò)環(huán)境下的主流分布式計(jì)算模式?；赬M L的數(shù)據(jù)傳輸格式在給Web服務(wù)帶來跨平臺(tái)性、松散耦合和良好的互操作性等優(yōu)點(diǎn)的同時(shí)，也在一定程度上影響了其性能。本文在分析Web服務(wù)性能的基礎(chǔ)之上，針對(duì)Web服務(wù)的額外性能開銷問題，以NET平臺(tái)為例，提出了使用緩存技術(shù)、SOAP壓縮技術(shù)和異步Web技術(shù)等策略實(shí)現(xiàn)Web服務(wù)性能的優(yōu)化。

一、Web服務(wù)的應(yīng)用模式

Web服務(wù)的應(yīng)用模式是一種基于SOAP、WS-DL、UDDI的面向服務(wù)的體系結(jié)構(gòu)（Service Oriented Architecture，SOA）。Web服務(wù)所提供的最簡單級(jí)別的應(yīng)用是使用SOAP協(xié)議和HTTP協(xié)議使Internet上的客戶端程序能夠使用Web服務(wù)。具體來說，一個(gè)客戶端請(qǐng)求是使用HTTP協(xié)議上的SOAP協(xié)議，然后經(jīng)由Internet進(jìn)行傳遞的Web服務(wù)發(fā)送響應(yīng)給客戶端應(yīng)用程序，該響應(yīng)是作為HTTP上的一個(gè)SOAP消息被發(fā)送的?？蛻舳苏?qǐng)求和Web服務(wù)響應(yīng)的SOAP消息主要是基于XM L格式的。由于Web服務(wù)主要使用HTTP和SOAP進(jìn)行通信，并且主要的供應(yīng)商都支持標(biāo)準(zhǔn)協(xié)議SOAP，避免了在CORBA、DOOM及其他協(xié)議之間進(jìn)行轉(zhuǎn)換，從而使Web服務(wù)具有跨平臺(tái)性、松散藕合和良好的互操作性。

二、影響Web服務(wù)性能的主要技術(shù)因素

通過針對(duì)Web服務(wù)基本架構(gòu)的分析，可知Web服務(wù)的運(yùn)行機(jī)制是建立在基于XM L的統(tǒng)一消息交換機(jī)制的基礎(chǔ)之上，影響Web服務(wù)請(qǐng)求響應(yīng)時(shí)間的主要因素是XM L消息的處理機(jī)制。因此，服務(wù)傳輸時(shí)間（即請(qǐng)求從客戶端到達(dá)服務(wù)端和響應(yīng)從服務(wù)端到達(dá)客戶端所用的時(shí)間）和XM L消息處理時(shí)間（即XM L解析、服務(wù)調(diào)用以及最后的應(yīng)答消息編碼所花的時(shí)間）是影響Web服務(wù)性能的主要因素。

第一，服務(wù)傳輸。在Web服務(wù)調(diào)用過程中，傳輸協(xié)議會(huì)對(duì)服務(wù)傳輸?shù)男阅茉斐芍匾挠绊?。SOAP協(xié)議大部分應(yīng)用是與HTTP協(xié)議進(jìn)行綁定的。HTTP采用一個(gè)無狀態(tài)的數(shù)據(jù)轉(zhuǎn)發(fā)機(jī)制，它只能處理單一方式的請(qǐng)求或應(yīng)答，這既是優(yōu)點(diǎn)也是缺點(diǎn)。一方面，由于缺少狀態(tài)使得HTTP累贅少，系統(tǒng)運(yùn)行效率高，服務(wù)器應(yīng)答快；另一方面，由于沒有狀態(tài)，協(xié)議對(duì)事務(wù)處理沒有記憶能力，若后續(xù)事務(wù)處理需要有關(guān)前面處理的信息，那么這些信息必須在協(xié)議外面保存。另外，缺少狀態(tài)意味著所需的前面信息必須重現(xiàn)，導(dǎo)致每次連接需要傳送較多的信息，造成了它的性能消耗。隨著電子商務(wù)的飛速發(fā)展，運(yùn)行在網(wǎng)絡(luò)上的用戶和數(shù)據(jù)量日益增加，在有限帶寬和網(wǎng)絡(luò)資源的條件下，HTTP顯然是制約Web服務(wù)性能的一個(gè)瓶頸。

第二，由于SOAP自身的特點(diǎn)導(dǎo)致在所傳輸數(shù)據(jù)的封裝編碼、解碼方面存在嚴(yán)重的性能問題，這些問題主要表現(xiàn)在將浮點(diǎn)數(shù)轉(zhuǎn)化為相應(yīng)的ASCII表示、將ASCII表示轉(zhuǎn)化為相應(yīng)的數(shù)據(jù)及從緩存中讀寫轉(zhuǎn)化后的數(shù)據(jù)，這些過程占據(jù)了整個(gè)通訊過程大概90%的時(shí)間。SOAP是一個(gè)基于XM L文本格式的協(xié)議，XM L雖然可讀性比較好，但是比一進(jìn)制實(shí)現(xiàn)的協(xié)議需要更多的帶寬、更大存儲(chǔ)能力和更長的處理時(shí)間，在很大程度上降低了Web服務(wù)的性能。此外，缺乏緩存或低效率緩存、低效的狀態(tài)處理錯(cuò)誤的使用線程、繁瑣的調(diào)用等問題都會(huì)加劇Web服務(wù)性能問題的嚴(yán)重性。

三、Web服務(wù)的性能優(yōu)化

第一，緩存技術(shù)。緩存（Cache）在計(jì)算機(jī)科學(xué)領(lǐng)域指的是一些數(shù)據(jù)副本的集合。當(dāng)原始數(shù)據(jù)訪問速度較慢時(shí)，可以通過使用在高速存儲(chǔ)區(qū)域中保存原始數(shù)據(jù)的常用數(shù)據(jù)副本，從而提升訪問速度。常見的硬盤緩存、CPU緩存、網(wǎng)頁緩存等都是緩存概念的應(yīng)用。由數(shù)據(jù)庫驅(qū)動(dòng)的Web應(yīng)用程序中，那些經(jīng)常被調(diào)用的并且對(duì)實(shí)時(shí)性要求不是很高的服務(wù)，使用緩存技術(shù)是一個(gè)十分有效的提高性能的方法。.NET平臺(tái)的Web服務(wù)充分考慮了對(duì)Cache的擊求，只要簡單地設(shè)定即可啟用Cache。對(duì)Web服務(wù)的調(diào)用也啟用Cache的機(jī)制，可以減少服務(wù)器端不必要的開銷。利用緩存技術(shù)，必須面對(duì)數(shù)據(jù)過期的問題（這也是實(shí)時(shí)系統(tǒng)比較少用的原因）。最典型的情況是，如果將數(shù)據(jù)庫表中的數(shù)據(jù)內(nèi)容緩存到服務(wù)器內(nèi)存中，當(dāng)數(shù)據(jù)庫表中的記錄發(fā)生更改時(shí)，Web應(yīng)用程序則很可能顯示過期的、不準(zhǔn)確的數(shù)據(jù)。這是不可接受的。解決這個(gè)問題的關(guān)鍵是在刪除或修改時(shí)根據(jù)Cache key來強(qiáng)制刪除該Cache項(xiàng)。綜上，對(duì)于一些經(jīng)常被調(diào)用的并且對(duì)實(shí)時(shí)性要求不是很高的Web方法，我們可以應(yīng)用這一屬性，設(shè)置一個(gè)合適的緩存時(shí)間用以減少調(diào)用的次數(shù)，從而減少服務(wù)器端的開銷。在一些不常調(diào)用，或者調(diào)用的參數(shù)是變換的Web方法，或者是實(shí)時(shí)性要求高的Web方法，可以減少Cache Duration屬性的使用，這將會(huì)減少服務(wù)器Cache的開銷。

第二，SOAP壓縮技術(shù)。由于Web服務(wù)主要使用SOAP協(xié)議作為標(biāo)準(zhǔn)通訊協(xié)議，因此，SOAP消息報(bào)文的解析、驗(yàn)證、編碼安全處理等對(duì)Web服務(wù)性能有最直接的影響。SOAP是基于XM L編碼的，而XM L文檔其實(shí)就是文本文檔。因此，SOAP消息也能夠看作一個(gè)文本流。假如采用壓縮文本流的方法將會(huì)大大提高網(wǎng)絡(luò)傳輸?shù)男剩p少傳輸?shù)臄?shù)據(jù)量，加速SOAP消息傳輸），從而也達(dá)到對(duì)Web服務(wù)性能的優(yōu)化。當(dāng)網(wǎng)絡(luò)傳輸?shù)膬?nèi)容是文本的時(shí)候，通過壓縮，它的尺寸能夠減少70%左右（不同的壓縮技術(shù)，壓縮比例不同）。這就意味著在客戶端和服務(wù)器之間帶寬的需求也能夠減少類似的白分比。所以壓縮是提高傳輸效率的最有效的方法，當(dāng)然為了壓縮和解壓縮，服務(wù)端和客戶端會(huì)增加自身CPU的負(fù)載。SOAP消息主要包括客戶端發(fā)出的SOAP請(qǐng)求消息和服務(wù)器端發(fā)出的SOAP響應(yīng)消息。通常情況下，服務(wù)器端的SOAP響應(yīng)消息要比客戶端的請(qǐng)求消息大。因此，壓縮服務(wù)器端的SOAP響應(yīng)消息對(duì)于性能的優(yōu)化的效果較為明顯。采用壓縮SOAP方式，特別是壓縮SOAP響應(yīng)消息的方式，降低了網(wǎng)絡(luò)上的數(shù)據(jù)傳輸量，可以達(dá)到優(yōu)化Web服務(wù)的性能，但同時(shí)也會(huì)帶來一個(gè)負(fù)面效果，如消息的壓縮和解壓縮需要額外的時(shí)間開銷，也會(huì)增加CPU的負(fù)載。

第三，異步Web技術(shù)。異步和同步的最主要的區(qū)分，簡單地講，就是異步?jīng)]有馬上返回結(jié)果，而同步則是馬上返回結(jié)果。常規(guī)的客戶端調(diào)用，當(dāng)調(diào)用Web服務(wù)時(shí)，由于服務(wù)器處理速度、網(wǎng)絡(luò)傳輸速度等各種原因會(huì)使一個(gè)Web服務(wù)從請(qǐng)求開始到獲得響應(yīng)結(jié)果之間等待一段時(shí)間，這時(shí)候線程會(huì)處于阻塞狀態(tài)，程序會(huì)等待請(qǐng)求結(jié)果導(dǎo)致客戶端無法進(jìn)行其他的動(dòng)作或處理。在.NET環(huán)境中，可以通過，asynchronism實(shí)現(xiàn)異步調(diào)用Web服務(wù)。即通過創(chuàng)建一個(gè)新的線程來執(zhí)行新的Web服務(wù)請(qǐng)求，這對(duì)程序的主線程不會(huì)產(chǎn)生影響。

常規(guī)的服務(wù)器端同步Web方法：當(dāng)從同步Web方法返回時(shí)，將發(fā)送對(duì)該方法的響應(yīng)。如果需要較長的時(shí)間來完成清求，則處理請(qǐng)求的線程會(huì)一直被占用，直到方法調(diào)用結(jié)束。服務(wù)器端為響應(yīng)多個(gè)請(qǐng)求，可能會(huì)建立多個(gè)線程，這樣可能會(huì)很快耗光系統(tǒng)資源。為了解決這個(gè)問題，就要考慮使用線程池技術(shù)。.NET運(yùn)行時(shí)提供了線程池的實(shí)現(xiàn)。對(duì)于異步方法調(diào)用由系統(tǒng)將方法提交給線程池，由線程池中的線程執(zhí)行。線程完成任務(wù)后，線程不會(huì)自行銷毀，而是以掛起狀態(tài)返回線程池。應(yīng)用程序每次向線程池發(fā)出請(qǐng)求，線程池會(huì)將掛起的線程激活并執(zhí)行任務(wù)，而不會(huì)創(chuàng)建新線程。當(dāng)然，在一個(gè)復(fù)雜的應(yīng)用程序中，用戶也許會(huì)同時(shí)請(qǐng)求多個(gè)Web服務(wù)，這時(shí)就得創(chuàng)建并控制多個(gè)線程。

綜上，客戶端的異步調(diào)用實(shí)現(xiàn)了請(qǐng)求和接收異步通信，解決了客戶端線程阻塞的問題。既滿足了調(diào)用多個(gè)Web服務(wù)的要求，又減少了響應(yīng)時(shí)間。而服務(wù)器端的線程池技術(shù)也很好地解決了服務(wù)器端同步Web方法的問題。當(dāng)然，多線程的控制雖然可以實(shí)現(xiàn)很好的應(yīng)用程序，但難度是比較大的，而且很容易引起異常。

四、結(jié)束語

隨著電了商務(wù)、電了政務(wù)的迅速崛起，基于Web服務(wù)的應(yīng)用模式己經(jīng)成為主流架構(gòu)，同時(shí)這也對(duì)Web服務(wù)的服務(wù)質(zhì)量（QoS，如服務(wù)的可用性、功效性和性能等）提出了更高的要求。本文在對(duì)Web服務(wù)的性能進(jìn)行分析的基礎(chǔ)上，針對(duì)Web服務(wù)的額外性能開銷問題，以.NET平臺(tái)為例，討論了使用緩存技術(shù)、SOAP壓縮技術(shù)和異步Web技術(shù)等策略在Web服務(wù)性能優(yōu)化中的應(yīng)用。Web服務(wù)性能優(yōu)化本身就是一個(gè)復(fù)雜的議題。除了采用上述幾種優(yōu)化的方法，還必須多方面地考慮優(yōu)化的問題，從系統(tǒng)設(shè)計(jì)到部署實(shí)現(xiàn)都需要考慮如何優(yōu)化改善其性能。如在Web服務(wù)接口設(shè)計(jì)時(shí)要充分考慮服務(wù)的粒度，配套開發(fā)工具（如、數(shù)據(jù)庫優(yōu)化）的優(yōu)化。

（作者單位：湖北工業(yè)大學(xué)計(jì)算機(jī)學(xué)院）

【參考文獻(xiàn)】

1、鄧海生,李軍懷,劉紅英.基于的Web服務(wù)性能優(yōu)化[J].計(jì)算機(jī)技術(shù)與發(fā)展,2007(10).

篇5

電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)是利用基于XML的WebService技術(shù),集成企業(yè)的現(xiàn)有系統(tǒng)。通過利用Web服務(wù),獲取電力企業(yè)的財(cái)務(wù)系統(tǒng)和生產(chǎn)系統(tǒng)中的已有數(shù)據(jù)進(jìn)行分析,完成情況分析、生產(chǎn)分析、經(jīng)營分析和綜合效益評(píng)價(jià)等項(xiàng)功能,從而為發(fā)電公司的生產(chǎn)經(jīng)營決策提供智力支持。通過提供Web服務(wù),支持用戶其他系統(tǒng)使用電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)的分析結(jié)果和數(shù)據(jù),例如,為企業(yè)網(wǎng)站提供發(fā)電量、營業(yè)額等統(tǒng)計(jì)信息。Web服務(wù)在電力經(jīng)濟(jì)活動(dòng)分析軟件中起到關(guān)鍵性的作用,生產(chǎn)系統(tǒng)和財(cái)務(wù)系統(tǒng)所提供的Web服務(wù),涉及生產(chǎn)、財(cái)務(wù)系統(tǒng)里的重要數(shù)據(jù),關(guān)系到企業(yè)的安全生產(chǎn)和運(yùn)營。所以如何在電力經(jīng)濟(jì)活動(dòng)分析軟件中構(gòu)建安全的Web服務(wù),使實(shí)施該項(xiàng)目需要重點(diǎn)考慮的問題。下面將從Web服務(wù)和其安全規(guī)范出發(fā),來介紹在電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)項(xiàng)目實(shí)施中,實(shí)現(xiàn)安全的Web服務(wù)。

1.Web服務(wù)和其安全性規(guī)范

(1)什么是Web服務(wù)

Web服務(wù)是一種完全建立在現(xiàn)有互聯(lián)網(wǎng)標(biāo)準(zhǔn)之上、松散耦合的、跨語言和平臺(tái)的應(yīng)用程序之間通信的標(biāo)準(zhǔn)方法。XMLWebService體系結(jié)構(gòu)的主要優(yōu)點(diǎn)之一是:允許在不同平臺(tái)上、以不同語言編寫的各種程序以基于標(biāo)準(zhǔn)的方式相互通信。雖然Web服務(wù)一經(jīng)出現(xiàn),便為各廠商接受和支持,但并沒有一個(gè)關(guān)于Web服務(wù)的統(tǒng)一的定義。廣泛接受的一個(gè)XMLWebService定義是:通過SOAP在Web上提供的軟件服務(wù),使用WSDL文件進(jìn)行說明,并通過UDDI進(jìn)行注冊(cè)。要實(shí)現(xiàn)一個(gè)完整的Web服務(wù)體系需要一系列的協(xié)議規(guī)范來支撐,如圖1所示:其中,第1、2層是已經(jīng)定義好的并且被廣泛使用的傳輸層和網(wǎng)絡(luò)層的標(biāo)準(zhǔn):IP、IITTP、SMTP等。而第3、4、5層是目前開發(fā)的Web服務(wù)的相關(guān)標(biāo)準(zhǔn)協(xié)議。SOAP(SimpleObjectAc-cessProtocol)是一個(gè)協(xié)議規(guī)范,定義了傳遞XML-encoded的數(shù)據(jù)時(shí)的統(tǒng)一方式,它還定義了使用HTTP作為底層通信協(xié)議時(shí)執(zhí)行遠(yuǎn)程調(diào)用(RPC)的方法。UDDI為客戶提供了動(dòng)態(tài)查找其它Web服務(wù)的機(jī)制。WSDL為服務(wù)提供了描述構(gòu)建在不同協(xié)議或編碼方式之上的Web服務(wù)請(qǐng)求基本格式的方法。

(2)Web服務(wù)的調(diào)用過程

利用Web服務(wù)可以建立面向服務(wù)的集成系統(tǒng)。即不用改變現(xiàn)有的各種應(yīng)用,也不關(guān)心它們技術(shù)的不同(比如是Java,還是.NET),利用Web服務(wù)的消息驅(qū)動(dòng)機(jī)制,讓它們協(xié)同工作和交互。Web服務(wù)體系最基礎(chǔ)的支柱是XML消息傳遞。XM消息傳遞的標(biāo)準(zhǔn)是SOAP,服務(wù)的請(qǐng)求者通過在傳輸層協(xié)議之上綁定SOAP消息來發(fā)送Web服務(wù)的請(qǐng)求。假設(shè)SOAP綁定在http之上,那么它就會(huì)利用http的請(qǐng)求/響應(yīng)消息模型,將SOAP請(qǐng)求放在http請(qǐng)求里面,服務(wù)的提供者將SOAP響應(yīng)的結(jié)果放在http響應(yīng)里面返回給Web服務(wù)的請(qǐng)求著。

(3)Web-Security規(guī)范

Web的基礎(chǔ)是簡單對(duì)象訪問協(xié)議(SOAP),它是在分布式環(huán)境中交換信息的簡單的XML文本協(xié)議,本身不涉及安全范疇。隨著各種基于Web服務(wù)應(yīng)用的發(fā)展,如電子商務(wù)、網(wǎng)上銀行等等,引出了人們對(duì)Web服務(wù)安全性的關(guān)注。WS-Security規(guī)范是構(gòu)建安全的Web服務(wù)應(yīng)用的基礎(chǔ)。該規(guī)范主要提供了三種機(jī)制:安全性令牌傳輸、消息完整性和消息機(jī)密性。通過提供安全性令牌來實(shí)現(xiàn)Web服務(wù)的授權(quán)訪問,安全性令牌包括普通的用戶名/密碼令牌以及X.509等證書令牌。后兩者是通過引入XML數(shù)字簽名和XML加密協(xié)議實(shí)現(xiàn)的。這些機(jī)制可以單獨(dú)使用,也可以組合使用,以實(shí)現(xiàn)不同強(qiáng)度的安全性。

2.Web服務(wù)關(guān)鍵安全手段

(1)加密技術(shù)

任何Web服務(wù)考慮其安全性,首先需要的一項(xiàng)重要安全技術(shù),就是在敏感數(shù)據(jù)通過開放網(wǎng)絡(luò)傳輸時(shí)提供保護(hù)。加密技術(shù)可以加密消息,從而保護(hù)敏感數(shù)據(jù)免遭暴露。加密技術(shù)還能保障消息的完整性。加密技術(shù)分為兩種:①秘密密鑰加密。又稱為“對(duì)稱密鑰加密”,通信雙方使用同一個(gè)加密密鑰來加密和解密消息。②公鑰加密。使用兩種不同但是在數(shù)學(xué)上相關(guān)的密鑰。使用公鑰加密技術(shù)時(shí),用公鑰來加密數(shù)據(jù),私鑰來解密數(shù)據(jù),也成為“不對(duì)稱加密”。公鑰密碼技術(shù)也可以用來創(chuàng)建以用戶的私鑰為基礎(chǔ)的不可偽造的數(shù)字簽名。正確標(biāo)示公鑰是公鑰證書的推動(dòng)因素。

(2)驗(yàn)證模型

Web服務(wù)安全性首先在于對(duì)用戶合法性的驗(yàn)證,也是Web服務(wù)授權(quán)和訪問控制的基礎(chǔ)。Web安全模型并沒有指明任何驗(yàn)證協(xié)議。用戶可采用任何認(rèn)為合適的方法來驗(yàn)證用戶。就目前的技術(shù)而言,驗(yàn)證主要可分為三類:①直接驗(yàn)證客戶端在使用Web服務(wù)時(shí),直接提交憑據(jù),例如用戶名和密碼,用作驗(yàn)證。②X.509證書驗(yàn)證用戶身份時(shí),另一個(gè)選擇足發(fā)送X.509證書。X.509證書確切地告訴web服務(wù)提供者用戶的身份。您可以使用PKI將此證書映射到應(yīng)用程序中的現(xiàn)有用戶。③Kerberos驗(yàn)證Kerberos驗(yàn)證包含客戶端向服務(wù)證明身份以及服務(wù)向客戶端證明身份的機(jī)制。要使用Kerberos,用戶需要提供一組憑據(jù)(例如用戶名/密碼或X.509證書)。如果所有內(nèi)容檢驗(yàn)合格,安全系統(tǒng)將授予用戶一個(gè)TGT(TicketGrantingTicket)。TGT是一個(gè)隱藏的數(shù)據(jù),用戶無法讀取,但必須提供它才能訪問其他資源。

(3)保護(hù)連接安全

保護(hù)XMLWebService安全的最簡單的一種方法就是確保XMLWebService客戶端與服務(wù)器之間的連接安全。根據(jù)網(wǎng)絡(luò)的范圍和交互操作的活動(dòng)配置文件,可以通過多種技術(shù)來達(dá)到這一目的。最流行也最廣泛使用的三種技術(shù)為:基于防火墻的規(guī)則、安全套接字層(SSL)和虛擬專用網(wǎng)絡(luò)(VPN)。

3.電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)Web服務(wù)安全功能的分析

(1)系統(tǒng)介紹

在給某發(fā)電企業(yè)實(shí)施的電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)中,該系統(tǒng)使用已有生產(chǎn)系統(tǒng)、財(cái)務(wù)系統(tǒng)的Web服務(wù)獲取基礎(chǔ)數(shù)據(jù),為用戶提供生產(chǎn)指標(biāo)統(tǒng)計(jì)分析、財(cái)務(wù)指標(biāo)統(tǒng)計(jì)分析、成本分析、利潤分析、歷史比較分析等功能。用戶即可通過瀏覽器、也可通過Web服務(wù)開發(fā)其它的用戶應(yīng)用來訪問這些功能。該系統(tǒng)功能結(jié)構(gòu)如圖2所示:對(duì)于使用Internet瀏覽器訪問的用戶,電力經(jīng)濟(jì)活動(dòng)分析軟件通過WebForm網(wǎng)頁作為用戶接口。用戶其他應(yīng)用程序獲取電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)的各種分析數(shù)據(jù),電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)獲取生產(chǎn)系統(tǒng)、財(cái)務(wù)系統(tǒng)的基礎(chǔ)數(shù)據(jù)也都是通過訪問生產(chǎn)系統(tǒng)、財(cái)務(wù)系統(tǒng)的Web服務(wù)實(shí)現(xiàn)的。

(2)消息流分析

電力經(jīng)濟(jì)活動(dòng)分析、生產(chǎn)系統(tǒng)、財(cái)務(wù)系統(tǒng)所有Web服務(wù)都是基于XML,提供WSDL(WebServiceDescriptionLanguage)定義的接口。用戶應(yīng)用使用這些Web服務(wù)是通過建立在HTTP協(xié)議之上的SOAP(SimpleObjectAccessProtocol)消息來訪問。圖3為電力經(jīng)濟(jì)活動(dòng)分析軟件中消息流圖。①用戶應(yīng)用通過HTTPS向電力經(jīng)濟(jì)活動(dòng)分析軟件發(fā)送一個(gè)SOAP請(qǐng)求。這個(gè)SOAP請(qǐng)求的header元素里包含用戶的用戶名和密碼。②電力經(jīng)濟(jì)活動(dòng)分析軟件成為了Web服務(wù)的請(qǐng)求方,發(fā)送SOAP消息給生產(chǎn)系統(tǒng)或財(cái)務(wù)系統(tǒng)。SOAP消息的header元素包含有自定義的二進(jìn)制令牌(一個(gè)X.509證書)。使用了X.509證書的公鑰來加密和簽名SOAP消息。③生產(chǎn)系統(tǒng)(財(cái)務(wù)系統(tǒng))給電力經(jīng)濟(jì)活動(dòng)分析軟件返回消息。SOAP的消息體使用了X.509證書的公鑰加密。④電力經(jīng)濟(jì)活動(dòng)分析軟件返回用戶的消息。在用戶和電力經(jīng)濟(jì)活動(dòng)分析軟件之間的SOAP消息交換,考慮到用戶都為企業(yè)內(nèi)員工,通過局域網(wǎng)訪問應(yīng)用,并結(jié)合響應(yīng)速度效率的因素,并沒有使用簽名和加密技術(shù)。我們對(duì)傳輸層使用SSL方式,來保證消息的一致性和完整性。利用SOAP消息的header元素包含用戶名和密碼來對(duì)用戶驗(yàn)證。由于生產(chǎn)系統(tǒng)、財(cái)務(wù)系統(tǒng)的安全對(duì)企業(yè)生產(chǎn)經(jīng)營至關(guān)重要,它們采用更嚴(yán)格的安全策略來對(duì)Web服務(wù)驗(yàn)證、保護(hù)。這兩個(gè)系統(tǒng)的Web服務(wù)都采用了X.509證書驗(yàn)證,數(shù)字簽名和加密技術(shù)保證Web服務(wù)的安全性。我們通過在生產(chǎn)系統(tǒng)和財(cái)務(wù)系統(tǒng)Web服務(wù)器的配置文件中,設(shè)置電力經(jīng)濟(jì)活動(dòng)分析軟件的證書和公鑰,便可實(shí)現(xiàn)電力經(jīng)濟(jì)活動(dòng)分析系統(tǒng)對(duì)生產(chǎn)和財(cái)務(wù)兩個(gè)系統(tǒng)的Web服務(wù)安全訪問。

篇6

關(guān)鍵詞：SOA；Web服務(wù)

中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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)是包含運(yùn)行環(huán)境、編程模型、架構(gòu)風(fēng)格和相關(guān)方法論等在內(nèi)的一整套新的分布式軟件系統(tǒng)構(gòu)造方法和環(huán)境，涵蓋服務(wù)的整個(gè)生命周期：建模－開發(fā)－整合－部署－運(yùn)行－管理。SOA是分布式軟件系統(tǒng)構(gòu)造方法和環(huán)境的新發(fā)展階段。

其基本要素是：

1）松散耦合：包括服務(wù)之間的松散耦合、接口和實(shí)現(xiàn)之間的松散耦合、業(yè)務(wù)組件和傳輸協(xié)議之間的松散耦合。

2）粗粒度：SOA服務(wù)接口應(yīng)比面向?qū)ο缶幊痰腁PI要大一些，更接近用戶的實(shí)際操作。

3）位置和傳輸協(xié)議透明：位置透明是指不論服務(wù)組件的實(shí)際位置URL如何變化，客戶的調(diào)用程序的URL都不需改變。傳輸協(xié)議的透明，就是指不管服務(wù)組件的傳輸協(xié)議如何變化，客戶端的調(diào)用程序的傳輸協(xié)議都不需要改變。

SOA的基本思想是面向服務(wù)，服務(wù)的本質(zhì)是業(yè)務(wù)和技術(shù)的分離，它超越于一切具體的技術(shù)，又包含一切具體的技術(shù)。SOA三個(gè)基本要素能消除目前IT系統(tǒng)集成的障礙，從而達(dá)到SOA的目標(biāo)：敏捷的，不受限制的業(yè)務(wù)集成。

1.2 SOA 和 Web Service 的根本區(qū)別

SOA是在 WebService 的基礎(chǔ)上發(fā)展起來的；而 WebServices 實(shí)現(xiàn)了松散耦合的服務(wù)和粗粒度的服務(wù)。雖然兩者都提供服務(wù)、服務(wù)接口都是基于開發(fā)的、接口與服務(wù)的具體實(shí)現(xiàn)都是分離的，但 Web Service 服務(wù)接口需要綁定具體實(shí)現(xiàn)服務(wù)的服務(wù)組件來實(shí)現(xiàn)服務(wù)，它對(duì)具體的服務(wù)實(shí)現(xiàn)完成了封裝，如圖1所示，實(shí)現(xiàn)了服務(wù)的透明化，客戶端不需知道服務(wù)是如何實(shí)現(xiàn)的，但客戶端調(diào)用 Web Service 組件時(shí)，還需要知道Web Service 的具置和傳輸協(xié)議，這將造成一定的不靈活性，因此它只是實(shí)現(xiàn)了一定程度上的抽象。

而SOA架構(gòu)平臺(tái)只和服務(wù)接口進(jìn)行綁定，對(duì)服務(wù)接口實(shí)現(xiàn)了封裝，如圖2所示，實(shí)現(xiàn)了服務(wù)接口的透明化，服務(wù)位置的透明化，傳輸協(xié)議的透明化。SOA 本身也不知道服務(wù)具體是如何實(shí)現(xiàn)的。當(dāng)客戶端通過SOA調(diào)用服務(wù)時(shí)，不需要知道真正的服務(wù)提供者是誰，具體的服務(wù)位置在哪里和具體的傳輸協(xié)議是什么。因此SOA實(shí)現(xiàn)了最高程度的抽象化，為實(shí)現(xiàn)具有最高靈活性的服務(wù)建立了架構(gòu)基礎(chǔ)。

2Web Service體系結(jié)構(gòu)

Web 服務(wù)是一種部署在 Web 上的對(duì)象或組件，Web 服務(wù)是基于 Web 服務(wù)提供者、Web 服務(wù)請(qǐng)求者、Web 服務(wù)中介者三個(gè)角色和、發(fā)現(xiàn)、綁定三個(gè)動(dòng)作構(gòu)建的。

服務(wù)提供者就是 Web 服務(wù)的擁有者，它向其他服務(wù)和用戶提供自己已有的功能；服務(wù)請(qǐng)求者就是Web服務(wù)功能的使用者，它利用 SOAP 消息向 Web 服務(wù)提供者發(fā)送請(qǐng)求以獲得服務(wù)；Web 服務(wù)中介者的作用是把一個(gè) Web 服務(wù)請(qǐng)求者與合適的服務(wù)者聯(lián)系在一起，充當(dāng)管理者角色，一般是 UDDI。在這些角色之間使用了三種操作：、發(fā)現(xiàn)、綁定。

1）服務(wù)提供者(ServiceProvider)可以自己的服務(wù)，并對(duì)請(qǐng)求使用服務(wù)進(jìn)行響應(yīng)；

2）服務(wù)注冊(cè)中心(Service Registry)用于注冊(cè)已經(jīng)的ServiceProvider，對(duì)其進(jìn)行分類，并提供搜索服務(wù)；

3）服務(wù)請(qǐng)求者(ServiceRequester)利用服務(wù)注冊(cè)中心查找所需服務(wù)，然后使用該服務(wù)。

所謂的WebService就是定義了一套標(biāo)準(zhǔn)的調(diào)用過程：

1）服務(wù)器端首先用一套標(biāo)準(zhǔn)的方法向外界描述它所提供的服務(wù)內(nèi)容，這屬于 WSDL；

2）客戶端需要以一種標(biāo)準(zhǔn)的協(xié)議來調(diào)用此服務(wù)，這屬于 SOAP (這也是WebService不同與其他組件如EJB的根本之處)

3）服務(wù)提供者將服務(wù)內(nèi)容放在一個(gè)公共的網(wǎng)址讓大家查詢，這屬于 UDDI。

3Web Service 三個(gè)組成部分

1）WSDL(WebServiceDescriptionLanguage)是一種基于XML格式的關(guān)于Web服務(wù)的描述語言，其主要目的在于提供者將自已的Web服務(wù)相關(guān)內(nèi)容，如服務(wù)傳輸方式、服務(wù)方法接口、接口參數(shù)、服務(wù)路徑等，生成相應(yīng)的文檔，給使用者。使用者通過這個(gè)WSDL文檔，創(chuàng)建相應(yīng)的 SOAP 請(qǐng)求，通過 HTTP 傳遞給提供者；Web 服務(wù)在完成服務(wù)請(qǐng)求后，將 SOAP 返回(response)消息傳回請(qǐng)求者，服務(wù)請(qǐng)求者再根據(jù) WSDL 文檔將 SOAP 返回消息解析成自已能理解的內(nèi)容。

WSDL 的目的就是告訴外界我有什么樣的服務(wù)，這類似Java的Interface。

2）SOAP(SimpleObjectApplicationPropotol)是WebService的標(biāo)準(zhǔn)通信協(xié)議，是一種標(biāo)準(zhǔn)化的傳輸消息的XML消息格式，以便大家都用同一種格式來講話，大家可以相互完全理解。SOAP請(qǐng)求(request)消息將客戶端的服務(wù)請(qǐng)求發(fā)給服務(wù)器，例如：需要調(diào)用什么樣的服務(wù)接口，以及接口參數(shù)值等。SOAP答復(fù)(respone)消息是從服務(wù)器返回給客戶端的消息，如服務(wù)接口實(shí)現(xiàn)后的結(jié)果返回值或調(diào)用服務(wù)時(shí)的錯(cuò)誤信息等。

3）UDDI(Universal Description Discovery and Integeration)是一種創(chuàng)建注冊(cè)表服務(wù)的規(guī)范，以便大家將自已的 WebService 進(jìn)行注冊(cè)供使用者查找。當(dāng)服務(wù)提供者想將自己的 WebService 注冊(cè)到相應(yīng)的UDDI商用注冊(cè)網(wǎng)站時(shí)，如IBM的/。服務(wù)提供者可以 SOAP 消息格式將自已的服務(wù)到這些網(wǎng)站。由于WSDL文件已給定了WebService 的地址URL，外部可直接通過WSDL 提供的 URL 進(jìn)行相應(yīng)的 WebService 調(diào)用。所以 UDDI 并不是一個(gè)必需的WebService 組件，服務(wù)方完全可以不進(jìn)行 UDDI 注冊(cè)。

4Web服務(wù)的開發(fā)方式

完整的Web服務(wù)開發(fā)包括3個(gè)階段：開發(fā)、部署、。

1）開發(fā)階段：此階段包括邏輯模塊(Java Bean或EJB)的開發(fā)與部署，WSDL 定義文件的設(shè)計(jì)或生成。

2）部署階段：指定 Web 服務(wù)的傳輸協(xié)議(綁定)，明確服務(wù)的終端地址，創(chuàng)建 Web 的附屬文件，以平臺(tái)可識(shí)別的方式將 Web 服務(wù)注冊(cè)到相應(yīng)服務(wù)描述部署文件。

3）階段：將 Web 服務(wù)的接口和調(diào)用地址公開給客戶端調(diào)用，常用的方式為提供WDSL鏈接，也可選擇 UDDI。

在開發(fā)階段，有兩種可以實(shí)施的方案：自上而下(top-down)方式，即先設(shè)計(jì)WSDL，即服務(wù)接口定義，然后生成服務(wù)邏輯代碼。自底向上(bottom-up)方式，即先完成業(yè)務(wù)邏輯代碼的開發(fā)或使用已經(jīng)存在的邏輯代碼，再根據(jù)代碼暴露出服務(wù)的接口WSDL,包裝Web服務(wù)。這兩種方式都可以實(shí)施，現(xiàn)階段，自底向上的模式更常見，大多數(shù)的SOA應(yīng)用都是基于當(dāng)前的應(yīng)用創(chuàng)建Web服務(wù)。

參考文獻(xiàn)：

[1] IBM Co.Service-oriented modeling and architecture[EB/OL].[2008-04-16]./developerworks/webservices/library/ws-soa-design1/.

篇7

本文對(duì)基于移動(dòng)互聯(lián)網(wǎng)的WebService開發(fā)設(shè)計(jì)中的關(guān)鍵技術(shù)進(jìn)行了深入的研究，其中包括WebService功能介紹與特點(diǎn)分析、支持手機(jī)調(diào)用的WebService服務(wù)端和客戶端開發(fā)設(shè)計(jì)，同時(shí)針對(duì)目前較為流行的兩大手機(jī)操作系統(tǒng)Andriod系統(tǒng)和IOS系統(tǒng)分別給出了客戶端設(shè)計(jì)思路，提出了一整套可以支持智能手機(jī)、平板電腦友好、高效訪問WebService的技術(shù)方法。實(shí)驗(yàn)表明，本文提出的關(guān)鍵技術(shù)解決方案具有較好的實(shí)際操作性，能夠支持大部分基于WebService的移動(dòng)網(wǎng)絡(luò)服務(wù)，對(duì)各類移動(dòng)終端系統(tǒng)具有良好的兼容性。

【關(guān)鍵詞】移動(dòng)互聯(lián)網(wǎng) WebService 網(wǎng)絡(luò)服務(wù)端 Andriod系統(tǒng) IOS系統(tǒng)

1 引言

隨著社會(huì)進(jìn)程的加快和現(xiàn)代化水平的提高，程序間甚至部門間的應(yīng)用與數(shù)據(jù)交換需求日益顯得迫切。而WebService通過web的方式向外界提供接口庫API，使得外部程序和應(yīng)用能夠通過標(biāo)準(zhǔn)化的方法和結(jié)構(gòu)進(jìn)行友好調(diào)用，為跨平臺(tái)的數(shù)據(jù)交換和內(nèi)部多業(yè)務(wù)的集成提供了通用機(jī)制。

與此同時(shí)，伴隨移動(dòng)互聯(lián)網(wǎng)和智能手機(jī)大潮的來襲，移動(dòng)應(yīng)用的概念應(yīng)運(yùn)而生。移動(dòng)應(yīng)用對(duì)于解決業(yè)務(wù)處理的時(shí)效性，降低管理成本，方便用戶使用等各方面都具備突出優(yōu)勢(shì)，能夠隨時(shí)、隨地、隨手獲取各類數(shù)據(jù)和服務(wù)，及時(shí)獲取重要的信息并處理工作。

因此，研究如何建立一套可行的基于移動(dòng)互聯(lián)網(wǎng)的WebService開發(fā)設(shè)計(jì)方案，就有其現(xiàn)實(shí)意義。根據(jù)這一思想，本文從WebService特性分析、支持移動(dòng)應(yīng)用的服務(wù)端設(shè)計(jì)、Android客戶端設(shè)計(jì)和IOS客戶端設(shè)計(jì)等多個(gè)角度進(jìn)行深入研究，著重解決WebService支持移動(dòng)互聯(lián)網(wǎng)平臺(tái)中的關(guān)鍵問題。

2 WebService技術(shù)

WebService是的核心功能是實(shí)現(xiàn)程序在不同編程語言和運(yùn)行平臺(tái)下輕松交換數(shù)據(jù)。WebService定位成接口的形式，基于XML消息封裝操作、執(zhí)行指令和傳輸數(shù)據(jù)。WebService體系中有規(guī)范和相對(duì)嚴(yán)格的技術(shù)棧，包括信息傳輸和服務(wù)的標(biāo)示、部署、實(shí)現(xiàn)等。以下是WebService的關(guān)鍵技術(shù)：

2.1 XML和HTTP

WebService以HTTP協(xié)議為基礎(chǔ)，在廣域網(wǎng)上實(shí)現(xiàn)信息的傳輸和對(duì)防火墻設(shè)備的穿透；而XML作為網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)男聵?biāo)準(zhǔn)，提供了可供擴(kuò)展的標(biāo)記功能。

簡單對(duì)象訪問協(xié)議SOAP （Simple Object Access Protocol）能夠在離散環(huán)境或者分布式系統(tǒng)中遠(yuǎn)程執(zhí)行命令同時(shí)完成數(shù)據(jù)交互，它以XML協(xié)議為基礎(chǔ)。SOAP規(guī)范由四部分組成：

（1）SOAP封裝體（envelop）：包含數(shù)據(jù)的收發(fā)對(duì)象和處理流程。

（2）SOAP數(shù)據(jù)編碼（encoding rules）：通過數(shù)據(jù)類型的描述來驅(qū)動(dòng)應(yīng)用。

（3）SOAP表達(dá)（RPC representation）：約定一種機(jī)制來執(zhí)行遠(yuǎn)程調(diào)用并返回應(yīng)答。

（4）SOAP底層綁定（binding），通過底層的協(xié)議來約束交換信息的類型。

2.2 Web服務(wù)描述語言WSDL

Web服務(wù)描述語言應(yīng)用XML結(jié)構(gòu)來描述WebService的標(biāo)準(zhǔn)，成為了Web服務(wù)的接口定義語言，通過WSDL能夠描述WebService的三個(gè)基本屬性：

（1）服務(wù)提供的功能――提供哪些接口和操作形式

（2）服務(wù)的訪問方式――通過哪種協(xié)議和哪類結(jié)構(gòu)交換數(shù)據(jù)

（3）服務(wù)的調(diào)用地址――服務(wù)提供的具體URL信息

2.3 通用描述、發(fā)現(xiàn)和集成協(xié)議UDDI

通用描述、發(fā)現(xiàn)和集成協(xié)議UDDI既作為WebService的信息注冊(cè)規(guī)范，同時(shí)也作為一種規(guī)范的編程接口。開發(fā)者能夠通過UDDI將自己的WebService出去。同時(shí)，其他用戶能夠通過查詢到特定服務(wù)的具體描述信息，通過動(dòng)態(tài)綁定的方式連接該服務(wù)，從而進(jìn)行遠(yuǎn)程查詢和調(diào)用。

3 WebService服務(wù)端

WebService服務(wù)端的作用是提供一系列方法的集合（接口），供外部用戶和應(yīng)用程序進(jìn)行方便的交互。例如需要從某個(gè)部門獲取一些業(yè)務(wù)數(shù)據(jù)，服務(wù)提供者能夠通過編寫接口向用戶提供一套方法，從而達(dá)到數(shù)據(jù)共享的目的，而不用提供數(shù)據(jù)庫的使用權(quán)限。

開發(fā)WebService服務(wù)端流程如下：

（1）編寫一個(gè)對(duì)外接口。

（2）完成該接口的實(shí)現(xiàn)類。

（3）通過命令產(chǎn)生服務(wù)信息，并完成服務(wù)接口的整體描述。

隨著web容器的啟動(dòng)，由以上配置形成的WebService應(yīng)用就能夠?yàn)橛脩籼峁?duì)應(yīng)的服務(wù)。

3.1 基于手機(jī)客戶端的WebService服務(wù)端開發(fā)

在計(jì)算機(jī)平臺(tái)的java客戶端中，普遍使用成熟的SOAP庫（比如CXF、XFire和Axis2，）提供創(chuàng)建服務(wù)器端、客戶端和網(wǎng)關(guān)SOAP操作的基本框架，但是對(duì)于效能較低的手機(jī)客戶端使用卻有很多問題。本文通過使用KSOAP類庫編寫webService服務(wù)端，可以支持手機(jī)客戶端完成webService調(diào)用。另外，對(duì)于企業(yè)級(jí)應(yīng)用，webService服務(wù)端也可以采用hibernate和spring框架進(jìn)一步增加效能。

3.1.1 編寫webservice代碼

在代碼中加入"@WebService"這個(gè)注釋，將類方法封裝成為一個(gè)webservice接口： @WebService

public interface CellClientService{

public String userLogin（@WebParam（name = "opPhone"） String opPhone， @WebParam（name = "loginPwd"） String loginPwd）；}

此過程中，手機(jī)端通過webservice參數(shù)中@WebParam（name = "***"）獲取服務(wù)。

為了提高傳輸?shù)馁|(zhì)量和效率，將服務(wù)器端返回的請(qǐng)求數(shù)據(jù)的數(shù)據(jù)先使用pojo類包裝，最后轉(zhuǎn)換為一個(gè)XML對(duì)象。

3.1.2 WebService接口實(shí)現(xiàn)類

接口的實(shí)現(xiàn)類，要加上相應(yīng)注解。下面是關(guān)鍵代碼：

@WebService（endpointInterface = ".ws.CellClientService"）

public class CellClientServiceImpl implements CellClientService {

public String userLogin（String opPhone， String loginPwd） {

}}

3.1.3 WebService接口

設(shè)置接口配置清單中的address為該服務(wù)的的真實(shí)地址。在Tomcat下創(chuàng)建Web應(yīng)用，將類為WebService，完成之后再訪問http：//host：port/webservice/services，能夠在列表中發(fā)現(xiàn)對(duì)應(yīng)的服務(wù)。

3.1.4 測(cè)試的WebService接口

推薦使用soapUI軟件，它能從配置文件中解析生成對(duì)應(yīng)的客戶端和服務(wù)端模擬，還具有負(fù)載等全程監(jiān)控功能。

3.2 基于android平臺(tái)的客戶端開發(fā)

首先下載KSOAP包：ksoap2-android-assembly-2.5.5-jar-with-dependencies.jar包然后新建android項(xiàng)目，加入對(duì)該包的編譯引用，然后按照如下步驟調(diào)用：

（1）生成SoapObject 對(duì)象，根據(jù)WSDL的說明設(shè)置webService的命名空間，同時(shí)設(shè)定對(duì)應(yīng)調(diào)用方法。如：

SoapObject request=new Soap Object （serviceNameSpace， getCity）；

（2）設(shè)置調(diào)用方法參數(shù)request.add Property（"參數(shù)名稱"，"參數(shù)值"）：

添加Web端Tomcat生成的接口地址與方法說明，手機(jī)確保能夠通過WIFI等手段連接至服 務(wù)器端。

（1）配置SOAP的請(qǐng)求相關(guān)信息：Soap Serialization Envelope envelope=new Soap Serialization Envelope（VER11）；

（2）注冊(cè)Envelope：（new MarshalBase 64（））.register（envelope）；

構(gòu)建傳輸對(duì)象，并指定WSDL文檔存在的URL：

AndroidHttpTransport transport=new AndroidHttpTransport（serviceURL）；

（1）調(diào)用WebService：transport.call（serviceNameSpace+getWeatherbyCityName， envelope）；

（2）解析返回?cái)?shù)據(jù)：最后從應(yīng)用功能出發(fā)完成數(shù)據(jù)交互的具體方法，以XML格式進(jìn)行數(shù)據(jù)的交互傳輸。以天氣預(yù)報(bào)為例，打開天氣預(yù)報(bào)服務(wù)（WSDL）的地址可以看到可供調(diào)用的方法，參照函數(shù)說明獲取城市列表：getSupportProvice，啟動(dòng)調(diào)用并返回xml文檔，通過 listview來顯示。運(yùn)行結(jié)果如圖1所示：

圖1：android客戶端演示

3.3 基于IOS的客戶端開發(fā)

同樣使用天氣預(yù)報(bào)的wsdl：

http：//.cn/WebServices/WeatherWebService.asmx？wsdl

然后根據(jù)wsdl生成SOAP消息體：

（1）添加一個(gè)類擴(kuò)展，如圖2DDXMLElement+WSDL.h和DDXMLElement+WSDL.m。

在配置文件設(shè)置中，提供以下幾個(gè)方法：（見圖3）。

（2）SoapUtility 文件用來封裝soap消息。SoapUtility調(diào)用DDXMLElement+WSDL來實(shí)現(xiàn)。

（3）完成Soap消息的封裝準(zhǔn)備，嘗試調(diào)用服務(wù)。這里分兩種調(diào)用方式：同步和異步。

if （isSync） {//同步方法

ResponseData *result= [soaprequest PostSync：postData]；

[self.result setText：result.Content]；}

else{//異步請(qǐng)求

[soaprequest PostAsync：postData Success：^（NSString *response） {

[self.result setText：response]；

} falure：^（NSError *response） {

[self.result setText：response.description]；}]；}

（4）解析XML。由于ios自帶的類解析xml比較繁瑣，本文使用的是GDataXML這個(gè)類庫。先添加libxml2.dylib類庫，然后對(duì)GDataXml進(jìn)行配置

soap調(diào)用返回的數(shù)據(jù)經(jīng)常放在：XXX中[6]，在webservice調(diào)用中可以直接提取出來一個(gè)xml，然后通過xml解析類進(jìn)行解析：

1.讀取XXX的內(nèi)容。

2.遍歷xml的所有內(nèi)容返回?cái)?shù)組。

至此，IOS客戶端能夠成功顯示服務(wù)返回的數(shù)據(jù)。

參考文獻(xiàn)

[1]蔡月茹，柳西玲等.Web Service基礎(chǔ)教程[M].北京：清華大學(xué)出版社，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] 馬興錄.嵌入式軟件開發(fā)-基于Web Service的云端應(yīng)用軟件開發(fā)[M].北京：化學(xué)工業(yè)出版社，2012.

[5]Gail Rahn Frederick， Rajesh Lal.智能手機(jī)Web標(biāo)準(zhǔn)開發(fā)實(shí)戰(zhàn)[M].北京：清華大學(xué)出版社，25-38，2010.

[6]饒俠，張堅(jiān)，趙莉萍.徹底研究Android/iOS跨平臺(tái)Web [Z].上奇科技股份有限公司，88-95，2013.

作者簡介

呂梁（1983-），男，浙江省衢州市人。碩士研究生學(xué)歷。現(xiàn)為浙江省氣象信息網(wǎng)絡(luò)中心工程師，從事信息網(wǎng)絡(luò)和辦公自動(dòng)化方面的研究。

胡永亮（1984-），男，浙江省溫州市人。大學(xué)本科學(xué)歷?，F(xiàn)為浙江省氣象信息網(wǎng)絡(luò)中心工程師，從事信息網(wǎng)絡(luò)和數(shù)據(jù)庫方面的研究。

肖云（1961-），男，浙江省杭州市人。大學(xué)本科學(xué)歷?，F(xiàn)為浙江省氣象信息網(wǎng)絡(luò)中心高級(jí)工程師，從事信息網(wǎng)絡(luò)和網(wǎng)絡(luò)安全方面的研究。

篇8

關(guān)鍵詞：Web Services 網(wǎng)絡(luò)在線出版

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2013）04-0053-01

1 Web Services的體系架構(gòu)及核心技術(shù)

Web Services是用來描述一系列操作的接口，通過XML消息傳遞，網(wǎng)絡(luò)訪問這些接口。即通過WSDL描述及SOAP訪問，在商業(yè)注冊(cè)中心（UDDI），使得開發(fā)人員和相關(guān)的應(yīng)用程序可以搜索并定位該服務(wù)。主要包括三大角色和三個(gè)操作：服務(wù)提供者（Service provider），服務(wù)（Service broker）和服務(wù)請(qǐng)求者（Service requester）通過（publish）、查找（find） 和綁定（bind）三類操作來將三大角色關(guān)聯(lián)起來。如（圖1）所示。

目前Web services的核心技術(shù)包括：XML，SOAP，WSDL與UDDI。

XML可擴(kuò)展性標(biāo)記語言（Extensible Markup Language）：它是Web Services技術(shù)的基礎(chǔ)，XML作為信息描述和交換的標(biāo)準(zhǔn)格式進(jìn)行Web Services的調(diào)用、界面描述和Web Services的發(fā)現(xiàn)。

SOAP（Simple Object Access Protocol）簡單對(duì)象訪問協(xié)議：它是以XML編碼，包含請(qǐng)求服務(wù)器的方法調(diào)用和返回客戶端的數(shù)據(jù)。它基于XML的簡單協(xié)議，實(shí)現(xiàn)各種交換結(jié)構(gòu)化的信息和類型信息。

WSDL（Web Services Description Language）Web Services 描述語言：使用XML進(jìn)行Web Services描述?？梢詫⑵淇醋饕唤M服務(wù)訪問點(diǎn)，客戶端通過這些訪問點(diǎn)對(duì)這些服務(wù)進(jìn)行訪問。

UDDI（Universal Description，Discovery and Integration）統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議：是Web Services的服務(wù)注冊(cè)規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用，可將UDDI視為Web服務(wù)的搜索引擎。

2 基于Web services網(wǎng)絡(luò)在線出版系統(tǒng)服務(wù)的實(shí)現(xiàn)

網(wǎng)絡(luò)在線出版系統(tǒng)中實(shí)現(xiàn)的最重要的服務(wù)就是實(shí)現(xiàn)系統(tǒng)的出版發(fā)行服務(wù)，關(guān)鍵技術(shù)是需要網(wǎng)絡(luò)客戶端與數(shù)據(jù)庫進(jìn)行大量的數(shù)據(jù)交互操作。隨著Web Services技術(shù)的提出和不斷發(fā)展，Web Services技術(shù)為網(wǎng)絡(luò)在線出版系統(tǒng)的服務(wù)實(shí)現(xiàn)帶來了巨大改變，在客戶端和數(shù)據(jù)庫之間建立一種Web Service中間層，形成三層次的結(jié)構(gòu)，客戶端通過SOAP協(xié)議只需要訪問和調(diào)用Web Service服務(wù)，就可以與應(yīng)用程序數(shù)據(jù)庫連接起來?；赪eb Service的網(wǎng)絡(luò)在線出版系統(tǒng)，不僅增強(qiáng)了整個(gè)應(yīng)用程序的安全性和可維護(hù)性，還簡化了客戶端的開發(fā)編程工作，縮短了開發(fā)周期，減少了客戶端代碼的冗余復(fù)雜度，方便了數(shù)據(jù)在客戶端和數(shù)據(jù)庫之間的數(shù)據(jù)交換。

因此，本系統(tǒng)是基于Web Service理念和技術(shù)而建立的多層次結(jié)構(gòu)的網(wǎng)絡(luò)在線出版系統(tǒng)，實(shí)現(xiàn)了客戶端、中間層、服務(wù)器數(shù)據(jù)庫的三層模型。客戶端和中間層之間通過XML形式的SOAP消息的請(qǐng)求和響應(yīng)實(shí)現(xiàn)通信：客戶端通過網(wǎng)頁交互界面向中間層的Web Service發(fā)送SOAP消息請(qǐng)求，中間層的Web Service接受請(qǐng)求后，調(diào)用相應(yīng)的Web Service方法，連接訪問服務(wù)器中的數(shù)據(jù)庫，獲得有關(guān)數(shù)據(jù)或者對(duì)數(shù)據(jù)做進(jìn)一步處理，然后通過Web Service把數(shù)據(jù)或者處理后的結(jié)果，以XML的形式保存并且返回給客戶端界面。其中，中間層的Web Service定義的方法只是提供相應(yīng)的服務(wù)，它并不關(guān)心調(diào)用服務(wù)的用戶是作者、讀者、還是出版商，而是一個(gè)可重復(fù)使用的方法庫。

該系統(tǒng)實(shí)現(xiàn)的主要功能包括出版服務(wù)和系統(tǒng)的發(fā)行服務(wù)。出版服務(wù)包括：數(shù)字資源作者（或資源提供者）注冊(cè)、登錄功能；向網(wǎng)絡(luò)在線出版系統(tǒng)提交出版申請(qǐng)、按照作者ID號(hào)或申請(qǐng)單號(hào)查詢、修改申請(qǐng)單的功能；在申請(qǐng)單被出版商審核通過后，資源作者實(shí)現(xiàn)資源上傳，并查看、修改上傳的資源的功能；資源上傳后與出版商簽訂出版合同，并使用作者ID或者合同編號(hào)查詢合同的功能。發(fā)行服務(wù)包括：讀者用戶的注冊(cè)、登錄功能；讀者用戶按照資源名稱、價(jià)格、編號(hào)、出版時(shí)間等條件查詢、瀏覽網(wǎng)絡(luò)資源的功能；用戶將資源放入購物車，并提交購買、訂單查詢的功能，網(wǎng)絡(luò)電子資源在線下載的功能。

在整個(gè)系統(tǒng)服務(wù)中，客戶端的網(wǎng)頁提供了作者出版申請(qǐng)和資源上傳的操作界面和讀者瀏覽資源與購買、下載資源的操作界面，而實(shí)際功能的完成方法的是處于中間層的負(fù)責(zé)數(shù)據(jù)訪問和處理的Web Service服務(wù)。客戶端的網(wǎng)站給Web Service服務(wù)端發(fā)送相應(yīng)的SOAP請(qǐng)求，然后調(diào)用Web Service中的相應(yīng)服務(wù)方法，讀取和處理后端數(shù)據(jù)庫中數(shù)據(jù)，最后把處理結(jié)果以SOAP消息返回客戶端界面，從而實(shí)現(xiàn)網(wǎng)絡(luò)在線出版系統(tǒng)服務(wù)。

參考文獻(xiàn)

篇9

目前，12306電子商務(wù)平臺(tái)的建成投入，對(duì)鐵路貨運(yùn)的發(fā)展起到了彌足輕重的作用，即簡化了客戶辦理托運(yùn)的過程，更省去了托運(yùn)人營業(yè)廳辦理業(yè)務(wù)的繁瑣手續(xù)。尤其是“五定班列”等貨運(yùn)專列推出后，托運(yùn)人可以選取自己的發(fā)貨日期、運(yùn)輸車型等，對(duì)于“門到門”服務(wù)托運(yùn)人來說更是可以做到“人在家中坐，收發(fā)天下貨”。但隨著12306的出現(xiàn)也為鐵路貨物的運(yùn)輸組織、營銷帶來了新的問題：（1）五定班列滿載率低，有些甚至接近于零；（2）列車回空率高；（3）內(nèi)部審查認(rèn)定、最新班列計(jì)劃更新慢。這“一低、一高、一慢”主要就是由于推出鐵路貨運(yùn)商務(wù)平臺(tái)后，鐵路原有的信息服務(wù)系統(tǒng)無法滿足平臺(tái)快速的信息交互的需求造成的。表1列出了目前鐵路貨物主要的信息服務(wù)系統(tǒng)。由此可知，由于各信息系統(tǒng)是在不同時(shí)期分別由不同設(shè)計(jì)人員設(shè)計(jì)實(shí)現(xiàn)的，其開發(fā)工具和數(shù)據(jù)庫系統(tǒng)各不相同，因此在信息整合上存在一定的難度。傳統(tǒng)的IT公司在處理企業(yè)信息系統(tǒng)融合方面，先后經(jīng)歷了點(diǎn)到點(diǎn)的集成、第1代企業(yè)應(yīng)用集成技術(shù)（公共對(duì)象請(qǐng)求體系結(jié)構(gòu)/分布式組件對(duì)象模型、面向消息的中間件等技術(shù)）和基于業(yè)務(wù)流程管理/業(yè)務(wù)流程改進(jìn)的第2代企業(yè)應(yīng)用集成技術(shù)[1]。然而，對(duì)于鐵路運(yùn)輸這樣一個(gè)信息傳輸量大、遺留信息系統(tǒng)多、后期新建或改建信息系統(tǒng)任務(wù)重的企業(yè)來說顯然無法滿足。基于SOA架構(gòu)的信息服務(wù)系統(tǒng)，以其獨(dú)特的松耦合結(jié)構(gòu)可以滿足鐵路貨運(yùn)系統(tǒng)的需求。

2“門到門”電子商務(wù)信息服務(wù)系統(tǒng)分析

目前，鐵路的信息系統(tǒng)主要存在的問題有：（1）部分信息系統(tǒng)“孤島”化，嚴(yán)重影響了信息的暢通性，更造成了大量數(shù)據(jù)的重復(fù)輸入。（2）信息流轉(zhuǎn)速度緩慢，無法為鐵路的調(diào)度指揮、組織等決策提供最新的數(shù)據(jù)支持，造成了決策的滯后性。（3）信息接口“死板化”，外部預(yù)留接口少。如鐵水聯(lián)運(yùn)，需要鐵路總公司商務(wù)平臺(tái)與港口的商務(wù)平臺(tái)擁有同步或異步的通信?！伴T到門”服務(wù)的實(shí)現(xiàn)需要信息流通道暢通、數(shù)據(jù)更新及時(shí)，這就需要一個(gè)統(tǒng)一的“平臺(tái)”整合來自12306電子商務(wù)平臺(tái)、內(nèi)部運(yùn)輸管理與運(yùn)力保障等眾多信息服務(wù)系統(tǒng)，形成一個(gè)可在各原有模塊間跨應(yīng)用、跨開發(fā)語言、跨數(shù)據(jù)格式的擁有推拉結(jié)合功能的信息中間通道。圖1列出了鐵路內(nèi)部實(shí)現(xiàn)“門到門”運(yùn)輸時(shí)的相關(guān)信息服務(wù)系統(tǒng)，在提供門到門服務(wù)期間這些系統(tǒng)各司其職又要通力合作。其中，貨運(yùn)服務(wù)系統(tǒng)主要負(fù)責(zé)“門到門”服務(wù)客戶關(guān)系管理、對(duì)外信息及外部信息的匯總；運(yùn)輸組織主要負(fù)責(zé)在貨物承運(yùn)的車底安排、運(yùn)行計(jì)劃安排、裝卸表1主要鐵路貨物服務(wù)系統(tǒng)系統(tǒng)名稱開發(fā)工具數(shù)據(jù)庫系統(tǒng)列車調(diào)度指揮系統(tǒng)TDCSVCOracle運(yùn)輸調(diào)度管理系統(tǒng)TDMSC、JavaOracle貨物運(yùn)輸管理系統(tǒng)FTMSC、VC、JavaDB2，Oracle，SQLServer集裝箱運(yùn)輸管理信息系統(tǒng)C、C++、VB、VC、JavaOracle貨運(yùn)營銷輔助決策系統(tǒng)FMDSC、DelphiOracle辦公信息系統(tǒng)OMISASP、.netOracle、Access車、貨物短程集卡拉運(yùn)等；12306電子商務(wù)平臺(tái)則是一個(gè)網(wǎng)絡(luò)信息平臺(tái)，托運(yùn)人通過它獲取各個(gè)路局子公司的貨運(yùn)安排情況、預(yù)定車底，平臺(tái)收集托運(yùn)人車底預(yù)定情況上報(bào)后對(duì)批復(fù)結(jié)果進(jìn)行回復(fù)；貨運(yùn)保障是鐵路內(nèi)部的后勤保障系統(tǒng)，負(fù)責(zé)承運(yùn)所需的基礎(chǔ)條件（電力、機(jī)車等）的保障。要保障“門到門”服務(wù)的實(shí)施需要綜合各系統(tǒng)的數(shù)據(jù)，如行車組織策劃系統(tǒng)需要結(jié)合貨運(yùn)服務(wù)系統(tǒng)中的客戶季度貨運(yùn)需求及貨運(yùn)保障系統(tǒng)中的空閑車底狀況等制定月計(jì)劃與日計(jì)劃；12306平臺(tái)要根據(jù)日計(jì)劃與月計(jì)劃情況，計(jì)劃班列情況。要真正實(shí)現(xiàn)“門到門”，需要以12306為交易平臺(tái)，提供方便快捷的網(wǎng)絡(luò)服務(wù)；以車輛為中心構(gòu)建業(yè)務(wù)管理系統(tǒng)，精確掌握車輛信息，調(diào)配運(yùn)力資源；以客戶為中心構(gòu)建貨運(yùn)管理系統(tǒng)，提供更加人性化的貨運(yùn)服務(wù)產(chǎn)品；結(jié)合預(yù)防為主的信息安全系統(tǒng)，保障鐵路信息高安全級(jí)別的需求及網(wǎng)絡(luò)電子交易的安全[2]。面向服務(wù)架構(gòu)（SOA）運(yùn)用開放的標(biāo)準(zhǔn)，把企業(yè)的業(yè)務(wù)功能包裝成標(biāo)準(zhǔn)的服務(wù)，通過透明的、與實(shí)現(xiàn)無關(guān)的接口來定義，服務(wù)被松散綁定，并且可以通過強(qiáng)調(diào)位置透明性和互操作性的通信協(xié)議進(jìn)行調(diào)用[3]。SOA沒有包括特定的協(xié)議和調(diào)用服務(wù)的格式，可以應(yīng)用于各種不同領(lǐng)域的數(shù)據(jù)整合及信息共享[4]。

3基于SOA的信息服務(wù)系統(tǒng)設(shè)計(jì)

企業(yè)應(yīng)用集成經(jīng)歷了從最初的點(diǎn)到點(diǎn)連接到基于消息的中間件再到基于SOA和ESB的發(fā)展歷程[5]。SOA架構(gòu)在國內(nèi)發(fā)展還處于起步階段，但在國外已成為企業(yè)IT整合的首選，也已有很多的成熟的產(chǎn)品，如Microsoft的Indigo平臺(tái)、IBM的企業(yè)服務(wù)總線（ESB，EnterpriseServicesBus）平臺(tái)、SUN的“SOAPath”（SOA路徑）服務(wù)導(dǎo)向架構(gòu)。綜合考慮各種SOA特點(diǎn)與使用場景，本文采用的是IBM的ESB平臺(tái)。在SOA架構(gòu)中將各系統(tǒng)功能封裝為可重用的服務(wù)，并在企業(yè)總線上進(jìn)行注冊(cè)；當(dāng)服務(wù)請(qǐng)求者需要調(diào)用服務(wù)時(shí)，總線偵聽請(qǐng)求信息，解釋并翻譯為服務(wù)提供者的信息格式與數(shù)據(jù)結(jié)構(gòu)，路由請(qǐng)求信息；服務(wù)提供者完成其提供的服務(wù)后，總線回調(diào)服務(wù)結(jié)果，解釋并翻譯為服務(wù)請(qǐng)求者的信息格式與數(shù)據(jù)結(jié)構(gòu)，路由信息至原服務(wù)請(qǐng)求者，這樣一個(gè)完整的服務(wù)調(diào)用才算完成。圖2所示是一種典型的服務(wù)體系結(jié)構(gòu)圖。在新的“門到門”信息服務(wù)系統(tǒng)中，不需對(duì)原遺留系統(tǒng)做過多的改變，這些系統(tǒng)依然作為“門到門”信息服務(wù)系統(tǒng)的底層服務(wù)系統(tǒng)，負(fù)責(zé)底層的信息采集和現(xiàn)場的管理；12306電子商務(wù)平臺(tái)基本不需要做改變，進(jìn)行原先的信息與結(jié)果回復(fù)操作，所不同的只是在SOA架構(gòu)下，隨著信息交互效率的提高、速度的增加，可以提供給托運(yùn)人更多更人性化的服務(wù)，貨物位置信息、預(yù)確報(bào)等信息更新也更加快捷?！伴T到門”信息服務(wù)系統(tǒng)以鐵路原有運(yùn)輸服務(wù)系統(tǒng)為基礎(chǔ)，利用分布式結(jié)構(gòu)組合已有系統(tǒng)的數(shù)據(jù)庫和應(yīng)用系統(tǒng)，作為SOA架構(gòu)的底層信息系統(tǒng)。運(yùn)用服務(wù)描述語言（WSDL，WebServicesDescriptionLanguage）將數(shù)據(jù)應(yīng)用層的系統(tǒng)（鐵路內(nèi)部原有系統(tǒng)）功能封裝為服務(wù)，并在通用描述發(fā)現(xiàn)和集成（UDDI，UniversalDescriptionDiscoveryandIntegration）注冊(cè)表中進(jìn)行注冊(cè)。此外，在預(yù)留系統(tǒng)的處理上，應(yīng)注意系統(tǒng)劃分為服務(wù)時(shí)的粒度，劃分的粒度過粗會(huì)影響服務(wù)調(diào)用的靈活性，粒度過細(xì)則會(huì)增加后期服務(wù)封裝與調(diào)用時(shí)的任務(wù)量。服務(wù)層管理所有在注冊(cè)表里注冊(cè)過的服務(wù)，對(duì)相關(guān)的服務(wù)進(jìn)行組合、刪除或合并等操作。此外，服務(wù)層中的ESB企業(yè)總線還負(fù)責(zé)當(dāng)表現(xiàn)層調(diào)用應(yīng)用層的功能模塊時(shí)，不同系統(tǒng)或應(yīng)用程序之間的協(xié)議轉(zhuǎn)換、格式變換、數(shù)據(jù)傳輸及智能路由等功能；數(shù)據(jù)應(yīng)用層不同服務(wù)之間的通信、數(shù)據(jù)應(yīng)用層向應(yīng)用層信息也由企業(yè)總線完成。應(yīng)用層劃分的一些相對(duì)獨(dú)立的功能塊是服務(wù)層對(duì)底層服務(wù)進(jìn)行封裝后，在UDDI中心注冊(cè)的服務(wù)接口，這些接口可以供表現(xiàn)層的平臺(tái)調(diào)用，也方便服務(wù)之間的彼此調(diào)用。12306平臺(tái)仍作為SOA架構(gòu)下的表現(xiàn)層，其本身也可理解為一種特殊服務(wù)，負(fù)責(zé)信息，接收應(yīng)用層的預(yù)確報(bào)等信息并顯示，同時(shí)也是托運(yùn)人查詢信息時(shí)與表現(xiàn)層的接口，提供同步與異步的通信查詢與反饋。在服務(wù)層企業(yè)總線的功能實(shí)現(xiàn)上，國內(nèi)外有很多成熟的基于XML的技術(shù)，對(duì)于我國這樣在鐵路內(nèi)部以XML為消息傳輸語言的信息系統(tǒng)尤其適合。比如進(jìn)行協(xié)議轉(zhuǎn)換時(shí)，運(yùn)用名為橋接器的通道適配器將簡單對(duì)象訪問協(xié)議（SOAP，SimpleObjectAccessProtocal）消息連接；數(shù)據(jù)格式轉(zhuǎn)換方面可選擇XSLT語言，將不同格式的服務(wù)請(qǐng)求方的數(shù)據(jù)轉(zhuǎn)換為XML語言，再翻譯為注冊(cè)表中對(duì)應(yīng)的服務(wù)提供者的數(shù)據(jù)格式；智能路由方面目前運(yùn)用較多的是基于地址的WS-Routing（無狀態(tài)協(xié)議）和基于內(nèi)容的WS-Notification（有關(guān)Web服務(wù)通知的規(guī)范）；此外，還可利用WS-BPEL（標(biāo)準(zhǔn)流程定義語言）對(duì)一些常用的造作流程或數(shù)據(jù)流程進(jìn)行定義[8]；至于安全方面，可選擇WS-Security規(guī)范，在SOAP的擴(kuò)展報(bào)頭寫入例如數(shù)字簽名的信息，再利用加密技術(shù)以HTTP協(xié)議傳輸。下文是一個(gè)簡單的在服務(wù)調(diào)用時(shí)，在消息源（即消息的核心內(nèi)容）報(bào)頭前添加UsernameToken標(biāo)簽，利用用戶名（Username）和密碼（Password）作為服務(wù)調(diào)用時(shí)的驗(yàn)證依據(jù)的例子：<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規(guī)范在SOAP擴(kuò)展表頭寫入驗(yàn)證信息……//消息頭</soap:Header></soap:Body>……//消息本體，即內(nèi)容</soap:Body></soap:Envelope>對(duì)于“門到門”服務(wù)來說，還要涉及很多與鐵路外部企業(yè)的接口，如集卡公司、防疫安儉等國家監(jiān)管部門。在實(shí)際應(yīng)用中，可以將這些部門的需要與鐵路交互的數(shù)據(jù)封裝為一個(gè)數(shù)據(jù)應(yīng)用服務(wù)：鐵路可以通過ESB總線獲取集卡公司的貨物實(shí)時(shí)信息、監(jiān)管部門的審批信息等；集卡公司可以取得需轉(zhuǎn)運(yùn)貨物信息、監(jiān)管部門也可以方便地實(shí)施監(jiān)管。考慮到鐵路數(shù)據(jù)的高安全級(jí)別，在外部接口與內(nèi)部網(wǎng)絡(luò)之間應(yīng)設(shè)立足以滿足鐵路信息安全級(jí)別的物理防火墻，并實(shí)行嚴(yán)格的IP地址、身份認(rèn)證。

4結(jié)束語

篇10

關(guān)鍵詞：Web服務(wù)；SSL；安全模型

中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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服務(wù)是Internet中最重要的服務(wù)之一，根據(jù)web訪問的結(jié)構(gòu)，可以將web服務(wù)的安全威脅分為3類：web服務(wù)器的安全威脅、web瀏覽器的安全威脅以及服務(wù)器和瀏覽器之間通信的安全威脅。其中，web服務(wù)器和瀏覽器的安全問題是計(jì)算機(jī)系統(tǒng)自身的安全性問題，傳統(tǒng)的web安全性問題指的是服務(wù)器和瀏覽器之間通信的安全，本文主要討論了傳統(tǒng)的web安全性問題，并在此基礎(chǔ)上提出了構(gòu)建一種可靠的Web服務(wù)的安全模型。

1 傳統(tǒng)的web服務(wù)安全解決方案

提供web服務(wù)安全的方法一種方法是使用IPSec，網(wǎng)絡(luò)層的IPSec對(duì)于Web 服務(wù)安全來說，是一個(gè)很重要的標(biāo)準(zhǔn)。同SSL/TLS一樣，它也提供主機(jī)審計(jì)認(rèn)證，數(shù)據(jù)完整性和數(shù)據(jù)機(jī)密性的功能，使用IPSec的好處是它對(duì)終端用戶和應(yīng)用是透明的，并能提供一種一般性的解決方案；另一種更一般的解決方案僅在TCP上實(shí)現(xiàn)安全，這種解決方案主要是安全套接字層（SSL）和傳輸層安全(TLS)協(xié)議，它們被用來提供傳輸層的Web服務(wù)安全，SSL/TLS在點(diǎn)對(duì)點(diǎn)（point-to-point）的會(huì)話中,可以完成包括審計(jì)，數(shù)據(jù)完整性，機(jī)密性這樣的要求。

SSL可以嵌入到特殊的軟件包中，例如Netscape和Microsoft Explorer瀏覽器都配置了SSL，大部分服務(wù)器也都實(shí)現(xiàn)了該協(xié)議。

1.1 SSL體系結(jié)構(gòu)

SSL使用TCP提供一種可靠的端對(duì)端的安全服務(wù)。SSL不是單個(gè)協(xié)議，它由兩層協(xié)議組成。SSL中定義的三個(gè)較高層次協(xié)議分別是：握手協(xié)議、密碼變更規(guī)格協(xié)議和報(bào)警協(xié)議。SSL協(xié)議中兩個(gè)重要的問題是SSL會(huì)話和SSL連接，會(huì)話是客戶與服務(wù)器之間的一種關(guān)聯(lián)，連接是一種能夠提供合適服務(wù)類型的傳輸。

1.2 SSL記錄協(xié)議的運(yùn)行流程

SSL記錄協(xié)議對(duì)各種更高層協(xié)議提供基本的安全服務(wù)。尤其是，超文本傳輸協(xié)議是為Web客戶端/服務(wù)器的交互提供傳輸服務(wù)的協(xié)議，它可以在SSL的頂層運(yùn)行。記錄協(xié)議要傳輸應(yīng)用消息是，先將數(shù)據(jù)分段成一些可操作的塊，然后選擇壓縮或不壓縮數(shù)據(jù)，再生成MAC、加密、添加頭并將最后的結(jié)果作為一個(gè)TCP分組送出。對(duì)收到的數(shù)據(jù)，首先解密，然后做完完整性驗(yàn)證、解壓縮、重組，最后把數(shù)據(jù)遞送到更高層用戶。

1.3 握手協(xié)議

SSL最重要的部分是握手協(xié)議。這一協(xié)議允許客戶端和服務(wù)器相互認(rèn)證，并協(xié)商加密和MAC算法以及用于保護(hù)SSL記錄中所發(fā)送數(shù)據(jù)加密密鑰。握手協(xié)議在任何應(yīng)用數(shù)據(jù)被傳輸之前使用，由客戶端和服務(wù)器之間的一系列消息交換組成。

1.4 密碼計(jì)算

我們主要關(guān)注兩個(gè)問題：

1) 通過密鑰交換創(chuàng)建一個(gè)共享主密鑰。共享主密鑰是通過安全密鑰交換方式為本次會(huì)話創(chuàng)建的一個(gè)一次性48字節(jié)的值。創(chuàng)建過程分兩步完成。第一步：交換預(yù)備主密鑰。第二步：雙方計(jì)算主密鑰。客戶端和服務(wù)器都按照下面方法計(jì)算主密鑰：

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消息中交換的兩個(gè)現(xiàn)時(shí)值。

2) 密碼參數(shù)產(chǎn)生。其方法是主密鑰利用散列函數(shù)來產(chǎn)生安全字節(jié)序列，字節(jié)序列足夠長以便生成所有需要的參數(shù)。

然而，僅有傳輸層和網(wǎng)絡(luò)層的這些安全機(jī)制是遠(yuǎn)遠(yuǎn)不夠的，Web服務(wù)的安全性是提供一種綜合的，全方位的安全保障。

2 構(gòu)建一種可靠的Web服務(wù)的安全模型

2.1 Web服務(wù)的協(xié)議棧

Web服務(wù)體系架構(gòu)中不同操作與交互的實(shí)現(xiàn)，則需要有一系列分層的協(xié)議規(guī)范，具體協(xié)議棧如表1所示。

Web服務(wù)能夠被服務(wù)請(qǐng)求者調(diào)用，則必須是能通過網(wǎng)絡(luò)進(jìn)行訪問的，由于HTTP的普遍性，使它成為了Internet中Web服務(wù)的標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議。Web服務(wù)還能夠支持其它Internet協(xié)議，包括FTP與SMTP等。

2.2 Web服務(wù)的基本工作過程

要建立面向服務(wù)的集成系統(tǒng)可以利用Web服務(wù)。我們不用改變現(xiàn)有的各種應(yīng)用，當(dāng)然也不需要關(guān)心它們技術(shù)的不同(比如是java，還是.net),可以利用Web服務(wù)的消息驅(qū)動(dòng)機(jī)制，使它們協(xié)同工作和交互。XML 消息傳遞是Web服務(wù)體系結(jié)構(gòu)最重要的基礎(chǔ)，XML 消息傳遞的行業(yè)標(biāo)準(zhǔn)協(xié)議是SOAP，服務(wù)的調(diào)用者通過在傳輸層協(xié)議之上綁定SOAP消息來請(qǐng)求服務(wù)。Web服務(wù)的基本工作過程是通過發(fā)送SOAP消息到一個(gè)由URI來鑒別的服務(wù)點(diǎn)（由一個(gè)SOAP server來接受消息），來請(qǐng)求特定的Web服務(wù)(操作)，接收到消息的響應(yīng)結(jié)果或者錯(cuò)誤提示。在傳輸層之外，當(dāng)消息數(shù)據(jù)被接受和中轉(zhuǎn)的時(shí)候，數(shù)據(jù)的完整性以及其他的安全信息就可能泄漏或者丟失。這要求Web服務(wù)的請(qǐng)求者/提供者必須信任那些中間節(jié)點(diǎn)對(duì)消息的獲得和處理（那些中間節(jié)點(diǎn)可能需要處理消息，生成新的消息）。

2.3 Web服務(wù)的安全模型

我們把Web服務(wù)的安全模型建立在三個(gè)層次上：傳輸層的點(diǎn)對(duì)點(diǎn)安全、應(yīng)用服務(wù)級(jí)的安全和策略和端對(duì)端的安全性。在這三個(gè)層次的基礎(chǔ)上我們構(gòu)建的Web服務(wù)的安全模型的工作流程是：

1） 服務(wù)方可以要求請(qǐng)求者的消息證明一組聲明（例如，名稱、許可、密鑰、性能等等）。這一組聲明和相關(guān)的信息就是端點(diǎn)策略。

2）請(qǐng)求方可以通過把安全令牌與消息關(guān)聯(lián)起來發(fā)送，使得消息既證明了發(fā)送者具有要求該操作又可以要求特定的操作的聲明。

3）如果請(qǐng)求者無法給出必需的聲明，那么請(qǐng)求者或它們的代表可以通過與其它Web服務(wù)聯(lián)系設(shè)法獲得必需的聲明。這里其它的Web 服務(wù)，指的是安全性令牌服務(wù)（security token service），我們接下來可以要求它們自己的一組聲明。安全性令牌服務(wù)通過簽發(fā)安全性令牌不同信任域之間的信任。

傳統(tǒng)的web服務(wù)安全性中的傳輸層的安全協(xié)議（如SSL/TLS），只能對(duì)全部的信息進(jìn)行加密，而不能選擇性地對(duì)部分信息進(jìn)行加密，導(dǎo)致在傳送大量數(shù)據(jù)的時(shí)將引發(fā)嚴(yán)重的性能問題。我們提出的web服務(wù)安全模型中的Web服務(wù)支持對(duì)SOAP消息的指定部分進(jìn)行加密或簽名可以減少因安全處理而導(dǎo)致的性能損失，這是提高性能的另一個(gè)關(guān)鍵。我們可以把安全模型應(yīng)用于基于Web服務(wù)的信息系統(tǒng)中，以期在保證安全的同時(shí)提高系統(tǒng)性能。

參考文獻(xiàn)：

[1] Stallings W.網(wǎng)絡(luò)安全基礎(chǔ)應(yīng)用與標(biāo)準(zhǔn)[M].白國強(qiáng),譯.3版.北京:清華大學(xué)出版社,2007:175-189.