通過將這些原則應(yīng)用到面向服務(wù)的體系結(jié)構(gòu)設(shè)計，可以幫助通過IT靈活性實現(xiàn)業(yè)務(wù)靈活性遠(yuǎn)景。

　　引言

　　面向服務(wù)的體系結(jié)構(gòu)（Service-Oriented Architecture，SOA）提供了支持業(yè)務(wù)靈活性的IT靈活性遠(yuǎn)景。在本文中，我們將重點討論IT靈活性的兩個特定方面：流程實現(xiàn)的分離和簡化。如何說明和實現(xiàn)各個服務(wù)對IT靈活性的這些方面有很大的影響，因此也對業(yè)務(wù)靈活性有很大的影響。我們此處的目標(biāo)是提供支持SOA遠(yuǎn)景的服務(wù)說明和實現(xiàn)指南。本文的論述結(jié)構(gòu)如下：

　　·首先，我們將描述將在其中說明和實現(xiàn)服務(wù)和服務(wù)操作的上下文環(huán)境。我們將考慮SOA基礎(chǔ)結(jié)構(gòu)的職責(zé)和服務(wù)的職責(zé)。
　　·接下來，我們將討論適用于整個服務(wù)（而不是各個操作）規(guī)范的設(shè)計原則。
　　·最后，我們將說明適用于各個服務(wù)操作的設(shè)計原則。

　　我們在文中所給出的設(shè)計原則旨在通過改善流程實現(xiàn)的分離和簡化來提高IT靈活性，因此，我們將通過對這些理念進(jìn)行更為深入的分析來完成我們的介紹。

　　分離

　　SOA原則非常強(qiáng)調(diào)將服務(wù)使用者和服務(wù)提供者分離開來，關(guān)于此類分離實際的含義，有很多不正式但非常有用的約定。分離背后的一個基礎(chǔ)概念就是，對服務(wù)提供者的修改不應(yīng)要求在服務(wù)使用者中進(jìn)行相應(yīng)的修改。例如，將當(dāng)前在特定操作系統(tǒng)上運(yùn)行的服務(wù)重新部署到另一個平臺的決定完全可能不要求對服務(wù)使用者進(jìn)行更改。一個主要的SOA指導(dǎo)原則就是，要減少使用者和提供者之間的依賴關(guān)系。

　　分離應(yīng)用于技術(shù)層面，強(qiáng)調(diào)Web服務(wù)和異步消息交付之類的技術(shù)，以允許使用者獨立于服務(wù)提供者選擇實現(xiàn)和可用性選項。我們還可以通過各種方式讓SOA基礎(chǔ)結(jié)構(gòu)實現(xiàn)技術(shù)分離，如：

　　表1. 分離技術(shù)

　　服務(wù)應(yīng)該設(shè)計為與要部署到其中的SOA基礎(chǔ)結(jié)構(gòu)兼容，特別是，服務(wù)應(yīng)確保避免不必要的耦合。舉個相反的例子，有狀態(tài)服務(wù)接口將傾向于通過將使用者與特定提供者實例關(guān)聯(lián)來增加使用者和提供者間的耦合。

　　分離的概念也同樣適用于非技術(shù)的業(yè)務(wù)層次。服務(wù)使用者應(yīng)該盡可能與服務(wù)提供者實現(xiàn)的業(yè)務(wù)邏輯細(xì)節(jié)分離。為了實現(xiàn)此類分離，同樣也需要進(jìn)行細(xì)心的設(shè)計。在下面的服務(wù)設(shè)計原則部分，我們將討論將服務(wù)接口表述為有意義的業(yè)務(wù)操作（而不是細(xì)粒度的原語方法）的好處。

　　流程實現(xiàn)

　　在SOA中，我們通過對各個服務(wù)進(jìn)行編排（通過編程方式或使用基于業(yè)務(wù)流程執(zhí)行語言——Business Process execution Language，BPEL——的工具）來實現(xiàn)業(yè)務(wù)流程。如果要實現(xiàn)SOA遠(yuǎn)景，則必須簡化創(chuàng)建和修改流程的任務(wù)——即，服務(wù)編排任務(wù)。

