分類  >  Web前端 >

企業級SOA之路——在Web Service中應用HTTP和JMS

tags:    時間:2013-12-10 01:06:47
企業級SOA之路——在Web Service中使用HTTP和JMS
概述
    IT業界在早期有一種誤解,認為Web Service等同於面向服務架構(SOA)。實際上,SOA遠不止這些。雖然SOAP是一種愈加通用的消息格式,但SOA通常還會需要其他的底層transport。當構建SOA的時候,如何選擇這些底層transport是最重要的決定之一。為了支持關鍵業務應用系統的需要,使用的transport必須要靈活、可靠而且可擴展;必須能夠支持不同類型的同步或者非同步的服務通訊。HTTP和Java消息服務(JMS)是兩種最常用的標準SOAP消息transport。
    本文分析了HTTP和JMS各自的優點和協議,重點講述每一種transport在SOA中的什麼地方是最適用的並且演示如何使用它們。
 
企業SOA通訊需求
    靈活性,可靠性,可擴展性。要想最大限度的利用所有的連接服務,這是企業SOA中使用的transport都要具有的三個屬性。
    在SOA架構中,transport需要能實時(同步)地進行消息傳輸,以對用戶或者系統進行響應。通常企業也要求擁有靈活性,以實現非同步通訊服務。一個原因可能是服務並不總是處於可用狀態。另一個原因可能是不可靠的或者非持續的網路連接,比如無線網路。
    在這些情況下,同步傳輸會產生失敗結果,除非服務本身可以進行「重新請求」操作和錯誤處理。此外,SOA中流程間的通訊並不總是點對點或者一對一的。通常,服務需要同時對多個流程或者系統發送消息,是一對多的關係。當服務也可以被多個「消費者」請求時,就增加了服務本身的複雜度並且使服務和終點緊密關聯。
    在很多情況下,服務要求有可靠的transport。如果transport沒有提供可靠的消息發布,在應用系統中就必須要增加額外的驗證。
    最後,transport必須是可擴展的。Transport本身不能對發布消息數量,消息發送方和消息接受方數量的增長進行限制。
 
HTTP的優缺點
    HTTP是SOAP消息中最常用的transport。畢竟,它是原始Web服務標準中的第一個官方的SOAP transport。因此HTTP作為標準的與Web服務連接和通訊的方法,被應用系統和系統提供商廣泛地採用。
    然而,HTTP本身所具有的點對點、同步的特性成為了它作為服務transport的局限。了解HTTP的功能和局限可以幫助我們找到最合適的地方使用它,並且根據情況考慮使用其他的協議替代它。
HTTP只支持點對點和同步方式
    HTTP支持的通訊方式有兩方面的局限。首先,因為HTTP是點對點協議,它不提供對多個接收方的併發請求能力。在企業SOA中,一個服務提供者可能需要在流程中的某一步完成後通知其他服務提供者。當使用HTTP時,服務必須明確的識別每一個接收者並向其發送消息。
    這種限制可以得到某種程度的緩解。解決方案包括開發一個應用系統來進行這些消息的連續傳輸或者根據OASIS制定的Web服務通知規範進行編碼,SOAP擴展程序對通知進行定址。Web服務通知規範目前正處於標準設置進程的公共評審階段。
    另一個局限是HTTP只支持同步通訊。很明顯,在SOA中既需要同步通訊也需要非同步通訊。流程經常會等待人工干預或者其他的流程結束。在這種情況下,HTTP的同步特性就不滿足SOAP對transport的要求了。HTTP等待請求的響應,要佔用寶貴的通訊資源直到它接收到響應信息。在非同步的情況下,在接收到響應消息前可能會有很長時間的等待。
    一個並不算完善的使用HTTP的SOAP提供非同步消息的解決方案是採用Web服務定址標準。通過使用Web服務定址,SOAP消息的整個路徑(包括它的返迴路徑)可以在SOAP消息封裝中直接描述。Web服務定址支持單向消息,雙向消息(比如請求/響應和點對點通訊)和長連接對話。但是,這個標準增加了複雜度,需要另外編寫程序和購買產品。
    除去這些解決方案,情況依然如此:為了使消息能夠被成功的發送,HTTP需要發送方和接收方同時被連接。如果網路或者接收程序沒有連接,HTTP就不能發送消息。
    簡單的說,HTTP本身並不具備企業SOA所要求的通訊(通知和非同步操作)的靈活性。不論是在應用程序級還是在SOAP級,開發人員都必須要額外編程來實現通知和非同步操作。
HTTP提供有限的可靠性
    因為HTTP只能提供很有限的錯誤碼,只能根據這些錯誤碼區分很小一部分可能的錯誤情況,所以這個協議本身是不能保證發送方的消息確實被發送了。然而確保信息被發送是任何企業SOA的一項基本功能。為了保證全部流程的每一步都能持續地進行,發送者的發送的信息必須保證能被指定的接收者接收到。
    一個提升企業架構可靠性的方法就是提升網路和應用系統的可靠性,防止網路和應用系統過載。另一個方法是為應用系統額外創建錯誤處理和修復功能。第三種方法是在SOAP層編寫程序,使他符合Web服務可靠消息標準(可靠的Web服務消息)。但是,每一種方法都會增加成本和複雜度,而且他們也無法完全的避免失敗。
