嘗試用SOA去思維

項目架構師剛剛把新的面向服務的架構（SOA）交給您（企業開發人員），以供系統實現業務實踐?，F在，您只需構建系統即可。SOA方法在設計和組織業務功能以及IT基礎架構方面極佳。SOA模型有助于確保系統的靈活性、可重用性和互操作性，使現在和將來進行管理和修改更容易。它也能節約成本。它只是可能不像光芒四射的新SOA一樣容易實現。

考慮一個類似的例子——建造一所房子。設計者可能非常優秀，但是那并不意味著他們設計的房子是可以信賴的。擔任建筑師的一位朋友講述了他的第一項任務的故事：落實一個公司的新辦公室計劃，它占用了一座巨大辦公樓的整個一層。新的入口處看起來富麗堂皇——直到我的朋友意識到前任建筑師忽略了一根承重柱子，這根承重柱子直接矗立在地板中央?，F在他有三個選擇：切段柱子，大樓也就破壞了；逐漸習慣于有一根柱子立在地板中央破壞美觀；或者更改計劃以反映現實。

開始之前

設計一個系統的架構也與此相同。如果在別人將SOA交給您的時候您才第一次了解SOA，那么您可能從一開始就遇到了麻煩。開發人員必須從業務流程的開端就參與業務流程的設計。對于保證真實性是SOA的一部分，開發人員的看法是非常寶貴的。這個看法來自技術、將來的發展以及特別的考慮等通用領域。

例如，在技術方面，開發人員與架構師的看法可能會不同。當然，在我們的房子上面搭上涼棚很好，但是我們將怎樣拉回屋頂呢？與此類似，寫下過程A將與過程B進行通信是容易的。但是，實際上，要使過程A與過程B通信良好可能需要能夠獲獎的——而且費用最大的——編程技巧。

靈活性也是SOA的目標之一，但是它可能會走得太遠。認為家庭辦公室有一天會被用作臥室——但是或許不是用作廚房——可能是聰明的想法。同樣，比如說，要求某種服務來處理所有的輸入可能沒有意義。調整SOA，反映出什么是難以做到的以及什么是很可能做到的，就能夠確保得到一種較好的結果。

開發人員不只是在規劃過程中令人掃興的人。他們往往了解不久后將成為可能并且會在SOA里出現的技術。在建造一所房子時，您可以預期某一天完成地下室，并且包括簡單的基礎結構。同樣，一家公司現在可能不提供無線服務，但是開發人員可以將它作為未來的可能性，這很可能帶來全新的業務面貌——以及SOA的重要部分。另外，開發人員可能知道SOA必須處理的特殊問題。例如，采用在Web上分布的組件服務模型時，通信的安全性可能比現有的內部應用需要更多的關注。

最后，在設計期間的信息流不應該僅僅是單向的。開發人員應該從架構師那里獲悉業務的結構——以及未來的方向。在以后的開發過程里，了解并且保持這個觀點對于指導決策將是至關重要的。

為開始做好準備

在開始開發過程之前，您需要從SOA的角度考慮技能、標準和工具等的特殊方面。這一部分是一種新SOA思維傾向。例如，既然整個服務思想是創造多個可重用組件，開發人員就必須超越一個應用程序的界限進行思考。您必須開始重用現有的服務，并且想像您的同事如何重用您的服務。打破舊的習慣，并且通過將服務鏈接在一起而不是通過編寫新代碼來構建應用程序，這可能是困難的。正確的態度將走向成功。

開發人員應該擁有面向服務的開發的正確技能。在業務流程、數據和元數據管理、消息傳遞和事務，以及安全性等方面，可能需要一些訓練。因為這應該是一個迅速的過程，在必要時，您希望人們已經為開始做好了準備。

將您的開發過程流線化。從一開始就使應用程序的生命周期標準化——包括交付階段——能夠緩解以后的麻煩。早早建立您的標準。這些標準可能是結構化信息標準促進組織（OASIS）的接口標準（比如WSDL）、協議標準（比如SOAP）、傳輸標準（例如HTTP和JMS），等等。要注意這些標準可能在現有的基礎設施和環境中遇到問題。

您可能需要面向Web服務的工具和一個SOA。不僅要考慮開發的特征，而且要考慮在企業內與其他成員通信的特征。如果您的可視化界面能夠將您的工作表達為非技術類型，那么您就可以節省很多工作量。您的工具應該能夠處理細節，例如元數據庫、XML索引和規則引擎。

煩惱的時刻

即使有了正確的培訓、態度、標準和工具，SOA開發也可能是困難的，這不足為奇。大多數業務流程基于實際的程序，這些程序復雜并且要求多個異步步驟。例如，一個簡單的采購訂單，可能涉及幾天的復雜工作流，并且要求幾個負責人簽署意見。您將面對無意義的副本，亂七八糟的數據，以及缺少集成。雖然您一次只能開發一種服務，但是您必須專注于整個系統：保持靈活性是困難的。即使您從實現一些高使用率的服務開始，您也必須知道它們將如何與其他服務交互。您一層一層地進行開發——核心應用程序基礎、公用服務層以及定制門戶層——但是您必須知道所作的更改是否真的沒有干擾其他層。