　　業(yè)務(wù)流程編排的目標(biāo)在于實際而有效地實現(xiàn)所需的業(yè)務(wù)邏輯。流程實現(xiàn)人員所面臨的問題包括：

　　·選擇恰當(dāng)?shù)姆��?wù)操作
　　·確定使用正確參數(shù)調(diào)用服務(wù)的順序
　　·處理各種可能的響應(yīng)，包括錯誤響應(yīng)

　　應(yīng)當(dāng)清楚，服務(wù)設(shè)計的質(zhì)量對編排簡化有很大的影響。有關(guān)服務(wù)、操作和參數(shù)的名稱和數(shù)量以及文檔質(zhì)量和服務(wù)操作之間的相互依賴程度——所有設(shè)計問題——的決策都可能給編排帶來很大的影響。

　　SOA設(shè)計原則

　　這一部分是有關(guān)整個SOA系統(tǒng)的指南，代表了在建立系統(tǒng)時需要進(jìn)行決策的各個方面。您將向設(shè)計人員和實現(xiàn)人員提供哪些規(guī)則和指導(dǎo)方針？您的SOA基礎(chǔ)結(jié)構(gòu)將提供何種功能？我們將給出一系列建議設(shè)計原則，但每個都是設(shè)計過程中的一種折衷做法。您的企業(yè)可能有具體的要求，而需要選擇與我們提供的常規(guī)建議不同的選項。我們提出設(shè)計原則的目的在于標(biāo)識需要進(jìn)行決策的方面；而此類決策則是架構(gòu)設(shè)計人員的責(zé)任。我們并不認(rèn)為所提出的設(shè)計原則非常全面；在您的企業(yè)中實現(xiàn)SOA時，很有可能會采用其他原則，我們非常希望您能將這些設(shè)計原則反饋給我們。

　　SOA要求一致性

　　有很多可用于創(chuàng)建、發(fā)布、發(fā)現(xiàn)和調(diào)用服務(wù)的候選技術(shù)。SOA應(yīng)提供一個參考體系結(jié)構(gòu)，以指定服務(wù)提供者和使用者將使用的特定機(jī)制；我們應(yīng)以在SAO所有參與者間實現(xiàn)一致性為目標(biāo)。此類一致性可以減少開發(fā)、集成和維護(hù)工作。

　　如果需要使用參考體系結(jié)構(gòu)之外的元素，我們推薦使用補(bǔ)充性方法。例如，假如我們?yōu)榉��?wù)發(fā)布和發(fā)現(xiàn)選擇的機(jī)制是UDDI，但某個特定的開發(fā)團(tuán)隊已在使用一個基于其他存儲庫技術(shù)的開發(fā)流程，此時該如何處理呢？我們將選擇投入精力將該團(tuán)隊的服務(wù)同時發(fā)布到兩個存儲庫。這樣，現(xiàn)有的服務(wù)使用者就可以使用其熟悉（但可能并不標(biāo)準(zhǔn)）的存儲庫了。而運(yùn)行于公共SOA基礎(chǔ)結(jié)構(gòu)上的使用者則可以為所有服務(wù)使用標(biāo)準(zhǔn)存儲庫——例如UDDI。

　　SOA簡化開發(fā)

　　我們希望任何企業(yè)級的SOA基礎(chǔ)結(jié)構(gòu)都具有可伸縮性和彈性；還應(yīng)包含行業(yè)級的企業(yè)服務(wù)總線（EntERPrise Service Bus，ESB）和安全技術(shù)。或者，換種說法，以SOA為目標(biāo)的服務(wù)和流程的開發(fā)人員可利用成熟的中間件，依賴SOA基礎(chǔ)結(jié)構(gòu)提供問題的解決方案，如身份驗證、消息轉(zhuǎn)換和可靠消息交付。

　　這些中間件功能的提供應(yīng)以一個重要的原則為基礎(chǔ)：服務(wù)和流程開發(fā)人員應(yīng)遠(yuǎn)離中間件實現(xiàn)的復(fù)雜細(xì)節(jié)。我們的理想目標(biāo)是，在我們的SOA環(huán)境中工作的開發(fā)人員應(yīng)只需要業(yè)務(wù)領(lǐng)域的相關(guān)知識和基本的編程技巧。