HTTP缺乏有效的可擴展性
    通過HTTP進行通訊的基礎架構無法有效的進行擴展。HTTP伺服器的架構限制了在任何時候同時連接的埠的個數。理論上埠的數量可以達到65536個,但是為了避免伺服器過載,可用的埠的最大數量要小很多。這些連接佔用了寶貴的機器資源,限制了可擴展性。一旦達到了限制的數量,就需要增加額外的硬體(比如其他的Web伺服器)以增加容量,並且要設置負載均衡。這些額外的手段增加了系統架構的成本和複雜度。
    儘管Web伺服器可能有很多埠連接在使用,但可能同時只有一小部分在發送消息。在這種情況下,伺服器即使還沒有滿負荷運行,也不能接受更多的連接。伺服器的資源並沒有被高效的利用。
基於HTTPSOAP複雜度高
    綜上所述,簡單的HTTP通訊方式可以被擴展成靈活的、可靠的和可擴展的通訊方式,來充當基於的Web服務的SOA的通訊基礎。進行這些改進是通過擴大SOAP層進行的。這些改進,處於不同的批准和採用階段,充分證明了SOAP的擴展性。然而,他們同樣帶來了額外的複雜性,並且需要額外的開發資源和/或額外的軟體來執行,因此增加了成本。
 
JMS降低複雜度
    JMS是由Java通訊程序制定的規範。它提供了標準的編程介面用來發送和接收消息,支持同步消息、非同步(發布/訂閱)消息和請求/響應(點對點)消息。JMS提供商的每個JMS產品,都對如何進行消息發布進行了規範,這些規範涵蓋了消息轉換、安全、錯誤處理和伺服器與客戶端之間的底層通訊協議。這樣,為服務傳送消息就變得簡單易行,不需要在應用系統中額外的編程去實現錯誤處理和恢復。要獲得更多的JMS方面的資料,可以訪問java.sun.com/products/jms/index.jsp。
    正因為有這些功能,JMS作為消息transport在應用集成和SOA中被廣泛的採用。包括使用JMS作為基於SOAP的服務的transport 。
JMS支持更多的通訊方式
   JMS相比HTTP能進行更靈活的消息發布。JMS支持「發射后不管」通訊,消息在發送后不必等待應答,並且可以存放在持久存儲或者Queue中。基於Queue的方式可以進行非同步通訊,消息發送時,消息的最終消費者不需要連接到伺服器上。當消息的消費者連接到JMS伺服器上時,消息就可以被發送到消息的消費者。HTTP就明顯不能支持這種非同步的通訊方式。當使用HTTP時,開發人員必須編程使應用系統支持非同步方式,並且要有效的重新創建消息傳送。
    除了在消息生產者和消費者之間進行點對點的消息通訊,基於JMS Topic的架構可以支持發布/訂閱方式,使用這種方式一個消息生產者可以與多個消息消費者同時進行通訊。生產者向給定的Topic上發送任何消息都可以被訂閱了這個Topic的每一個消費者接收到。HTTP不能提供這樣的功能,除非增加SOAP消息的複雜度或者編程使應用系統實現一對多的消息發送。OASIS的Web服務通知(WSN)技術委員會定義了一套規範,用來對Web服務使用「通知」和「事件」的交互進行標準化。它們構成了使用Web服務架構事件驅動的基礎。
Modes of Transport for HTTP and JMS
  Point-to-Point Publish/Subscribe
Synchronous HTTP, JMS JMS
Asynchronous JMS JMS
 
    當使用JMS作為消息transport,上面表格中的四種消息發送方式組合中的任何一種都可以使用。這種既能使用同步操作又能使用非同步操作,既能進行點對點方式,又能進行發布/訂閱方式的功能使得JMS在作為消息傳送機制時比HTTP有明顯的優勢,因為HTTP本身只能支持同步和點對點傳送。更多的消息傳送方式使得流程設計人員在為服務之間的通訊選擇最合適的方式時,提供了更靈活的選擇。
    JMS消息還可以設置優先順序,使得對時間敏感的信息流有更多的控制,還可以作為定義服務通訊相關質量的方式。管理員通常使用這種功能調整服務級別,完善整體服務性能。這樣在網路擁堵、系統臨時宕機或者災難恢復時,能確保那些擁有相關優先順序的關鍵系統能夠正常運行並進行通訊。
