松散耦合的SOA需要保持差異性嗎？

在SOA的所有核心原則之中，大概最基礎的就是服務提供者和消費者之間的松散耦合關系。

SOA的核心靈活性和重用優越性依賴于服務提供者和消費者在用于描述交互的服務合同條款框架內各自獨立運作的能力，并且對于一個特定的SOA來說，至關重要的是不能為其能力和行為加入非必要的要求或限制，因為無論是服務提供者和消費者都可能隨時間而改變。

無差異性原則對于松散耦合的需求來說是十分必要的。畢竟，一個服務要通過消息傳遞為軟件提供接口。不存在一種與對象實例類似的服務實例的表示方式;相反地，服務只是簡單的停在那里，和他的每個訪問者通信。更具體的講，既然SOA包括了獨立實體之間通過服務耦合進行的互操作，我們只需要在服務之間傳遞消息和數據就可以了。這些松耦合的、異構的、復合的應用程序要求所有的服務必須是無差異性的，以保證他們不會將自己的系統或進程地信息暴露給外部從而增加了系統的耦合度，那會導致可重用性和可用性的下降。

將不同服務組和在一起的原因是要實現商務流程，而這些流程必定是有差異性的，畢竟，一個進程的不同實例可能處在不同的狀態。于是如何利用無差異的服務實現有差異的事務邏輯就變成了十分重要的挑戰。如果實現方式不對將會失掉由無差異的服務帶來的松耦合的好處。

在SOA中維護差異性信息

Wikipedia 是這樣定義“差異性”的:這樣的差異性保留了過去的信息，如一個用戶記錄或購買事務，并且差異性反映了系統從起始到當前時間的所有變化過程。在這個“差異性”定義的基礎上，出現了許多關于另一個概念“計算”的定義:從一個狀態到另一個狀態的轉變以及他們之間轉換發生的條件。對于一個進程來說，差異是十分重要的，因為如果沒有差異性，我們的系統將沒有任何歷史可供積累。實際上，我們開發的大部分系統，要么是記憶差異，要么對差異進行操作。進一步來說，各個公司都需要之前的狀態來從某種錯誤的更新狀態中恢復。最要緊的是沒有前一步的狀態記錄，我們做到任何的可靠交易，因為無法在發生問題的時候進行回退。

因此，既然差異性對于一個信息系統如此之重要，那么為什么不把差異性的表示和維護功能包含在SOA中呢?回答這個問題的關鍵，在于充分了解差異性信息在一個松耦合的系統中是需要被共享還是獨立在各個服務中。

松散的耦合是否意味著不需要差異性

松散耦合使得SOA具有很高的效率。這就是說，SOA增加了靈活性，并使得一些互不干擾地各自運行的服務能夠盡可能多被重用，所以，就不會在服務用戶的行為和能力上強加一些不必要的需求和限制。在這種情況下，特定服務活動的差異性概念就應該在服務內部保持而不應該暴露給使用服務的客戶，這將變得很有意義，因為這樣當差異性萬一需要發生變化的時候，就不需要讓所有的服務用戶來操作這種變化。更具體的來說，因為SOA包括了組成服務的實體之間的合作，所以就僅僅需要把消息和數據從一個服務傳遞到下一個服務，這樣帶來的缺點則是所有的服務將需要保存各自的狀態。

然而，即使在SOA的環境之中，為了獲得那些跨組織或者跨公司的長期運行的進程信息，仍然應該在每個獨立的服務實現之外保持差異性的值。而且，一些進程需要保留多個服務的現場，為了這些進程的性質的要求，同時也為了安全、管理等目的，一些差異性的表現也是必需的。

用沒有差異的服務保持有差異的系統

沒有差異性的web表現出同樣的問題，這些web必須保存一些跨越多個web的session，而每個web都不會獨自保存狀態?；旧嫌袃煞N方法可以在web上保存差異:一種是在瀏覽器中存儲一個擁有多個交互信息的cookie，另一種是在服務器上以某種方式跟蹤差異，可以用網絡的普通協議來交換保存的session信息的方式來實現這種跟蹤。

