【文章內(nèi)容簡介】 則，如：216。 標(biāo)準(zhǔn)化服務(wù)契約216。 服務(wù)松耦合216。 服務(wù)可重用性216。 服務(wù)自主性216。 服務(wù)的無狀態(tài)性216。 服務(wù)可發(fā)現(xiàn)和組合實際執(zhí)行過程中，其實是分析各項目組提供的系統(tǒng)間交互接口，對這些接口盡可能按照以上原則進(jìn)行調(diào)整，并要求原系統(tǒng)進(jìn)行修改，具體表現(xiàn)就是對接口進(jìn)行分析，對沒有完整業(yè)務(wù)含義的多個技術(shù)接口進(jìn)行合并，對相近接口進(jìn)行整合和擴充，調(diào)整為一個服務(wù)，對個別由多個系統(tǒng)共同完成一個完整業(yè)務(wù)的進(jìn)行架構(gòu)調(diào)整，調(diào)整為一個系統(tǒng)提供服務(wù)（常見場景是核心系統(tǒng)和前置系統(tǒng)各完成部分功能，由前端進(jìn)行接口組合調(diào)用）。另外，這些大的原則由于缺乏具體的操作說明，在實際過程中還是常常不知道該如何把握。 服務(wù)分析步驟在操作過程中，我們可以按以下步驟進(jìn)行服務(wù)分析：各個步驟主要工作如下：第一步：接口分析，主要是收集各系統(tǒng)間交互的接口信息；第二部：服務(wù)識別，主要是判斷是否有可用服務(wù)、是否需要調(diào)整之前的服務(wù)，是否需要新建服務(wù)；第三步：更新服務(wù)分析文檔，主要記錄接口分析的結(jié)果；第四步：編寫服務(wù)規(guī)范映射文檔，主要是定義服務(wù)的輸入輸出信息；第五步：編寫服務(wù)規(guī)范映射文檔，記錄原接口字段與服務(wù)定義字段的映射關(guān)系（字段轉(zhuǎn)換）；第六步：更新數(shù)據(jù)字典，定義全行規(guī)范的詞匯表；第七步：編寫接口映射文檔，記錄服務(wù)與接口的映射關(guān)系；第八步：發(fā)布服務(wù)規(guī)范以下介紹每步的具體操作，并給出模板作為參考。 接口分析接口分析的首要工作是收集各系統(tǒng)的需求文檔，通過需求文檔，了解、熟悉系統(tǒng)的功能說明，以便服務(wù)分析人員理解行業(yè)的業(yè)務(wù)內(nèi)容，為后續(xù)的服務(wù)定義奠定業(yè)務(wù)基礎(chǔ)。否則，在服務(wù)定義時，會出現(xiàn)缺乏行業(yè)知識，導(dǎo)致服務(wù)類別無法判斷、服務(wù)字段定義缺乏擴展性、對接口的調(diào)用系統(tǒng)缺乏敏感，不能及時發(fā)現(xiàn)其他系統(tǒng)對該接口的使用，帶來服務(wù)定義穩(wěn)定性、擴展性較差的問題。接口分析的原則是按照使用哪個接口，對該接口進(jìn)行分析的原則。比如，在該階段需要集成核心系統(tǒng)、信貸系統(tǒng)、網(wǎng)銀系統(tǒng)，則對核心系統(tǒng)中信貸、網(wǎng)銀使用的接口進(jìn)行分析，其他接口暫不分析。這樣的優(yōu)勢是，不用花費太多的精力完成全部外圍系統(tǒng)對核心系統(tǒng)的調(diào)用關(guān)系分析，可以快速構(gòu)建ESB平臺并上線，且給出的服務(wù)都會被使用和驗證。缺點是當(dāng)服務(wù)定義人員缺乏經(jīng)驗時，往往不能發(fā)現(xiàn)被信貸使用的接口實現(xiàn)的業(yè)務(wù)功能，基金或者IC卡系統(tǒng)也要使用，可能使用的是功能相近的其他接口，造成定義的服務(wù)缺乏部分字段，穩(wěn)定性差，后期需要不斷的調(diào)整。接口分析是按系統(tǒng)收集該系統(tǒng)與其他系統(tǒng)的訪問接口信息，要求各系統(tǒng)按照模板填寫，其中包含報文格式描述（銀行一般會有固定的幾種報文格式，一般由核心系統(tǒng)的實施商制定，其他系統(tǒng)相互訪問也按照該格式；具有國際標(biāo)準(zhǔn)如858），接口的功能描述、接口處理邏輯和流程，接口的輸入輸出字段的詳細(xì)描述、使用的代碼的描述、沖正或反交易的描述、異常的描述等信息。接口收集的模板可參考如下文件，根據(jù)自身需要作調(diào)整。獲取接口文件的同時，盡可能拿到該系統(tǒng)的系統(tǒng)架構(gòu)，因為在實際分析過程中可能涉及到功能實現(xiàn)的調(diào)整，如將前置的支付功能剝離出來，改造為支付平臺實現(xiàn)，這也是前面提到服務(wù)分析人員最好具有技術(shù)背景的原因，因為涉及到架構(gòu)調(diào)整，需要說服相關(guān)人員調(diào)整的必要性、合理性和先進(jìn)性。另外，對需求文檔中得業(yè)務(wù)背景、不清楚的部分需要跟業(yè)務(wù)人員溝通，明確具體的業(yè)務(wù)要求。對新系統(tǒng)，則需要參加該系統(tǒng)的分析過程，以掌握第一手資料和詳細(xì)的業(yè)務(wù)信息，這些業(yè)務(wù)背景信息可能在形成的需求文檔中并沒有描述和體現(xiàn)。 服務(wù)識別拿到接口文件之后，即可開始對接口進(jìn)行分析，首先從已有的服務(wù)中查看是否已有該對應(yīng)服務(wù)；若沒有，確定是否可通過服務(wù)組合的方式提供；再確認(rèn)是否可通過擴展原有服務(wù)滿足該功能；若還沒有發(fā)現(xiàn)，則需要新建服務(wù)，此時，需要對服務(wù)進(jìn)行業(yè)務(wù)歸類，是金融類、查詢類、通用類、沖正類還是其他類別。查看是否有已有服務(wù)是否可通過組合實現(xiàn)是否可調(diào)整原有服務(wù)支持該需求是否需要新增這其實也涉及到服務(wù)的粒度劃分問題，之前我們提到服務(wù)設(shè)計的原則，其中一個重要的特性是重用，除此之外，還要強調(diào)業(yè)務(wù)完整性，也就是不能依賴其他服務(wù)才能提供完整的業(yè)務(wù)含義。舉一個例子，對公對私客戶新增時，由于需要的字段信息有很多不同，若強行定義為一個服務(wù)，則該服務(wù)內(nèi)字段可能超過100個，且對公對私要求的字段屬性如“是否必輸項”很難描述，在ESB平臺進(jìn)行報文有效性判斷時，也需要設(shè)定大量的邏輯驗證規(guī)則（如客戶類型為對公，則公司名稱、營業(yè)執(zhí)照號、注冊資金、法人代表名稱、注冊地等不為空），實際使用過程中也非常不便，雖然是復(fù)用度很高，但這是無意義的復(fù)用，而可取的做法是整合各系統(tǒng)對客戶信息的不同字段要求，整合為對公、對私客戶信息維護(hù)，如整合核心系統(tǒng)、信貸系統(tǒng)（過程可參考CIF的客戶基本信息整合），這才是有意義的復(fù)用。另外，比如賬戶交易明細(xì)查詢，若原有接口為對公一個接口、對私一個接口，此時，則可以完全合并，因為對應(yīng)的接口非常相近，完全可以整合為一個。服務(wù)的粒度劃分非常難以掌握，也缺乏統(tǒng)一的標(biāo)準(zhǔn)和操作指導(dǎo)，經(jīng)常會成為爭論的焦點。我們先看下面一段引用的文章：216。 業(yè)務(wù)服務(wù)如果是是否存在可重用的原子服務(wù)，如果有則應(yīng)該先做原子服務(wù)再做組合服務(wù)。216。 原子服務(wù)存在的意義在于存在多個業(yè)務(wù)服務(wù)復(fù)用，如果不存在不識別為原子服務(wù)。216。 從業(yè)務(wù)出發(fā)，為了保證事物完整性和服務(wù)設(shè)計的無狀態(tài)原則，應(yīng)該如何設(shè)計，哪些能拆，哪些不能拆。216。 根據(jù)BPEL流程編排，會增加業(yè)務(wù)校驗類細(xì)粒度服務(wù)，應(yīng)從滿足多個業(yè)務(wù)編排需求來考慮可重用性。216。 根據(jù)安全性原則，哪些服務(wù)需要拆分，根據(jù)拆分服務(wù)提供不同屬性類別的服務(wù)216。 根據(jù)性能原則，哪些粗粒度服務(wù)當(dāng)不滿足性能測試要求時候需要拆分為多個細(xì)粒度的服務(wù)什么是服務(wù)的顆粒度？一般的說法，服務(wù)顆粒度（service granularity）就是指一個服務(wù)包含的功能大小。舉個例子，對于電信九七系統(tǒng)中的營業(yè)受理來說，提交客戶訂單就是一個典型的粗粒度的服務(wù)，而實現(xiàn) 這個提交訂單服務(wù)的一系列內(nèi)部操作，比如說創(chuàng)建客戶資料，生成客戶訂單，記錄產(chǎn)品屬性，更新帳務(wù)關(guān)系等等就可能成為一系列細(xì)粒度的服務(wù)。細(xì)粒度的服務(wù) （finegrained）提供相對較小的功能單元，或交換少量的數(shù)據(jù)。完成復(fù)雜的業(yè)務(wù)邏輯往往需要編排大量這種細(xì)粒度的服務(wù)，通過多次的服務(wù)請求交互 才能實現(xiàn)。相反，粗粒度的服務(wù)（coarsegrained）則是在一個抽象的接口中封裝了大塊的業(yè)務(wù)/技術(shù)能力，減少服務(wù)請求交互的次數(shù)，但相應(yīng)也會 帶來服務(wù)實現(xiàn)的復(fù)雜性，交互大量的數(shù)據(jù)，并因此而不能靈活更改以適應(yīng)需求的變化。就像任何事物都有兩面性一樣，服務(wù)粒度不能太大或者太小，而應(yīng)該大小合 適。一個良好的SOA架構(gòu)設(shè)計，必須在服務(wù)粒度設(shè)計上維護(hù)一種平衡，以獲得成本降低，靈活響應(yīng)的好處。盡管沒有一本Bible讓我們可以依此正確地設(shè)計服務(wù)的粒度，但我們還是能從與之相關(guān)的多方面利弊權(quán)衡的設(shè)計實踐中，總結(jié)出一些能夠幫助正確選擇服務(wù)顆粒度的經(jīng)驗法則。識別并設(shè)計一個粒度適中的服務(wù)，我們可以主要從以下三個方面權(quán)衡考量?！　 重用性所謂重用性，就是指服務(wù)能夠應(yīng)用于不同上下文的能力。重用可以說是SOA的核心思維，通過重用獲得降低開發(fā)維護(hù)成本，縮短應(yīng)用交付周期，提升質(zhì)量等種種好處。與任何基于分解的范例相一致，顆粒度的大小直接影響到服務(wù)的可重用性。一個簡單的經(jīng)驗法則就是細(xì)粒度的服務(wù)更容易被重用。換句話說，就是顆粒度越粗，服務(wù) 越少被重用或者越難以被重用。因為隨著顆粒度增加，越來越多的業(yè)務(wù)規(guī)則和上下文信息被嵌入到業(yè)務(wù)邏輯中，服務(wù)逐漸變得具有特定的業(yè)務(wù)意義。要使用它，我們 必須首先了解它到底封裝了哪些規(guī)則，否則我們無法確信這個服務(wù)正是我們所需要的。這并不意味著我們就不要構(gòu)建粗粒度的服務(wù)，事實上粗粒度的服務(wù)往往還停留 在”businessgrained”層面，它讓業(yè)務(wù)用戶和