JMS更可靠
    當應用程序或者網路出現間歇性的失效甚至停止運行,JMS能確保消息從發送者(生產者)傳送到接收者(消費者),HTTP就不能。JMS通過將消息存放在中間伺服器上來實現這種可靠的傳輸。比如,在保證消息傳送的情況下,消息會被重發或者重複解析來保證消息確實被傳送了。與HTTP不同,JMS內置有錯誤恢復和消息重傳機制,不需要在應用系統或者SOAP層進行編程。
JMS擴展性更強
    JMS能更有效的使用系統資源,不論是在一台單獨的機器上縱向線性增長的資源還是橫向增長跨系統的資源都比HTTP更高效。
    Scaling up:JMS可以在消息發送者和接收者之間配置單連接,甚至是在發送大量的併發消息的時候。HTTP需要為每一個請求和響應服務建立socket連接,消耗了大量的系統資源,JMS就沒有這種問題。大量減少socket連接可以很好的節省系統資源,能支持更多的通訊量,因此提高了伺服器的擴展性。
    Scaling out:HTTP和JMS的一個最大的區別是JMS將目的地址與物理主機或者應用系統名稱分離。這種獨立的命名空間使得JMS實現可以更加的動態。比如,對於一些JMS提供商,發送程序、路由伺服器和接受程序可以被添加到相同的topic或者queue上,能夠動態的增加負載。這種負載均衡是通過軟體來實現的,而不是額外的硬體設備。
基於JMSSOAP比基於HTTPSOAP更簡單
    相比HTTP,很明顯JMS的消息傳送更靈活、更可靠和更可擴展。所有這些特性都是JMS本身所具有的。不需要像HTTP一樣,在應用系統或者SOAP層作開發。使用JMS代替HTTP可以減少編寫代碼的時間和降低通訊的複雜度,使得開發的周期更短。
 
何時用HTTP,何時用JMS
    雖然JMS提供了更強大的transport功能,HTTP已經在企業中被廣泛的使用。這些事實決定了在企業SOA中,這兩種協議會同時存在。不只是你的企業,你的客戶和合作夥伴也一樣會同時使用這兩種協議。所以,你在選擇SOAP消息的transport的時候就要考慮在什麼時候是用HTTP,什麼時候是用JMS。
    你可以嘗試是用一些簡單的規則,比如在企業內部使用JMS作為transport,在與合作夥伴和客戶通訊的時候是用HTTP。但是,這種方法也過於簡單。可以通過考慮使用哪一種transport更有意義或者使整合變得更簡單來選擇,來代替使用位置(比如企業的內部或者外部)進行選擇。
以下情況適合使用SOAP/HTTP
l         流程和/或者服務已經使用了基於HTTP的SOAP
l         客戶或者合作夥伴正在使用基於HTTP的SOAP,或者想要使用
l         通訊端點的一方是瘦客戶端,比如Portal或者Web瀏覽器
以下情況適合使用SOAP/JMS
l         需要與移動設備或者非持久連接的服務進行非同步或者發布/訂閱通訊
l         可靠性和擴展性要求高的服務,比如關鍵任務服務,數據發布或者同步
l         必須與那些沒有Web服務介面並且要求整合的應用系統連接的時候
l         客戶或者合作夥伴使用基於JMS的SOAP
    大多數企業都可能會用到多協議,為不同的情況選擇最合適的transport協議,這是最基本的要求。
 
實現企業級SOA
    為了使企業SOA的作用達到極致,不論在底層使用的是什麼樣的通訊協議,所有的企業中的服務都要被重用。在企業級的SOA中,服務之間使用多種不同的協議進行通訊。比如HTTP,還有其他很多種協議。JMS由於提供了更好的靈活性、可靠性和擴展性,經常被要求嚴格的、關鍵任務的服務所使用。這就意味著SOA需要在使用不同的transport和協議的服務間進行通訊,不管他們是不是Web服務。
    要對不同的協議進行無縫的連接,提供各個服務間的連接能力(使企業中的服務實現重用),需要企業服務匯流排(ESB)來完成這個工作。TIBCO BusinessWorks產品提供所有的ESB功能,包括高級ESB服務和服務集成環境,使開發人員可以不去關心底層系統的複雜性並提高生產效率。
    SOA的最主要的目標之一,就是使那些使用HTTP,JMS和其他協議的系統能夠一起工作,實現企業範圍內的服務重用,但是實現這個目標是很困難的。幸運的是,客戶可以通過ESB在SOA中選擇和使用多種協議。通過ESB本身支持的基於HTTP、JMS或者其他協議的SOAP和XML,跨協議路由,數據轉換或者其他功能,可以最大限度的實現跨協議的服務重用。與HTTP和JMS一樣,ESB是一項成熟的技術。自從2001年開始,超過1000家用戶使用了TIBCO BusinessWorks ESB產品,使那些基於HTTP、JMS和其他協議的軟體系統能夠作為企業級SOA的一部分進行協同工作。簡而言之,你想要靈活的選擇協議或者技術,就要走上通往企業級SOA的道路。

推薦閱讀文章

Bookmark the permalink ,來源:互聯網