　　我們可以通過各種方式實現(xiàn)此目標(biāo)，如下所述：

　　·聲明技術(shù)：J2EE編程模型就是使用聲明技術(shù)提供應(yīng)用程序邏輯和中間件配置分離的一個例子。例如，應(yīng)用程序組裝人員通過在部署描述符（而不是代碼）中添加相應(yīng)條目來應(yīng)用EJB方法角色的安全授權(quán)；然后部署人員會將這些角色映射到用戶和組。請注意，部署人員無需編寫任何授權(quán)代碼。
　　·抽象： 在某些情況下，SOA基礎(chǔ)結(jié)構(gòu)中可以提供API，以用于特定的用途。例如，SOA基礎(chǔ)結(jié)構(gòu)可以提供錯誤報告和審核機(jī)制。在設(shè)計此類API時應(yīng)非常小心，要注意其易用性。我們應(yīng)優(yōu)先考慮聲明技術(shù)，而不是對這些機(jī)制進(jìn)行編程配置。同樣，在標(biāo)準(zhǔn)API可用時（例如Java日志API），我們應(yīng)通過這些標(biāo)準(zhǔn)API公開SOA基礎(chǔ)結(jié)構(gòu)功能，而不是采用自己開發(fā)編寫的方式。
　　·代碼生成： 在無法避免代碼復(fù)雜性的地方，可以使用代碼生成技術(shù)。例如，Web服務(wù)描述語言（Web Services Definition Language，WSDL）就可以為開發(fā)人員隱藏SOAP、HTTP和JMS的復(fù)雜細(xì)節(jié)。這是通過組合用WSDL表示的可由計算機(jī)處理的接口定義和可從WSDL生成相關(guān)調(diào)用代碼的語言特定實現(xiàn)的工具來實現(xiàn)的。
　　·工具：在不可避免SOA基礎(chǔ)結(jié)構(gòu)的細(xì)節(jié)進(jìn)入開發(fā)人員代碼的情況下，我們可以通過使用合適的工具擴(kuò)展開發(fā)環(huán)境來減少開發(fā)人員工作的復(fù)雜性。IBM Rational Software Development Platform產(chǎn)品所提供的基于Eclipse的環(huán)境可使用自定義插件、代碼片段和用戶指南輕松地進(jìn)行擴(kuò)展。
　　·模型驅(qū)動的開發(fā)：模型驅(qū)動的開發(fā)技術(shù)可以被視為前面兩種方法的特定復(fù)雜組合，同時利用了工具和代碼生成功能來簡化開發(fā)體驗。開發(fā)人員生成統(tǒng)一建模語言（Unified Modeling Language，UML）模型，此類模型可轉(zhuǎn)換為相應(yīng)的代碼，其中包含利用SOA基礎(chǔ)結(jié)構(gòu)所必需的代碼。

　　總之，在定義面向服務(wù)的體系結(jié)構(gòu)及其基礎(chǔ)結(jié)構(gòu)時，我們必須特別注意開發(fā)人員的需求。當(dāng)為開發(fā)人員提供指南，以告知他們應(yīng)如何開發(fā)或使用服務(wù)時，我們應(yīng)該尋找可促進(jìn)這些指導(dǎo)方針遵循的機(jī)制。一個總的原則是“只要可方便完成所需的工作，就說明方法是正確的�！睋Q句話說，遵循相關(guān)指南應(yīng)當(dāng)為阻力最小的方法。SOA內(nèi)的控制對其成功甚為關(guān)鍵。

　　從開發(fā)人員的角度而言，他們有責(zé)任了解SOA基礎(chǔ)結(jié)構(gòu)和指南，并積極使用指南，而不要嘗試進(jìn)行規(guī)避。

　　服務(wù)具有標(biāo)準(zhǔn)的、經(jīng)過正式定義的可由計算機(jī)處理的接口

