大規模的財政應用和面向服務的體系結構(weblogic)

　　 
財政機構在J2EE和基于組件的結構上已經有了很重的投資。WebLogic服務器是用來對客戶和貿易伙伴展開革新財政服務的關鍵的電子商務平臺。出現面向服務的結構范例是對J2EE（Java 2 platform Enterprise Edition）的很自然的擴展，并且WebLogic把它無縫集成起來。

組件和商業過程的重用

組件的重用是構造大規模的商務對商務（B2B）的財政服務的關鍵；本篇文章說明了用WebLogic平臺實現這些服務的好處。電子商務提出的最基本的方法是核心的業務邏輯是定位以及被管理于應用服務器上。此外，現在業務邏輯可以從各種各樣的介紹渠道獲得。WebLogic是用于加強處理集中商務過程重用的一個強有力的平臺。如果你給Excel電子數據表單提供商務過程，簡單的做法是你不得不壓縮它，將其當作SOAP（Simple Object Aclearcase/" target="_blank" >ccess Protocol 簡單對象存儲協議）服務， 然而WebLogic可以極大地簡化這項任務。

應用拓撲學和商務模式

退回一步，我們注意到在金融領域中出現的一些電子商務模式是很有趣的。在其最簡單的形式中，商務模式描述用戶，商務和數據之間的相互作用。在這種理解下, 用模式驅動的方法構建圍繞著WebLogic的電子商務結構是非常有趣的。J2EE的體系結構可以簡單的被映射成不同的商務模式，類似用戶－商務，或叫"自助"模式；用戶－數據，或叫"信息集合"模式；和B2B，或叫"擴展企業"模式。

一旦你確認了你的財政服務所應用的電子商務的模式，下一個步就是把它繪制成應用拓撲結構，按順序編成runtime拓撲結構。本篇文章將主要集中于財政服務的用戶－商務模式，但是也將談到類似Web服務的企業應用的擴展。

對于用戶－商務模式，已經確認了兩個應用拓撲結構。在第一種拓撲結構中，你的應用是不需要和遺留系統以及第三方應用交互的。這種類型發生在當你構建不需要WebLogic服務器連接遺留系統的純J2EE應用體系時。在第二種拓撲結構中，你的應用系統是需要和遺留系統以及第三方應用進行交互。這在需要獲得實時數據提供的財政服務，ticker plants ，和第三方業務管理系統中最普遍。
runtime拓撲學

一旦應用拓撲結構被確認，它肯定被編成runtime拓撲結構，并作為電子商務解決方案被最終部署。以下是為用戶－商務模式提供的本質的財政服務的概況的一覽表：

1． 有權使用實時財政消息和數據的供給
2． 在事件上的通知和改變，例如貿易或引用值
3． 財政手段的實時貿易
4． 業務量計算和報告

令人驚訝地，顧客已經開始期待這些服務在移動設備上有功能上相同的水平使他們可以使用Web瀏覽器。財政服務必須自始至終被設計成多渠道的。圖1解釋了當應用WebLogic構造大規模，多層次的財政應用時，我發現runtime拓撲結構非常有效。

節點

runtime拓撲結構由幾個節點組成，他們被看成是特定的功能，如防火墻，Web服務器和目錄服務像LDAP（Lightweight Directory Access Protocol）等。每個節點在圍繞著WebLogic而構造的企業貿易系統中都很重要。

這些節點代表著外界連接不同的財政商務過程的角色。一個角色可以是私人的或者制度上的客戶，另一個應用通過Web服務/SOAP溝通，經紀人公司用FIX協議在預定，承認貿易訂單，甚至是可移動的委托人。一個或幾個角色初始化大部分系統用例。
第一個防火墻節點根據一套規則從因特網和過濾通信量限制訪問。例如，大部分的銀行業務應用HTTPs（Hypertext Transfer Protocol超文本傳輸協議）密碼化，使防火墻僅能確認某幾個IP地址和端口號443。第二的防火墻節點限制從非軍事區（DMZ）到內部網絡的訪問。介紹通道和其他節點，如FIX引擎的移動網關等定位于DMZ。

Web服務器節點（WebLogic在這個拓撲結構中）作為財政上的Web應用。在大部分的情況，這種應用在文件管理，電子報告和對財政的數據和消息的訪問中?？蛻羰褂肳eb方法；然而，大部分的業務邏輯處理通過RMI/IIOP（Remote Method Invocation/ Internet Inter-ORB Protocol 在Internet對象請求代理協議上的遠程方法調用）使EJB組件定位于第二道防火墻后面。

FIX引擎節點是一個非常專門的用來生產和消費把消息編碼成FIX的消息引擎，是一個跨產業的開放式協議，特別的發展了實時性和股票處理的無縫的電子的交換。FIX能給你提供直通的處理，它減少了處理成本，實質上是消除了在貿易商和代理人之間的電話和傳真的溝通。通常，一個FIX引擎必須滿足和其他runtime節點相同的高效性準則；因此，大部分的引擎銷售公司是將集群和容錯功能集成在他們的產品中。

