仇士春 鄧敏麗
Web Service是一個平臺獨立的、低耦合的、自包含的、基于可編程的web應用程序,可使用開放的XML(標準通用標記語言下的一個子集)標準來描述、發布、發現、協調和配置應用程序,常用于開發分布式的互操作的應用系統。
Web Service能使得運行在不同機器上的不同應用,無須借助附加的、專門的第三方軟件或硬件,就可相互交換數據或集成。依據 Web Service規范實施的應用程序之間,無論使用哪種語言、平臺或內部協議,都可以相互交換數據。Web Service是自描述、自包含的可用網絡模塊,可以執行具體的業務功能;也很容易部署,因為它們基于一些常規的產業標準及已有的一些技術,如標準通用標記語言下的子集XML、HTTP;Web Service減少了應用接口的花費,為整個企業甚至多個組織之間業務流程的集成提供了一個通用機制。
Web Service 作 為 RPC (Remote Procedure Call Protocol)技術的一種演進,主要由SOAP、UDDI和WSDL組成。SOAP是基于XML的簡易協議,可使應用程序在HTTP之上進行信息交換。UDDI是一種目錄服務,企業可通過它注冊并搜索Web Services。WSDL是一門基于XML的語言,用于描述 Web Services及如何對其進行訪問。Web Service通過這一系列的協議從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議,使開發者可以更加專注于開發的程序本身,更加輕松和有效地使用遠程的資源或進行數據交互。
Web Service作為一種平臺獨立的技術,具備跨平臺、跨開發語言的特性。可以在 Windows、Linux、Unix甚至是手機App中都能使用,而且包括Java、.Net、PHP、Delphi等開發語言都支持使用該技術開發各項應用。
近年來,隨著鐵路信息化的發展,越來越多的應用系統也開始使用這項技術進行開發,極大的提高了不同系統之間的整合效率。
盡管Web Service有諸多優點,但由于其運行方式及鐵路信息系統的特點,在使用中還是會遇到一些問題,下面對這些問題的表現及解決進行總結。
嚴格來說Web Service是行業標準,各個組織和廠商以其為依據開發自己的服務和框架,其中最具代表性的就是Java的JAX-WS、微軟的.net web server和 WCF、Apache的Xfire和axis2。
實際工作中遇到兼容性問題主要是在JAX-WS和WCF之間,由于微軟的技術實力雄厚,不僅實現了Web Service的標準,而且基于自家的.net做了大量的擴展和優化,使其作為服務與JAX-WS進行交互時會出現兼容性問題。解決這個問題的辦法比較簡單,就是在WCF的服務開發時將其服務綁定規則設置為basicHttpBinding,這樣WCF就能夠以Web Service的標準方式對外提供服務,與JAX-WS開發的程序進行正常交互。
通過Web Service進行不同系統和服務之間的相互調用的模式具備非常明顯的SOA特征。
1.獨立功能的實體。目前開發設計新系統無一例外都是采用分系統、分模塊進行的,這樣各系統、模塊具備自我管理和恢復的能力。常見的技術有事物處理、消息隊列、冗余部署、集群系統等,這些技術和模塊之間差異巨大,但是通過Web Service進行相互調用時只需知道對方的服務接口,而不用關心對方使用的什么硬件平臺、運行什么操作系統、使用什么語言、網絡層接口處理等底層細節。
2.大數據量低頻率訪問。通過使用 WSDL和基于文本 (Literal)的SOAP請求,可以實現一次性接收大量數據接口。SOAP請求分為文本 (Literal)方式和遠程調用 (RPC)方式,使用文本方式就可以一次性發送/接收大量數據,測試和使用過程中可實現一次性傳送20MB的文本數據,進行少許改造后甚至可以用來傳送照片、統計圖表之類的小型文件。只是對平臺有些要求,如Java環境版本不能低于1.6.0_20,服務器軟件如WebLogic、WebSphere也不能使用過老的版本。
3.基于文本的消息傳遞。Web Service所有的通信都是通過SOAP進行的,而SOAP是基于XML的,不同版本之間可以使用不同的DTD或XML Scheme加以辨別和區分。而傳統的COM、CORBA這類組件模型中從服務器端傳往客戶端的是一個二進制編碼的對象,在客戶端通過調用這個對象的方法來完成某些功能。但是在現實環境下,不同語言、不同平臺對數據、甚至是一些基本數據類型定義不同,給不同服務傳遞對象帶來很大困難。由于基于文本的消息本身是不包含任何處理邏輯和數據類型的,因此服務間只傳遞文本,對數據處理依賴于接收端的方式可以繞過兼容性問題。
Web Service的使用促進了SOA架構的成熟與完善,降低了不同系統軟硬件之間的兼容性障礙,使得開發更大更豐富的信息系統成為可能,不但可以更快的開發新系統,而且可以無縫的與既有系統進行集成和整合。
鐵路網絡系統的安全域是通過安全平臺將網絡分為內網和外網,數據和關鍵服務處于內網,用戶和應用服務處于外網。用戶訪問應用服務器時,應用服務器通過安全平臺訪問內網服務進行處理,然后將處理結果再通過響應方式反饋給用戶。用戶訪問見圖1所示。
由于穿越安全平臺過程比較復雜,所以在使用Web Service穿越安全平臺進行內外網應用交互時,公用的實現框架均不能滿足這種需求,需要進行相關的安全認證和設置安全信息的工作才能將訪問請求通過安全平臺發送到內網服務端。為了完成這部分工作,開發了一個Java接口開發包,這個開發包通過使用定制化的SSLSocketFactory獲取到認證中心的SSL連接認證適配器,基于這個定制化的SSLSocketFactory結合HttpsURLConnection即可完成到認證中心的通信,獲取認證令牌,然后通過定制化的HandlerResolver接口和定制化的SOAPHandler接口,即可將獲取到的認證令牌按照指定的格式填充到Web Service請求的HTTP頭中去,然后將定制化的HandlerResolver設置到Web Service的服務接口中后,就可以像調用普通的Web Service,而這一系列的初始化操作都可以通過使用Spring Framework配置實現自動化,而在程序中只需要進行類似如下操作即可調用:
class Test {
@Autowired
private IHello iHello;//測試 Web Service服務接口
public void sayHello () {this.iHello.say-Hello ();}
}
因此雖然在不同的安全域間可能會存在以上這種比較復雜的認證隔離設備,給內外網之間的應用通信帶來不小的影響,但是只要選擇的方式、方法得當,仍然可以將這種影響降到最低,既能保證內外網間的通信安全,又能順利的通過 Web Service進行服務調用。
在進行應用訪問的過程中,由于網絡問題、服務響應問題等不可避免的會出現響應超時的情況,如果不處理超時問題,不僅會影響用戶的訪問體驗,甚至會影響程序的穩定性,導致程序僵死。
對于比較常用的JAX-WS框架,如果需要在訪問Web Service的時候啟用超時處理,則需要一些特別的方法,主要方法如下:
#假設Service服務下有個IHello服務接口
IHello ihello=Service.getIHello ();
Map<String,Object>requestContext=((BindingProvider)ihello).getRequestContext();
#設置連接超時,單位ms
requestContext.put(BindingProviderProperties.CONNECT_TIMEOUT,10000);
#設置訪問請求超時,單位ms
requestContext.put(BindingProviderProperties.REQUEST_TIMEOUT,10000);
#然后在調用IHello接口中的方法就會受到超時設置的影響
ihello.sayHello ("Hello World!" );
這個方法可解決Web Service調用時的超時問題,通過這個方法設置連接超時和請求超時,當相應超時事件發生時就會拋出異常TimeoutException,應用可以捕獲該異常進行處理或是反饋給前端用戶,由用戶決定是否繼續,更加友好的解決應用中的超時問題。
Web Service作為一種重要的跨平臺、跨語言的開發標準,其優點眾多,而且促進了SOA的成熟與發展,勢必會成為一種廣泛使用的開發模式,甚至是應用架構的重要演進方向。然而就像以前曾經流行過的其他技術一樣,它并不完美,在實際使用中,也會遇到諸如跨安全域訪問、超時等問題,不僅會影響用戶的使用感受,嚴重時會影響應用的穩定性,危及應用的安全穩定運行。因此必須要不斷的研究、學習和測試它,才能在鐵路信息系統中更好的使用它,發揮其優點,規避其缺點,使其更好地為鐵路應用系統服務。
[1] Martin Kalin.Java Web Services:Up and Running.O'Reilly Media,Inc,USA,2009.
[2] 陳雄華.Spring 3.x企業應用開發實戰[M].北京:電子工業出版社,2012.
[3] Elliotte Rusty Harold.Java Network Programming .O'Reilly Media,Inc,USA,2004.
[4] 許令波 .深入分析Java Web技術內幕,第2版[M].北京:電子工業出版社,2014.