當我們所做的系統(tǒng)到一定的程度后，隨著涉及的領域越來越寬泛，客戶群也越來越多，我們的系統(tǒng)不得不需要第三方系統(tǒng)協(xié)作，或者將原有大系統(tǒng)分解成各個協(xié)作的小系統(tǒng)才能更好地完成任務。就好像KFC，收銀員就負責客戶端點餐、收銀、找零錢、開發(fā)票是一個接待人員完成。而真正為您做餐的又分為比較復雜的分工，比如負責炸薯條的人、做漢堡的人、還有做蓋飯的（KFC的蓋飯，唉~~不說了）。而為這些做餐人員提供物料供給的又是另一些人。還有就是KFC外賣送，店員管理經(jīng)理，是這些人撐起了一個KFC店面。每個人負責的分工都不一樣，每個部門人員的分工都和別的部門人員的分工有交互才能完成客戶整個的“吃飯”需求。當然了，KFC還提供了洗手間，里面有專門的保潔人員。

從實例看我們IT界吵了這么多年的SOA吧，說通俗了，他就是想讓大型的軟件系統(tǒng)像KFC這種提供服務類似，內部是各個小系統(tǒng)（相對于整個大系統(tǒng)來說的，有可能這里面每個小系統(tǒng)的規(guī)模都是十分大的），有可能內部員工來自于不同的國家，他們之間都使用統(tǒng)一的標準語言——英語進行交流。

Java的分布式系統(tǒng)一般都會遇到異構系統(tǒng)之間的交互，而且這些異構系統(tǒng)99.9%都是在不同物理位置的，需要網(wǎng)絡進行通訊，互協(xié)作。也就是說當系統(tǒng)一大了，就要面臨將群雄割據(jù)的系統(tǒng)逐一馴化，使之Java分布之系統(tǒng)為我輩所用。

問題

SOA讓不同的系統(tǒng)之間使用標準的規(guī)范進行通訊，而每個系統(tǒng)暴露出來的功能，SOA稱之為“服務”（Service），為客戶服務得到位不到位，全看整個大系統(tǒng)運作流不流暢。系統(tǒng)之間沒有SOA規(guī)范之前可能也進行過整合，協(xié)作，但是那個時候沒有一個標準的規(guī)范限制住通訊的協(xié)議，那么造成一個現(xiàn)象就是：系統(tǒng)A與系統(tǒng)B進行因為不同語言，要進行協(xié)作使用的是WebService，而系統(tǒng)B與系統(tǒng)C因為大多數(shù)功能都是用Java實現(xiàn)的，他們之間可能出于同語言的原因，使用JMS進行通訊協(xié)作就夠了。而過些時間又出來一個系統(tǒng)D，需要系統(tǒng)A與系統(tǒng)C同時與之協(xié)作才能完成一個復雜的業(yè)務邏輯了，怎么辦？有可能同語言，采用更為古老的RMI，有可能直接寫個socket通訊就OK。

基于以上的各種現(xiàn)象不同系統(tǒng)之間是采用不同的通訊技術或者說通訊規(guī)范的，那么就要求開發(fā)這個大系統(tǒng)的每個人都得需要了解其他很多種通訊規(guī)范，針對不同的協(xié)作系統(tǒng)的更改，進行相應的修改。這樣就好比KFC的員工都說自己國家的語言，想和我交流嗎，OK，先學學我們國家的語言咱們再交流。難道客戶在柜臺那邊等著你們將員工內部所有的國語都學了個遍，交流順暢了再要吃的？？客戶說算了，還是“更多快樂，更多歡笑盡在麥當勞吧。要不早餓死了……”

所以說不同系統(tǒng)，尤其是異構的系統(tǒng)之間采用一個標準的協(xié)議進行規(guī)范，大家都按照這個標準規(guī)范來，以上各自為政的現(xiàn)象就能夠得以解決。

SOA規(guī)范的要求

SOA的規(guī)范要達到的要求主要有以下幾點：

統(tǒng)一的交互方式：這個目標就是解決上面異構系統(tǒng)之間的通訊問題

服務品質：也叫做QoS，包括了通訊的安全，可靠的訪問。每個服務能支撐的訪問量是有限的，流量控制，機器資源負載分配等等措施都是保證服務質量的。

依賴管理：大系統(tǒng)內部往往是小系統(tǒng)之間的耦合工作來完成，那么系統(tǒng)和系統(tǒng)間少不了就要產(chǎn)生耦合，或者說是依賴。那么SOA就需要有解系統(tǒng)間耦合的規(guī)定，不能讓不同系統(tǒng)強制耦合在一起。