Web服務服務器節點提供基礎結構去編制SOAP調用在主機正面第二道防火墻后面的會話EJB。用這種RPC(Remote Procedure Call 遠程過程調用) 形式調用到達Web服務服務器的SOAP消息。服務器解析消息并用RMI/ IIOP調用會話EJB，這個EJB依次處理本地調用駐留在WebLogic上的會話beans和實體beans。舉這個例子說明作為EJB組件封裝起來的可重用的財政過程的好處，它可以由Web應用服務器和SOAP客戶端支撐。作為Web服務，RPC 形式的調用對于提供定價或證券的優化分析很理想，它提供很多新的機會去共享內外過程。

移動網關節點在企業財政過程和移動平臺如Symbian, Palm OS和Windows CE等之間提供連接。隨著更強大的設備和更豐富的用戶界面的出現，移動用戶期望可以由桌面應用服務器提供相同水平的功能。WML (Wireless Markup Language 無線標記語言) 幾乎不體現那種理解。 使用基于JMS (Java Message Services Java消息服務) 的可移動中間件是一個不錯的方法。這種解決方案依賴三個組件：WebLogic作為給財政商務邏輯，數據同步和安全性的一個JMS供應者；一個移動的JMS網關；和一個非常小的駐留在移動設備上的JMS客戶端程序。來自Softwired公司的iBus//mobile (www.softwired-inc.com) 為構建使用JMS的移動服務對WebLogic進行無縫集成。由于移動平臺有諸如間歇性連接和中斷通信連接等問題，提供隊列設備和可靠的消息傳送是JMS消息傳送所必須的，是理想的候選者。

大量的財政過程定位在第二道防火墻后面的節點上。在這種情況下，WebLogic應用服務器是一個主要的儲存庫，儲存那些由可重用的財政商務過程打包成的會話beans，實體beans，和消息驅動beans。最終目標，組件的重用是通過確認在所有大規模的財政應用中重復出現的基本服務并且將他們壓縮作為EJB的組件而實現的。組件的重用實現起來有困難；然而，在現今快步調的市場經濟下我們除了依賴于堅實的以及經過可靠測試的重要組建集群外，是別無選擇的。

目錄服務節點對于創建單一的注冊基礎結構不可缺少。單一的注冊不僅消除了多用戶的注冊和口令的管理爭論，而且在整體上大大的簡化了管理任務。一個LDAP的目錄不僅可以儲存像電子郵件地址這樣的一般信息，也可以存儲強大的認證信息，用戶證明。從應用發展觀點看，集中的數據存儲對于用戶管理是非常重要的，因為同樣的授權和認證業務邏輯在每一次的應用中不能復制。對于runtime拓撲結構有一些細微的不同，它需要在DMZ上加上一個只讀的"從屬"LDAP目錄。寫控制在第二道防火墻后面，復制習慣在同步控制和從屬節點。這種解決方案有更好的縮放的優點。

引用服務器，或者叫"標記設備"節點是一個實時的行情數據分配系統就像Reuters Triarch。標記設備用TIBCO的通信技術，從TIBCO集合消息實時的調度JMS的引用消息到客戶端應用節點。

客戶端應用節點是GUI(Graphical User Interfaces 圖形用戶接口) 用來管理證券或輸入交易訂單。除了實時引用的處理之外，在GUIs后面的大量的業務邏輯實際上是作為EJB組件來執行的，它駐留在WebLogic上并由Web層重用。

這種交易處理節點是一個后臺系統用來調整和清除交易的。財政商務過程從駐留在WebLogic 發送JMS交易消息道交易處理器，處理器確認交易之后把JMS消息返回給消息驅動bean。

