怎樣構建正確服務組合

申請免費試用、咨詢電話：400-8352-114

對于那些一直關注于XML，Web services和面向服務技術的分析師們，他們備受鼓舞的看到聽眾，包括用戶，供應商，以及咨詢公司，都在問一些關于如何正確的建立構架的更加復雜而深入的問題。這一切看起來似乎是我們已經通過了低谷，并且我們的架構師已經有了關于什么是SOA和為什么他們需要它的一些好的想法。

不再試著重新定義SOA是什么和它對于商業(yè)是什么意義，人們反而關注于如何正確的使用SOA這些更加重要的問題上。在那些方面，我們最近的一些對話都集中于如何構建"正確的" 服務。關于這個問題的一個關鍵答案是確信我們構建的服務是以合適的粒度水平。

粒度是一個關于一個功能的需求模塊必須以什么樣的規(guī)模來滿足即將到來的需求。組織細致的服務滿足小單位的功能或者少量的數(shù)據(jù)。因此，為了構建復雜的商業(yè)過程，公司需要編排大量的類似的服務來有效的使這個過程自動操作，而這個處理過程是很困難的，通常是需要付出巨大努力的任務。粗糙組織的服務，盡管在一個單獨的抽象接口中封裝了大量的能力，減少了必須的服務請求的數(shù)目來完成一個任務，但是從不好的一面來說，這樣就會返回過多的數(shù)據(jù)，或者很難再修改他們來滿足不斷變化的商業(yè)需求。這個選擇的平衡，當然也是面向服務架構的一部分。

什么可以組成一個良好定義的服務?

在試圖明白如何來劃分適合粒度的服務的時候，第一個問題就是需要明白一個良好定義的服務接口必須是什么樣的。一些人可能認為你所需要的就是正確的標準，然后你將會有一個良好定義的服務接口。從本質上而言，可以說良好定義的接口是一些可以被電腦理解的東西。盡管如此， 你使用哪個具體的標準來定義一個服務接口并不重要，只要它為松耦合提供足夠的信息。

在一個SOA 中，我們的確更傾向于基于標準的交換，而不是非標準的交換，并且這似乎看起來WS-*概念棧的好的部分(特別的是 WSDL, XML Schema, WS-Security, WS-Policy,以及可能的 BPEL或者 WS-CDL)正在廣泛的受到人們的接受。盡管在機器可理解的標準中有一些元數(shù)據(jù)契約是好的，但是如果簡單的讓這些規(guī)范對于用戶來說是可以獲得的，這樣并不能為如何定義服務接口和解決粒度挑戰(zhàn)的問題提供任何的線索。確定的，很重要的是一個電腦能夠理解一個提供的服務，但是這并不能使得一個服務有價值。實際上，其他的一些形式的架構也依賴于基于標準的接口，并且也沒有產生我們所希望的松耦合的服務。在這一點，我們必須去掉我們的開發(fā)者的帽子，把我們的架構放上。

在我們最近的ZapFlash確定了一個服務契約有那些東西，我們討論的事實是一個服務算不上服務，除非它是使用一個元數(shù)據(jù)編碼的契約定義的。這個契約必須包含兩個關鍵元素：規(guī)定了服務消費者和提供者兩端的功能性和非功能性信息。在這種情況下，至少的 ，一個服務七月必須提供關于服務會做什么的明確的信息。還一句話說，一個服務必須清楚的說出它是意味著什么，并且它說了的意味著什么。用戶不應該被留下來抓腦袋想在要求的輸入被提供之后將會發(fā)生什么。

所以，一個關于良定義的服務的更好的爭論是一個服務是良定義的應該不只是意味著它只是可以被一個電腦理解的，而是要和服務所承諾提供的要完全的一致?；镜兀粋€人也可以理解這個服務契約，而不需要咨詢額外的資源或信息。

現(xiàn)在，這個關于明確性的需求也逐漸的被松耦合的系統(tǒng)所要求了。通過一些東西，我們稱之為架構的可以把這個明確的要求完成并且把服務的內部工作提供出來，或者可能提供具體的如何一個商業(yè)過程被組成的細節(jié)。盡管如此，為了讓松耦合的系統(tǒng)工作， 我們可以知道一些關于服務是如何工作的或者關于組裝的過程，從而能夠完成任務。即便這樣，我們也許會有在與語義緊耦合的協(xié)作稱之為可操作的松耦合。換一句話來說，我們需要了解服務將會做什么，同時也要知道它將會怎樣通訊以使得它是有用的。從而，第一個挑戰(zhàn)是構建一個夠具體細致的服務契約元數(shù)據(jù)，但是不要太多的細節(jié)。

聚焦復用

我們仍然還沒有回答那個問題及如何來決定服務的粒度的水平，盡管最后，我們可以構建良好組織的，良定義的服務和粗糙組織，良定義服務。很重要的是要知道一個特定的服務是否是單獨使用的還是多用途的。你可以說最好的服務是最有用的一個，這是事實，恰到要點。畢竟具有怎么多的冗余，良好組織的服務導致了大量的開銷和低效率。很明顯的具有更小的可用的粗糙組織的服務的集合在很多情況下都是一個更好的選擇。盡管如此，很多開發(fā)者會把這條準則推向一個極端，并試圖構建一個單獨的服務，稱之為，或者說，"做一些東西"是可以滿足每一個單獨得需求的。做某些東西將可以具有能夠支持一些任意服務功能需求的一個簡單接口，并且它將會產生一個相應的服務結果。