高性能，高可用：協(xié)作的系統(tǒng)，當然要性能過關，客戶用著用著說，怎么報出Exception了，或者說“系統(tǒng)正在維護，請耐心等待”？就好像客戶在KFC吃漢堡包吃出了……（不說了），那么這客戶下次肯定不來KFC了，而且還向他的朋友說KFC怎么怎么樣……

與其說SOA提出這些規(guī)范，不如說SOA提出了這些目標。實現(xiàn)了這些目標，那么至少說您的大系統(tǒng)、大軟件是符合SOA規(guī)范的。

實現(xiàn)SOA規(guī)范的，可參考的標準有SCA和ESB。

SOA實現(xiàn)

首先大家不要誤會，SCA和ESB不是2個對立的東東，他們不是麥當勞和肯德基，他們的關系類似于JPA規(guī)范和Hibernate實現(xiàn)之間的關系。ESB更像是個抽象的概念，而SCA是一個面向應用的編程和組裝方式。使用SCA，開發(fā)人員基本不用考慮技術接口, 代碼是純業(yè)務邏輯。

SCA的發(fā)布服務：

SCA為了減少對現(xiàn)有系統(tǒng)的入侵，將現(xiàn)有系統(tǒng)的服務類抽象成接口，當然如果原先就是接口+實現(xiàn)類就更方便了。通過SCA配置默認將系統(tǒng)接口暴露成為SCA服務。至于具體的配置文件格式和相關實現(xiàn)類的配置Demo在此先暫時放一放。

SCA的調用服務：

調用服務的方式可以采用xml配置實現(xiàn)，借助Spring集成相關SCA框架的整合可以很方便的使用SCA服務完成自己的業(yè)務。這個有點類似Spring集成CXF，這個內容在此也先不介紹。

SCA支持的通信及其交互方式：

SCA規(guī)范規(guī)定通訊方式有3種方式，JMS、WebService、跟情況而定，如果應用處于同一JVM采用JMS，不同則采用WebService。當然了，通過擴展SCA也可以支持其他通訊方式。

對于系統(tǒng)間的依賴管理SCA并沒做太多解決的規(guī)范，而調試跟蹤也沒提出具體規(guī)定性的方案。這當然取決于具體的SCA實現(xiàn)框架，或者借助其他開源工具，比如Maven、TestNG整合等等手工措施待見屬于你們公司自己的基于SOA思想的SCA平臺。

ESB和SCA不是競爭關系，ESB算是提出一些基于SOA理念的一些抽象概念，核心思想是基于消息中間件來實現(xiàn)系統(tǒng)之間的交互，將系統(tǒng)要通訊的消息動作放到一個統(tǒng)一的尋呼臺（消息中間件），處理消息隊列的時候，消息自身帶著目的信息，之后就發(fā)送過去，完成業(yè)務邏輯，就相當于麥當勞有個中央總控，所有人都有一個隨身攜帶著的尋呼機，客戶來了買餐，前臺打開尋呼機往中央尋呼臺發(fā)送一條消息：“客人點餐，兒童套餐”，發(fā)送完畢后，中央尋呼機將此消息發(fā)給了后廚，后廚趕緊炸薯條，烤面胚，微波爐熱牛肉。一切皆由消息總線進行任務分發(fā)。

其實ESB相當于承擔了SOA提出的統(tǒng)一服務方式進行交互。

ESB框架需要具備以下功能：

標準通訊格式：方便系統(tǒng)間進行通訊

消息路由：根據(jù)消息的目的地將消息發(fā)送至消息目的地，整合分系統(tǒng)統(tǒng)一成完整大系統(tǒng)，這點BPEL做得十分到位。

支持消息的請求相應、訂閱分發(fā)2種模式進行。

支持多網(wǎng)絡協(xié)議：http、TCP、UDP

解決多種數(shù)據(jù)格式進行交換，數(shù)據(jù)間的請求數(shù)據(jù)格式有可能存在差異，消息總線要屏蔽這種差異。

綜上所述，實現(xiàn)JMS規(guī)范的各種消息中間件，怎么看怎么和ESB所提出的規(guī)范相吻合。

總結

這次介紹了相應的分布式系統(tǒng)的特點和SOA提出來的目的，做大型企業(yè)分布式系統(tǒng)，利用SOA進行系統(tǒng)整合、一統(tǒng)的意義。當然這次僅僅是抽象概念的一些介紹。之后會有相關內容作為其SCA規(guī)范、ESB規(guī)范的具體代碼實現(xiàn)的。

SOA已經(jīng)不是什么新鮮詞語了，筆者的感覺現(xiàn)在搞軟件研發(fā)越來越像服務行業(yè)了，面對客戶，面對客戶的客戶，我們只有提升自己的服務質量，才能營造更好的品牌效益。還是那句老話，任何技術的推動背后都是商業(yè)運作。