最后，Reuters Investor 節點 (http://rfs.reuter.com/investor) 用XML(extensible Markup Language 擴展標記語言) 格式為駐留在WebLogic上的財政組件提供財政數據和消息。Reuters Investor服務和引用服務器的不同在于，Reuters Investor服務是用來構建財政上的入口由靈活的Reuters數據提供，而引用服務器的目標是為貿易提供實時的財政數據流。
在不同的節點使用分組，例如FIX引擎，移動網關和WebLogic服務器等，提高了可靠性和實用性。橫向的縮放通過分組獲得。通過給服務器機器增加CPU和內存等資源達到了縱向的縮放。在這種拓撲結構，WebLogic在DMZ中被用作Web服務器并作為應用服務器在內部的網絡中應用。

面向服務的體系結構

在DMZ中應用WebLogic是很有意義的，尤其是用由WebLogic7.0 提供了附加功能的和像WebLogic WorkShop 一樣的工具。因為WebLogic同時扮演著集群Web服務器和Web服務節點的角色所以runtime拓撲結構也被簡化了。然而，還有更好的理由使用WebLogic服務器來構建面向服務的體系結構。如果你用過WebLogic Workshop，也許你已經看到了構建和發布Web服務是多么的簡單。這不是個秘密；我們都知道企業計算的下一步是面向服務的體系結構。真正的問題是如何盡可能無痛苦的達到這個目標。很多人相信使用像WebLogic WorkShop 一樣的工具，面向服務的體系結構在設計企業軟件上會體現出基礎上的轉變，比起基礎上的轉變，它更是使企業軟件擴展和適應的問題。畢竟，你還必須開發J2EE組件，并且，你還必須應用J2EE模式，不同的就是你必須考慮服務的面向。

在大多數情況下，商務過程復雜并且需要若干異步步驟。甚至是最簡單的財政過程，像一個貿易訂單，可能從事跨越若干天的復雜的工作流并且需要很多角色的干預。如同在圖2中被描述的那樣，當你可視化軟件結構并把它作為中心過程規程開發的時候，真正基礎上的轉變就發生了。最有趣的是構建過程模型和在Web服務上發布他們的能力。

對WebLogic Workshop進行測試

為了將WebLogic Workshop作為中心過程軟件開發工具進行評估，我"重新開發"了我幫助建造的應用。
銀行A想出售基金給銀行B，銀行B希望依次通過提供適當的證券出售這些基金給他的客戶。過程包括了幾個復雜的步驟和商業規則。另外，銀行A 的IT基礎結構和銀行B的完全不同。

我們設計了通過發送和接收每天的批量文件交換信息相關的笨拙的模式。然后業務邏輯曾為了使貿易和訂單得到確認辦理了文件。這個過程需要了很多手工操作的干預，在最后我有了"我能做得更好"的感覺。

使用 Web 服務解決問題是非常好的,但是直到最近它仍然被當作實驗性的技術被考慮。 用WebLogic Workshop，這不太現時。給我留下深刻的印象是我可以很快的設計原型和把應用作為一組Web服務來重新設計并且逐漸地使整個工作流程可視化。我將結果展示給一個有一些軟件工程知識的商業專家看，由于WebLogic Workshop的可視化界面，他能夠提供反饋，并且我們能交互式的修改和調整商業模型。

角色的分離

runtime拓撲結構的目標不僅是提供一個安全的，可調整的，和可靠的環境, 而且可以促進在開發者之間的角色上的分離。 在圖1中runtime拓撲結構提供了駐留在WebLogic上的業務邏輯組件和表示邏輯組件的清晰的分離。有 EJB 和 WebLogic 程序設計豐富知識的開發人員構建可重用的商業組件。開發者工作在Web服務和表示通道然后將它們集成在表示層。

一個重要的問題是從中間層的方法調用和數據傳遞的性能考慮。 J2EE 設計模式是避免這些缺陷的最好的信息來源。 我推薦佛洛依德的書, EJB的設計模式, 作為模式的來源和用EJBs構建分布式系統的最好的實踐。

簡單用例

最后，讓我們看典型的用例的情況?？紤]一個用戶在訪問金融機構的站點。Single Sign-on過程自動認證該用戶。今后，他或她根據該組可以訪問資源。個性化信息如報告，財政數據和消息通過WebLogic的Portal和portlet提供。

證券portlet給用戶一個即時的關于他或她的目前的資產的總的情況以及最新的增益/損失情況。建議portlet顯示依照用戶情形的當前的建議。由于交易的portlet，用戶回顧這個建議并且在一定限制條件下輸入交易訂單。用戶終止連接，并且訂單被委派到業務層EJBs。

同時，一個交易通知JMS消息被送到由用戶監聽的證券管理器。當證券管理器連接到應用服務器，他或她確認交易訂單，并且另外的一個 JMS 消息從客戶端的GUI應用程序發送到交易處理器。在一些處理之后，交易處理器返回一個JMS確認消息給另一個由FIX引擎確認，并且發送它到另一個JMS消息。然后FIX引擎將交易訂單作為FIX消息打包并將它發送給代理。經過一些處理，代理返回一個確認信息，這個確認信息被編譯成JMS消息，并返回到業務層。一個通知被發送到他或她的移動電話。

結論

過去的一年中，財政機構在J2EE體系結構上已經有了很重的投資，以使其適應并對Internet、貿易伙伴和客戶開放其內部的IT基礎設施。WebLogic服務器已經成為大規模的財政應用的基本組件和基本服務，例如在線貿易或證券管理。面向服務的體系結構對于構建高度分離的服務為中心的和商業過程為中心的解決方案是合理的下一步驟。不過，現在對于J2EE的投資應該被用杠桿作用操縱，并且面向服務的體系結構應當被當作J2EE基于組件模型的發展而不應是變革。像WebLogic服務器和WebLogic Workshop等工具，不僅僅保留你的現在的投資也使向面向服務的體系結構轉變變得容易。

原文轉自：http://www.anti-gravitydesign.com