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