　　了解了工具和代碼生成在SOA實現(xiàn)中可扮演重要角色之后，我們現(xiàn)在要強(qiáng)調(diào)使用可由計算機(jī)處理的接口的重要性。當(dāng)使用定義良好的可由計算機(jī)處理的語言描述了接口時，實際上就為各種工具支持功能提供了支持。我們希望改善分離狀況，因此我們強(qiáng)烈建議使用WSDL之類正式定義的開放標(biāo)準(zhǔn)語言，而不要使用專用格式。

　　可由計算機(jī)處理的方法的概念應(yīng)該從服務(wù)接口描述（如WSDL）擴(kuò)展到所有其他形式的聲明信息或元數(shù)據(jù)。只有同時強(qiáng)調(diào)聲明技術(shù)和可由計算機(jī)處理的元數(shù)據(jù)，才能將其相關(guān)的復(fù)雜性從業(yè)務(wù)應(yīng)用程序開發(fā)人員轉(zhuǎn)移到基于標(biāo)準(zhǔn)的中間件中。新興的WS-Policy之類的技術(shù)在支持此方法方面充當(dāng)著重要的角色。

　　服務(wù)應(yīng)設(shè)計為可重用

　　服務(wù)設(shè)計人員應(yīng)該記住，他們所開發(fā)的任何服務(wù)都可能成為可重用資產(chǎn)。設(shè)計人員不應(yīng)只關(guān)注服務(wù)的最初使用者的需求，而應(yīng)該進(jìn)行更為廣泛的業(yè)務(wù)分析，以確定更全面的需求。我們建議，設(shè)計人員應(yīng)考慮服務(wù)可能的發(fā)展方向：

　　·設(shè)計必須能適應(yīng)不斷增加的吞吐量；如果服務(wù)在使用服務(wù)的數(shù)量增加的情況下仍可成功運(yùn)行，那么使用率也會成級數(shù)遞增。
　　·如果使用服務(wù)的數(shù)量增加，則數(shù)據(jù)量和并發(fā)數(shù)據(jù)訪問模式可能會與最初投入使用時的情況大為不同。
　　·我們必須對服務(wù)請求的未來增長進(jìn)行預(yù)計；新使用者可能需要其他的功能，或者需要對現(xiàn)有功能進(jìn)行更改

　　文本其余部分所討論的很多設(shè)計原則都與確保服務(wù)的可伸縮性和可維護(hù)性密切相關(guān)。需要提醒一下：可能會由于考慮了潛在的重用而采用不恰當(dāng)?shù)脑O(shè)計方法對服務(wù)進(jìn)行設(shè)計，從而導(dǎo)致實現(xiàn)“過當(dāng)”。我們鼓勵將最初的重點放在服務(wù)接口設(shè)計上，以確保其支持可伸縮性；我們的設(shè)計原則可幫助做到這一點。然后生成一個該接口的戰(zhàn)術(shù)型實現(xiàn)，要求足以滿足目前已知的需求。假如該接口設(shè)計良好，應(yīng)該可以在出現(xiàn)相關(guān)需求時替代伸縮性更好的實現(xiàn)。

　　服務(wù)設(shè)計原則

　　我們曾說過，服務(wù)是其接口采用某種一致認(rèn)可的格式發(fā)布的服務(wù)操作的邏輯分組，那么我們接下來將討論適用于整個服務(wù)的設(shè)計原則。在下面的服務(wù)操作設(shè)計原則中，我們將討論各個操作的設(shè)計。

　　命名服務(wù)時應(yīng)以最大化易用性為目標(biāo)

　　我們在選擇服務(wù)、操作、數(shù)據(jù)類型和參數(shù)的名稱時有一個指導(dǎo)原則：希望最大化服務(wù)的易用性。我們希望幫助流程開發(fā)人員標(biāo)識實現(xiàn)業(yè)務(wù)流程所需的服務(wù)和操作。因此，我們強(qiáng)烈建議使用服務(wù)使用者專業(yè)領(lǐng)域內(nèi)有意義的名稱，優(yōu)先選用業(yè)務(wù)概念而不是技術(shù)概念。

　　我們的建議就是：應(yīng)使用名詞對服務(wù)進(jìn)行命名；而應(yīng)使用動詞對操作進(jìn)行命名。

　　比較清單1和清單2中所示的兩個服務(wù)定義。我們使用簡化的偽代碼來減少編程語言“簇”。