使用Cookie保存差異只有在web上才適用，因為它們本身就是HTTP的結構，而HTTP是Web最基礎的協議，每個瀏覽器都支持它。但是，當涉及到服務的時候，需要考慮系統到系統的通信，因為不可能所有的用戶都是瀏覽器，或者更一般來說，都支持某種特定的協議。這就使得只有消息能夠在SOA環境下保存差異性。

本質上，跨多服務的保存差異性是有可能的，這種保存可以通過對每個服務消息打上某種持久的標記來實現。而這種標記將代表一種跨越多服務交互活動的持久狀態，表現良好的服務會把這種標記以混合的方式不加刪改地傳遞到其他的服務，這種傳遞會通過管理這些服務的協議來進行。通過這種方式，個體服務仍然是沒有差異性的，但是消息能夠保存那些特殊服務的組件所需要的差異性。

這種基于消息的差異性保存方法回避了問題的本質，那就是到底要怎樣來管理服務組件代表的進程。傳統的BPM(業務處理管理)工具利用了代表所有運行進程的運行時組件引擎，而這些引擎保存了差異性。這種方法的優點是它提供了對運行進程的可見性并保存了相關服務的差異性。

然而，這種方法有一些嚴重的問題:第一，一個核心進程的運行環境僅僅能給服務可見的服務和服務組件提供差異性的保存。一旦服務的請求超出了系統的邊界，進程工具將不再能夠控制進程。第二，進程的活力性依賴于進程工具的活力性——如果工具崩潰并丟失了信息狀態，那么就沒有方法來恢復進程實例。但是也許這還不是最嚴重的事情，因為核心進程的運行環境降低了松散耦合的性質會導致所有的服務提供者和用戶都必須通過進程服從核心工具的控制。

此外，這里已經完成的是把BPM和面向服務的BPM分開，這種面向服務的BPM建立在差異管理的基礎之上。一種理解這種區別的方法是在練習時嘗試“去掉服務器”。當一個核心BPM工具停止時，正在運行的進程將會出現什么情況?因為核心工具控制了所有的進程邏輯，包括差異性邏輯，因此停止工具其實就意味著所有進程的終止，這經常是不可恢復的。

解決這些問題就必須要用面向服務的方式保存進程的差異性。也就是說，通過約定的服務提供差異管理，這些服務的目的就是為進程實例保存差異性。本質上，這種方法把消息當作事件來處理，差異保存服務能夠對這些事件審計，記錄日志，并在以后根據這些記錄分析決定給定的差異。這種方法認為差異性是運行系統潛在的缺點而不是運行進程環境應該保存的一些必需信息。這種事件驅動的、面向服務的方法跟蹤所有相關的事件，并且有一個單獨的服務集合來分析事件流并執行專門的過程，這些活動是基于進程的需求，政策以及服務的協議等。

現在，當進程管理的服務集合停止以后會發生什么呢?因為服務提供者和用戶交互的消息包含了持久地標識，這些標識代表了進程的差異性，所以進程的信息將不會丟失。相反，發送到進程管理服務的消息被放進一個隊列，等待服務恢復再處理。一旦服務被恢復，則可以繼續執行它沒有處理完的進程邏輯，因為隊列中的消息能夠提供它需要的關于當前進程差異的所有信息。

從一個設計師的角度來看，在面向服務的設計中考慮差異性是十分有必要的。服務除非它是差異性管理服務且在特別要求這樣做時一般自己不保留差異信息。就算這樣做時，它們也管理那些暴露給差異性管理服務的進程。在任何情況下不會有一個服務管理自己的差異性信息，因為一個服務消費者通常自己知道一個服務的內部狀態便于確定是否給服務發送消息。如果那樣的話會破化SOA中松散關系和封裝原則。

有效率的公司設計師已經認識到，就如所有有關SOA的文章中所闡述的，好的設計隨協議而改變。也就是說，雖然差異性無關是一個獨立的服務通過松散連接獲得靈活性的必要條件，狀態無關也是商業程序為獲得商業目的而需要的條件，所以這種手段是一種平衡來用于它們在采用面向服務設計方法的共同需要。

(責任編輯：銘銘 mingming_ky@126.com TEL：（010）68476636)