SOA開發技能中的不同開發人員類型介紹
傳統的三層架構通常包括一個呈現層、一個中間層或應用層，和一個數據層。在某些情況下，開發人員要負責這三層的所有工作。在較大規模的公司中，可能會有專門的UI開發人員、應用開發人員和數據庫開發人員等。在SOA中，除了在集成應用時，可以說應用這個概念已經與SOA毫無干系。在SOA中，我們構建的是獨立于應用的業務服務。下圖列出了SOA所需要的開發人員的類型。
現在來談談業務服務。業務服務是各層所有開發人員所做的工作的集合體。比如一個像在亞馬遜上所用的“購物車”這樣的業務服務，它很可能是由服務和/或寄存在這個架構中的各層組件所構成。呈現層包含最終的使用方式，也就是用戶最終看到并在瀏覽器上使用的樣子。業務過程層包含引導用戶從開始到最后付款結束的整套邏輯流。業務規則層包含稅收、折扣、會員等規則，而底層的數據元素和結構則是在數據層處理的。在許多情況下，由于合并、兼并、多年的遺留系統、第三方應用的購買等諸多因素，公司會使用多種數據結構提供相似的功能。數據層的存在就是為了提取這些數據結構并以相同的形式呈現出來，掩蓋底層的復雜實現方式（可以想像主數據管理）。
所以，要開發這樣一個購物車的業務服務，所有工作在架構中不同層上的開發人員都要全力協作，并以滿足公司所采用的SOA治理中所定義的業務需求與技術需要為前提。其中的技術需要可能是：
◆遵守WS-*安全標準
◆數據加密策略
◆平臺無關
◆滿足具體的性能要求
為什么要說這么多呢？因為在面向服務的架構中，一個成功的開發人員需要具備以下特征：
◆靈活、變通
◆協作能力
◆可以與同僚一起檢查他們的工作
◆能看清大局
◆不會固執地偏好某種特定技術
◆能接受建設性的批評
◆創新精神
那些不容別人批評自己的工作或偏好某一種技術的人可能會在SOA中遇到不少困難。SOA目標之一就是構建靈活、可維護性好、松耦合、與平臺無關的軟件。要構建這樣一個軟件就必須從軟件開發轉向軟件工程。簡單來說，我們必須從拖曳的工作方式轉向計劃建模的工作方式。我們必須能夠接受協作、同行審查和治理。如果開發人員不喜歡這些東西，他們要么選擇改變，要么選擇離開。否則他們將成為巨大隱患，并且一直拖后腿。
好了，現在我們來談談開發人員的分類。但是在此之前需要強調一下，這里討論的是分類，而不是個體。在小型企業里，一個開發人員可能會跨越多個分類。在大型企業中，我們可能會看到非常專業化的開發人員工作在架構中的單獨一層。最后聲明一點：討論的默認前提是存在一個架構團隊，并且各層中存在一定程度的標準與治理。
UI開發人員
如果公司有能力專門化，那么這會是非常棒的一層。這層的開發人員并不需要非常高深的技術。重要的是他們要明白可用性、UI標準和Web界面的最佳實踐。這些人可以從模擬開始，與業務部門或業務分析員合作分析各種情況，最終達到一致的結果。這些開發人員必須能用業務用語和業務部門交流，并且能明白商務用戶如何使用網絡技術進行交互。
業務過程開發人員
在這個業務過程層中有兩種截然不同的類型：一種處理業務過程建模，另一種處理業務過程與底層服務和系統的集成。在某些公司里可能會讓一個人完成這兩項任務，但是更多情況下這會是兩個人的工作，因為這兩方面需要不同的技能。負責業務過程建模的人甚至可以不是IT人士。某些公司在業務方面設有專門部門，部門中的人主要負責改善并自動化業務過程。（這種公司都是使用6Six Sigma或全員質量管理的公司。）
業務過程集成是一個技術活，它需要Web服務、REST、JMS隊列或其它類似的專業知識。負責集成的人是將業務過程與控制業務服務流程和組合業務應用（通常稱為編排）的后端技術聯系到一起的人。
業務規則開發人員
這一類型有點模糊，并不是所有架構都有一個具體的業務規則層。某些情況下，這些業務規則是在數據層中進行控制的。對于那些有非常動態的業務規則，特別是以客戶為中心并且允許終端用戶甚至顧客更新規則的公司來說，提取出一個業務規則層來是很有必要的。如果公司有一個業務規則層，并且使用某個工具來管理業務規則，那么這個公司很可能會需要一個技師來管理這一層，就像數據庫維護人員維護數據庫層一樣。在某些情況下，這份工作也可能交給數據庫維護人員來做，當然這是靈活的。
不管由誰來做，他們都必須明白這一層的含義并尋找能讓終端用戶更快地對業務變化做出反應的辦法。比如，一個貸款審批程序需要這樣的一個特定狀態的業務規則：貸款申請人需要具備多少比例的資產才有可能得到審批。這個比例值經常要根據狀態進行改動，所以必須能夠盡量快地保持更新。最佳的辦法是把IT從這個過程中剔除出去，讓某個具有授權的特定的人（或系統）按需對這個值進行更新。不管是誰負責這個業務規則，他都必須能夠與業務部門和/或業務分析員共同協作，明白變動的頻率、許可權限以及各種業務規則所帶來的影響。另外，與此相關的還有大量與創建和管理規則相關的日常支出，負責人必須能夠權衡利弊并做出決定。
數據服務開發人員
或許我們應該稱他為信息結構工程師。他要負責提取底層的數據層并將其暴露給架構中的其它層，甚至提供給外部的其它系統。比如，假如購物車業務服務允許多種支付方式（美國運通卡、Visa和Pay Pal）。另外，不同產品（書籍、DVD、衣物等）分別由不同的庫存系統進行管理。我們需要隱藏這些復雜的東西，并可以隨時添加其它的支付服務和庫存管理方式。因此，我們使用數據服務來為購物車提供數據的邏輯視圖。也就是說，我們創建了一個可以提供給購物車的標準的支付與庫存信息。只要購物車使用的是這些標準消息，那么底層的各種支付與庫存服務的物理實現就毫無干系。購物車服務只需要識別這些信息的標準格式，而標準信息到接收系統的轉換工作就交給數據服務層。
這一層的開發人員（或架構師）必須具備數據建模和數據庫設計領域方面的知識。即使公司有工具可以管理這一層（我們也建議這樣做），管理員這一職位也是需要的。
數據庫開發人員
現在各個企業通常都有這一層，這就是DBA工作的地方。在SOA環境下，DBA必須更緊密地與架構中其它層的開發人員合作。他們必須明白各層的安全與性能要求，并保證底層的數據模型能夠滿足這些要求。因為舊系統的集成在當前的SOA建設中還很常見，所以通常都會需要DBA創建結構的視圖，甚至建立新的ETL過程為架構中的其它層提供數據視圖。
安全開發人員
雖然安全專家們可以不做實際的開發工作，但是必須有人或者有團隊能夠了解當前SOA所面臨的安全方面的挑戰。SOA可能會產生以下威脅：
◆暴露原本不可暴露在防火墻外的舊系統
◆多系統之間的免登錄切換需要信任
◆將一條信息分別按不同的安全準則發往多個合作伙伴
◆將信用卡或其它隱私問題暴露到網絡上
現在的多層安全模型在B2B類型的SOA上尚存在許多不足。這一領域的開發人員必須對信息協議、安全性最佳實踐、網絡架構、法案（比如HIPAA、SOX、PCI）和WS-*或其它標準有深入的了解。
總結
我們可以看到，成功實現SOA需要多種截然不同的開發技能。要找到一個熟練掌握所有技能的人是不實際的。即使有這么一個人，那么他也只可能在你的架構團隊里。這個架構的高明之處在于它能夠把各層的問題分解并解決掉。一個業務服務可以由各層的許多人員共同完成。這需要堅固的治理、扎實的技巧和團隊協作，而這也正是為什么需要在合適的位置安排合適的人來解決SOA中出現問題的原因。下一篇文章將討論SOA系統中測試人員所需技能，以及他們與開發團隊的關系。
【編輯推薦】