　　清單1. 使用動詞短語和IT構(gòu)造的服務(wù)定義

 ManageCustomerData {
 
  insertCustomerRecord()
 
  updateCustomerRecord()
 
  // etc ...
 }
 
　　清單2. 使用名詞和動詞短語及業(yè)務(wù)概念的服務(wù)定義

　　 CustomerService {
 
  createNewCustomer()
 
  ChangeCustomerAddress()

  CorrectCustomerAddress()
 
  EnableOverdraftFacilityForCustomer()
 
  // etc ...
 
 }

　　請注意清單1中的定義是如何使用IT概念進(jìn)行表述并同時為服務(wù)和操作使用動詞短語的。在清單2中，服務(wù)表述為名詞，而操作則使用具有清楚的業(yè)務(wù)含義的動詞短語進(jìn)行命名。我們認(rèn)為第二個示例的易用性更好一些。此外，在第二個示例中，服務(wù)的業(yè)務(wù)用途非常清楚，而不單是僅僅指示其輸出。因此，我們不使用“update customer record”（可以為出于任何原因進(jìn)行的任何更新），而使用“enable overdraft facility”。與此類似，在客戶搬遷時，我們使用“change customer address”方法更改客戶地址；而在希望更正無效數(shù)據(jù)時使用“correct customer address”更正客戶地址，因為這樣很容易看出這兩個操作采用了不同的服務(wù)邏輯。

　　如果采用業(yè)務(wù)概念表述服務(wù)和操作名稱，則必須密切注意如何確定這些名稱。這就非常需要有一個正式的術(shù)語詞匯表，可以通過業(yè)務(wù)分析活動得到這個詞匯表。詞匯表應(yīng)該有一個正式的所有者。

　　服務(wù)應(yīng)具有精心選擇的粒度

　　粒度 一詞在SOA相關(guān)討論中有多種不同的用法。在本文的服務(wù)設(shè)計討論中，我們考慮的是服務(wù)本身的粒度，即服務(wù)應(yīng)該包含的操作數(shù)量。

　　沒有可用于確定服務(wù)粒度的簡單啟發(fā)式方法。我們將提供兩個在設(shè)計服務(wù)時應(yīng)該考慮的因素的示例加以說明：

　　·服務(wù)將通常作為測試和發(fā)布的單位。如果粒度過粗，而將大量操作分組到單個服務(wù)中，則可能將增加服務(wù)的使用者。因此，如果我們對服務(wù)的某些方面進(jìn)行更改（可能僅為了其中一些使用者的利益），則必須重新發(fā)布整個服務(wù)，從而可能影響所有使用者。
　　·服務(wù)使用者所面臨的一個挑戰(zhàn)就是找到正確的操作。通常，使用者需要瀏覽服務(wù)列表，然后在標(biāo)識了合適的服務(wù)后瀏覽服務(wù)操作列表。我們認(rèn)為，服務(wù)粒度的兩個極端——提供僅有幾個方法的很多服務(wù)，或數(shù)十或數(shù)百個操作均集中在幾個服務(wù)中——都將對易用性造成影響。

　　這表明，在選擇服務(wù)粒度時，我們可能需要在多個因素間進(jìn)行折衷，如可維護(hù)性、可操作性和易用性。任何給定的SOA都應(yīng)向服務(wù)設(shè)計人員提供指南，以便確定此類折衷方案。

　　服務(wù)應(yīng)是內(nèi)聚而完整的

　　既然認(rèn)識到了在確定服務(wù)粒度時需要考慮周全，那么在確定哪些操作應(yīng)組成服務(wù)時有什么注意事項呢？我們認(rèn)為有兩個對象設(shè)計概念很有用：內(nèi)聚性和完整性。我們可將這些概念應(yīng)用于服務(wù)接口。

　　我們希望創(chuàng)建功能內(nèi)聚的接口，一組操作由于其功能相關(guān)而聚合到一起。我們發(fā)現(xiàn)，當(dāng)評估內(nèi)聚程度時，從服務(wù)使用者角度看待服務(wù)很有用。通過使用者的視角，我們會將重點放在服務(wù)的功能上。將此方法與使用以下內(nèi)聚標(biāo)準(zhǔn)進(jìn)行對比：