牢牢記住SOA的目標是重要的：靈活性、可重用性和互操作性。的確，對于給定的服務，有時看起來您只能挑選其中兩個，或者可能只能挑選其中一個。但是那些是目標。事實上，有時精練而靈活的組件的想法好像自相矛盾。如果它是精練的，它又怎能靈活地完成全部的工作？如果它足夠靈活，能夠處理所有事務，難道它會不復雜嗎？難道它會是精練的嗎？是的，要達到那個美妙的結合點，需要一些折衷。服務必須可供多個應用程序使用，因此，必須正確地開發。此外，我們需要維護并增強服務，因此，它們必須簡單。

這是不是聽起來全部不可能？不是的。它只需要一個更大的視角?？紤]一下房子的例子。您能僅僅掛起那扇門而完全不考慮到其他任何事情嗎？不，因為如果門不在這個位置，這里將開一扇窗。如果門在這里，它會影響墻里的布線。如果門在那里，它就影響了另一扇門的設置。您將找到合適的位置，但不是僅僅專注于那扇門：您必須查看它周圍的一切。利用SOA進行開發的情況也是一樣的。

為目前的需求進行開發是艱難的；為將來的需求進行開發則是一項更大的挑戰。除了觀察其他所有組件以外，您還需要留心觀察將來的可能性。如果您的服務是考慮到將來的需求而創建的，那么它們就可能用于將來的應用程序。這里有一個技巧：如果服務完全與當今業務實踐相匹配，那么它可能不支持對業務實踐的更改。如果服務接收特定的輸入，就使輸入通用化。如果該服務處理五個進程，那就讓它處理十個進程。如果它將結果傳輸給另一個服務，那么使另一個服務是可以選擇的。您需要的不是一套扳鉗，而是一把月牙扳鉗。

將來會出問題嗎？試著想像從現在起三年后，您正在將這種服務轉換到一個新職能。您希望它如何簡化您的工作？請記住，該代碼直接將轉換重用于為企業提高勞動生產率和節約成本，并且為您節省了開發時間。

節拍在繼續

盡管最初幾個服務不是流程的結束，但是它在不斷進行的過程中是一個有價值的里程碑。在執行了這些最初的組件之后，您應該能夠判斷它們是否達到了您的目標。其他服務能否容易地使用這些服務？如果能的話，那很好。如果地板不是水平的，那么現在就弄平，然后在上面進行建造。

在這個過程中，開發人員在某處發現意外的困難不足為奇。例如，因為種種原因，事實可能證明兩個業務流程終究不能使用同一個組件。在開發過程中，您應該有一種適當的機制，與架構師交流需要進行哪些更改。SOA不是青銅鑄成的：它是某臺機器上的一些小東西，正如您所使用的其他一切事務一樣。從假定更改是必不可少的開始，構建您需要加入任何所需更改的觸點。

您如何發出某些任務不能執行的調用？在不可能與“我們不能完成”之間有很大的差別。如果您陷入了這樣的困境，不要不戰而降。首先，進行一些研究。在討論區中詢問如何處理這樣的情況。如果有人已經解決了您需要執行的任務，那就表明您可能能夠完成它。即使他們的情況只是有點類似于您的情況，您也可以在這個有價值的問題上獲得一個看問題的角度。

如果那樣不能產生一個答案，那就回去找架構師協商。向架構師解釋困難。SOA可能需要修改。但是也可能是架構師們對此有設想，而您沒有。請記住他們是解決方案的一部分：如果他們有解決方案，那就使用它。

因為這是一個企業開發項目，因此，讓企業知道情況將如何發展是很重要的。您應該經常報告成果。解釋已完成的每個服務的意義，展示它在整個開發中所處的位置。當整個應用程序完成時，證明它們的商業價值。您應該使用一種方法來衡量投資收益：讓每個人都了解它。

這不僅對于企業來說是重要的，而且對于開發人員來說也是重要的。所有為腦海中的大圖——以及未來——所作的特殊的編碼工作都將獲得補償。并且企業會承認這種工作的價值?，F在該是舉行慶功宴的時候了。

SOA的未來

在2002年，Gartner Group稱SOA為“現代應用程序開發過程中惟一非常重要的主題”。執行SOA方法能夠幫助您更迅速地完成項目，并且更快地兌現投資收益率。不過，它仍是一種新方法，并非每個人都是這方面的專家。隨著時間的流逝，您和您的同事將能更熟練地實現面向服務的架構。您可以利用更多、更好的工具。那時將出現改進的策略，并且成為標準問題的標準解決方案。在正確的計劃和觀點指導下，您精心打造的服務將能夠在許多年內不斷運作、發展和改善。