這個能做某些事情的服務的問題對于任何曾經試圖實現(xiàn)這樣的東西的人來說都是很明顯的。從本質上來看，它不再是以惡可以使用的服務了，因為我們已經基本上只是把責任推給別人了，而不是讓服務自己來決定自己的語義。我們只是把決定推延到更低水平的代碼塊上去了。本質上，我們只是把SOA看成某種類型的路由協(xié)議或者消息系統(tǒng)而不具有任何的固有的功能。這樣的服務，明顯的不能滿足SOA的需求。

所以，如果通用目的的服務是一個轉移注意力的問題，那么單獨目的服務呢?這個問題的答案有一點拖拽。一些單目的的服務，盡管他們可能是非常良好組織的，并且只是完成特定的任務，但是他們可能異常的容易復用。那就是說，架構師也許能夠把這些服務組裝起來，從而能夠滿足很多情況的使用。相反的，可能面向領域的服務可能只能應用于特定的情況，但是事實是他們是特定于問題或者問題集合的，這正是使得他們對于商業(yè)是有價值的。并且這也是我們找到的關于試圖解決服務粒度問題的第一個線索：不要關注與一個單獨的服務，而是應該著眼于整個商業(yè)處理過程和在商業(yè)中服務是怎樣滿足多處理的需求的。 一個公司越能讓一個服務來完成更多的服務，那么這個服務也就越有用。對應的，如果可以調整一個服務在多個不同的處理中使用，那么需要知道的是它是否是在合適水平的粒度。

分解處理的角色

服務不是一格真正的技術概念，它只是商業(yè)想要從它的技術中獲得他們的價值的一種抽象表示。同樣的，我們應該關注于如何從商業(yè)的角度來定義服務--這就是說，從商業(yè)處理的角度來看，因為商業(yè)處理根本的定義了商業(yè)。

一個具體實現(xiàn)正確的服務的途徑是：以某種商業(yè)過程為開始，然后把它分解成為遞增的更小的處理子過程，直到你不能再作進一步的分解了。這些分解出來的子過程就變成了那些實現(xiàn)系統(tǒng)的候選服務。如果一個公司越多的把商業(yè)過程以這種方式分解，他們就越能看到子過程之間的公共性，從而能夠有機會構建一個合適的可服用服務集合。

盡管如此，這種由上而下的過程分解方法有一個致命的弱點，那就是我們最后可能定義了一些不可能或者不夠實際來實現(xiàn)的服務。從而，很重要的是同時經過現(xiàn)有商業(yè)邏輯的練習，就是基于代碼級別的而不是元數(shù)據(jù)，并把它作為服務提供出來，這些服務將會作為具體的而不是全部的商業(yè)處理的候選服務，而不是采用實現(xiàn)處理的機制。這將跨越兩個服務種類：在多處理之間的可服用的商業(yè)功能性服務和可以在組織內部為不同的服務提供值的良好組織功能性服務。

ZapThin建議

通過這種服務定義訓練的公司應該保證不要陷入這種常見的現(xiàn)象，致命的思維缺陷是認為一旦定義了他們的服務，就完成任務了。SOA，天生就需要不斷的發(fā)展，即使公司開展的服務對于一段時間的商業(yè)是完美無缺的，但是商業(yè)會連續(xù)經歷持續(xù)的變化，就需要新的服務以及新的公司服務。那些在一些時候還有剛好合適水平的粒度的服務，也許僅僅幾周之后就會變得不適合了。

結果，把服務的粒度水平轉化為特定的形式是沒有意義的。公司必須不斷的重復他們的服務設計，在一個粒度范圍內構建良好定義的服務接口，然后當這些服務是合適的時候，就可以發(fā)布和使用這些服務了。面向服務架構將花他們相當多的時間把服務接口集合在一起，從而在及時地提供了足夠多的關于他們商業(yè)的知識，他們可以實現(xiàn)在良好粒度同粗粒度組合以及單獨目標同多用途之間的最優(yōu)組合。

結果，開發(fā)者和建筑師們會抵制這種得到正確服務的激勵。實際上，使他正確并不是那么重要，因為今天正確的明天或許就是完全錯誤的。畢竟，建立服務并不是SOA的目標--它正在構建一個架構，這個架構允許商業(yè)持續(xù)的改進他們的為商業(yè)所需要的有用服務的集合，并且能夠調整不斷進行的變化。建設這種有用的服務是為了打破多用途和特殊領域的服務以及過度的定義和過多的不明確服務分界之間的平衡。這里沒有固定的和已成定局的答案來說明哪些服務該針對特殊的公司，但是這里顯然有更好的途徑來是那些服務成為現(xiàn)實。刺激和獎勵在商業(yè)中正在進行的爭論將能夠使得SOA對商業(yè)更有用，從而更值得去不斷的書寫和談論。(techtarget)