　　·我們可以考慮基于功能實現(xiàn)的內(nèi)聚性進(jìn)行決策。是否應(yīng)由于操作使用相同的算法分組到一起，或者由于均是使用相同主機(jī)上的CICS事務(wù)實現(xiàn)的而將其分組到一起？這些是實現(xiàn)細(xì)節(jié)，不應(yīng)影響接口設(shè)計。
　　·可以使用時間內(nèi)聚性原則，即，將在短時間內(nèi)一起使用的操作分組到一起，例如，RetrieveCustomerDetails、CheckCreditRating、createLoanFacility和TransferFunds操作都可能在金融業(yè)務(wù)流程中依次出現(xiàn)。不過，時間內(nèi)聚性并不意味著這些操作應(yīng)該由同一個服務(wù)提供，CheckCreditRating和TransferFunds就缺乏功能內(nèi)聚性。

　　使用名詞-動詞對服務(wù)和操作進(jìn)行命名的規(guī)則可以幫助我們將重點放在服務(wù)接口的功能內(nèi)聚性上。我們可以問這樣一個問題“這個動詞是否是該名詞所進(jìn)行的操作？”

　　我們的第二個對象設(shè)計概念是完整性概念。在為已知使用者創(chuàng)建服務(wù)時，完整性的問題尤為值得注意。在這種情況下，我們通常會將重點放在滿足所知的使用者需求上。請務(wù)必記住，服務(wù)應(yīng)該為可重用的，因此需要考慮將來的使用者的可能需求。舉個簡單的例子，假如有個名為CellPhone的服務(wù)提供create、update、Query、delete和Deactivate等操作。我們完全可以想象會需要對棄用的手機(jī)進(jìn)行重新激活，因此應(yīng)決定是否也應(yīng)提供對稱的Activate方法。

　　通過判斷，我們應(yīng)該應(yīng)用完整性規(guī)則。如果不知道使用者需求，則可能很難提供正確的功能，因此就有可能存在將開發(fā)和測試工作浪費(fèi)在提供將不會使用的操作上的風(fēng)險。

　　服務(wù)應(yīng)對實現(xiàn)細(xì)節(jié)進(jìn)行封裝

　　另一個對象設(shè)計原則（封裝）也適用于設(shè)計服務(wù)接口。我們封裝服務(wù)實現(xiàn)的細(xì)節(jié)——所用的算法和資源——的動機(jī)在于增加服務(wù)使用者和提供者之間的分離，從而為將來擴(kuò)展提供靈活性。

　　服務(wù)適應(yīng)多種調(diào)用模式

　　WebSphere等提供的Web服務(wù)技術(shù)允許進(jìn)行更高層次的封裝。服務(wù)使用者通過使用各種調(diào)用模式，可以使用完全相同的代碼技術(shù)來調(diào)用Web服務(wù)，如以下這些模式：

　　·使用SOAP over HTTP的傳統(tǒng)同步調(diào)用
　　·使用SOAP over JMS的基于消息的異步調(diào)用
　　·使用Java過程調(diào)用的本地調(diào)用

　　不過，雖然Web服務(wù)基礎(chǔ)結(jié)構(gòu)可以封裝調(diào)用的細(xì)節(jié)，從而簡化代碼，但服務(wù)設(shè)計也應(yīng)對調(diào)用方式加以考慮。對比一下本地調(diào)用和遠(yuǎn)程調(diào)用。與清單3所示內(nèi)容類似的服務(wù)設(shè)計可以提供有價值的業(yè)務(wù)功能，但卻不適合在很多SOA環(huán)境中部署。

　　清單3. 繁忙型服務(wù)接口

 LibraryCatalogService {
  // search operations elided
 
  String getBookTitle(String isbn)

  String getBookAuthor(String isbn)

  Date getBookPublicationDate(String isbn)

  // further operations elided
 }

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：實現(xiàn)SOA服務(wù)設(shè)計原則是什么？（上）

本文網(wǎng)址：http://www.ezxoed.cn/html/support/1112153779.html