SOA實踐秘訣

上周，我們提到「開發(fā)即整合，整合即開發(fā)」的觀念。在服務導向架構（SOA）底下，我們的目標是將所有具備價值的IT 資源，不論是舊的或新的，通通都能夠透過Web Services的包裝，成為可以隨取即用的IT資產。

這樣一來，利用專為Web Services所設計的商業(yè)流程管理（BPM；Business Process Management）工具，便可將各種服務快速匯整，開發(fā)出組合式應用，達到「整合即開發(fā)」。此外，透過那些對于Web Services 充分支持的應用服務器，以及相關的開發(fā)環(huán)境下所開發(fā)出的新應用，先天上就會是Web Services-ready。

從此以后，所有在這種環(huán)境下所開發(fā)出來的應用單元，幾年后不至于再淪為新的legacy 系統，因為我們在開發(fā)的時候便已經把它們的未來準備妥當，也同樣符合「整合即開發(fā)」的概念。

本周，我們接著探討應用平臺，特別是其所提供的各項基礎設施服務，以及對于建置與部署SOA架構所產生的重大影響。開發(fā)Web Services的進入門坎固然低，但真正的挑戰(zhàn)在于如何確保這些Web Services能夠經年累月穩(wěn)健的執(zhí)行下去，并且能顧及安全上的要求。

畢竟，當Web Services愈來愈普遍的扮演IT中的建材角色，卻無法同時經得起24x7 關鍵性任務的挑戰(zhàn)時，后果自然不是當初導入 SOA 所想要的。這樣的需求，自然會讓我們聯想至應用服務器，以及于其上所衍生的各項專門的應用領域。實際上，安全性、穩(wěn)定性、可用性、延展性，和效能方面的要求，一直是應用服務器這類型新一代的中介軟件（middleware）在設計時，便必須考慮在內的關鍵指標。

幾年導入下來的經驗，加上許許多多的成功案例，提供了非常可靠的驗證。另有數家應用服務器廠商，早在兩年前便開始積極提供各項Web Services相關科技的支持。因此，選擇能擔當大任的應用服務器作為Web Services宿主，在邏輯上，將會是很自然的延續(xù)與延伸。
先前提到，由應用服務器衍生出來的數據、應用整合平臺，可透過數種策略，將既有系統重新包裝為Web Services；而業(yè)務流程設計／管控 (BPM)、訊息格式轉換，訊息和服務路由等基本功能，則進一步的提供SOA上不可或缺的基礎服務。

整體而言，這樣的信息整合平臺在 SOA 的世界扮演的是服務提供者 (Web Services provider) 的角色；而服務消費者 (Web Services consumer)則是交給 Portal 平臺來扮演。因為portal可將后端的作業(yè)流程、服務，數據等，一一加以匯整，再根據前端瀏覽器具的不同，以及個人化的設定，將信息提供給終端的使用者。從Portal軟件開發(fā)的趨勢來看，Portal在IT中所扮演的角色，正逐漸從早年作為內容管理的門戶，逐步邁向process portal之路。

在Web Services的安控方面，最直接的作法，固然是可以將權限控管等安全相關的邏輯直接寫死在Web Services 的應用里，但這種將安控邏輯內嵌在多支程序中的作法，將成為未來在更新、維護和管理上令人頭疼的問題。比較理想的方式，是透過可橫跨整個平臺的安控機制，集中擬定各項與Web Services相關的安控設定。

這就與流程控管、服務路由，以及負載平衡相同，如果可以經由平臺提供設定與控管的功能，而不是在應用軟件（AP）的層級進行，將在整體維護及整合雙方面，產生極大的幫助。

此外，在Web Services的營運方面，幾個比較新的領域還包括了Web services 的管理、效能水平監(jiān)測 (SLA；Service-Level Agreement)、業(yè)務流程監(jiān)控 (BAM；Business Activity Monitoring)，以及Web services 訊息攔截和轉運等?，F階段，已有多家廠商開始在這些領域中進行愈來愈多的著墨。

正因為應用平臺提供了多項 SOA 需要的加值功能，許多分析師都一致看好幾個主要的應用平臺廠商，在未來將囊括大半的SOA市場。此外，由于應用服務器與相關科技，已經在許多企業(yè)中具有相當程度的導入經驗，所以若從技能與基礎設施共享，以及IT資產集中化等潮流與角度審視，以應用平臺作為邁向SOA的基礎環(huán)境自是最邏輯的選擇。(zdnet)