無(wú)論如何，松散的耦合不僅僅意味滿(mǎn)足不同用戶(hù)的不同需要，它還意味著(zhù)變更的創(chuàng )建。因為我們有適當的操作、管理的基礎架構，這使得抽象服務(wù)、抽象接口、抽象技術(shù)實(shí)現中可以建立多對多對多關(guān)系，在松散耦合方式中我們能夠對那些需求修改等變更做出反應，換句話(huà)說(shuō)，不需要破壞任何事物。
例如，如果一個(gè)消費者修改了必需的數據格式，我們能提出一個(gè)新的合同文本，這也許需要服務(wù)接口和抽象服務(wù)之間媒介的一個(gè)新轉換，但是不會(huì )直接影響服務(wù)接口或任何一個(gè)服務(wù)技術(shù)實(shí)現。另一個(gè)例子是需要升級或增加一個(gè)新的數據源來(lái)支持服務(wù)。這樣的變更可能需要一個(gè)或多個(gè)服務(wù)接口的一個(gè)新的技術(shù)實(shí)現。但是如果那些接口的合同文本沒(méi)有變化，那么抽象服務(wù)就不受影響，消費者也就不受影響。第三個(gè)例子是決策升級，這將改變服務(wù)接口和他們的技術(shù)實(shí)現間的基于上下文的路由行為。實(shí)際上，我們將這個(gè)基于上下文的路由應用視作管理變更而不是集成作業(yè)，因為這需要支持運行時(shí)間決策變更。
ZapThink的收獲
用這種面向服務(wù)方法去技術(shù)實(shí)現抽象服務(wù)時(shí)，有一個(gè)引人注目的副作用：計算你有多少服務(wù)變得困難。當然，在這個(gè)例子中，從交易的角度來(lái)看你有一個(gè)顧客信息服務(wù)，但是實(shí)際上它可能有很多個(gè)服務(wù)合同文本，每個(gè)合同文本都有幾個(gè)接口——并且隨著(zhù)時(shí)間流逝，那些接口的數量會(huì )發(fā)生變化。你怎么計算服務(wù)可能影響你的SOA成熟模型，甚至影響諸如你的軟件許可成本等，因此這個(gè)問(wèn)題遠比它看上去的重要得多。
歸根結底，最重要的事是記住顧客信息抽象服務(wù)只是一個(gè)簡(jiǎn)單的例子。在一般情況下，必須依據手頭問(wèn)題的特殊性，從多種SOA框架模式中挑選一個(gè)架構，正如我們近期的ZapFlash SOA基礎框架模式和媒介方法所解釋的。概括地說(shuō)是松散耦合提出的架構挑戰，這種挑戰是計劃和技術(shù)實(shí)現SOA基礎框架的核心。構造服務(wù)抽象概念提出了一個(gè)交易的單一化表示法，但是需要深層次的額外的努力以使抽象概念成為一個(gè)具體的客觀(guān)存在。這是SOA的工作：實(shí)現和維護松散耦合的交易服務(wù)是任何SOA技術(shù)實(shí)現成功的關(guān)鍵。
聯(lián)系客服
