怎樣構(gòu)建正確服務(wù)組合

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

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

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

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

什么可以組成一個(gè)良好定義的服務(wù)?

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

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

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

所以，一個(gè)關(guān)于良定義的服務(wù)的更好的爭(zhēng)論是一個(gè)服務(wù)是良定義的應(yīng)該不只是意味著它只是可以被一個(gè)電腦理解的，而是要和服務(wù)所承諾提供的要完全的一致。基本地，一個(gè)人也可以理解這個(gè)服務(wù)契約，而不需要咨詢額外的資源或信息。

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

聚焦復(fù)用

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

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

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

分解處理的角色

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

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

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

ZapThin建議

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

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

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