SOA 架構中的ESB是更好的應用於異構系統整合整合還是用於統一服務呼叫/基礎服務實施

魏瓊東發表於2013-10-18

一、討論主題與觀點

      寫一篇文章、發現一次自覺得有意思的SOA架構方面的討論,源於昨天AgileEAS.NET SOA 平臺群(113723486)裡幾個群友的一次關於ESB的一次討論。

      大家的討論觀點主要整合在:對於ESB的定義也有類觀點,一類觀點是把ESB定位於SOA架構之中的基礎服務設施(書上都這麼講),還有一類觀點就是ESB做為異構系統之間的整合和整合之間,其實ESB本身都能實現兩種觀點的功能,只是覺得在時下,應該更偏重於那一方面,兩者的本質上最大的區別是,同一系統內部的功能是否需要經過ESB進行呼叫。

      ESB是SOA架構的基礎服務設施的觀點,我們可以用買下圖來表示:

image_thumb[9]

      這個圖應該是最符合SOA架構和ESB的一些書籍之間的ESB架構圖,我們可以簡單的解釋一上,即史是A系統呼叫A系統的服務,也必須經過ESB系統,那麼有ESB系統的規劃和建設就是一個必須早期考慮的問題,即我們必須先建立SOA的基礎架構和ESB體系,並且在這個架構上面開發A系統、B系統、C系統,這是一種觀點,那麼在目前我們國內,政府、企業領導應答是很喜歡這樣的結構的,統一規劃、場面巨集大,這裡面就出現一個問題,整體系統被規劃的非常完美,但是實際上這更好像一個用遠也不能完全的夢(永遠都沒有完美的東西),實現成本就不可估量

      ESB最好是做為異構系統之間的整合整合之用,我們可以用買下圖來表示:

image_thumb[12]

      這個觀點是我的觀點為,即我認識這是一種比較現實和比較經濟的觀點,ESB用被做於異構系統之間的整合,他是支援異構系統的整合的基礎設施,而不是基於統計規劃下的基礎服務設施,基於這個觀點的原因是,企業內部各種各樣的系統不可能全部推翻了,全部規劃和重來,很多企業的供應商在某一領域也做的很專業,博眾家之長並進行整合應該是一個比較現實和可取的做法,一個系統一個系統穩定有序的實現,應該是比全部重新規劃具體更小的風險

二、聊天記錄摘抄

金靚(123140395) 13:40:58
大家好
金靚(123140395) 13:41:34
想做服務的統一呼叫
也就是說所有的業務系統都走服務匯流排
通過匯流排來進行業務服務的呼叫

簡單的訊息交換模式沒問題
請求/響應
但是雙向交換模式下如何實現呢
何戈州<hotdefans@qq.com> 13:52:15
雙工嗎?
金靚(123140395) 13:52:23
對的
何戈州<hotdefans@qq.com> 13:52:36
那也沒問題

 

金靚(123140395) 13:52:57
能否給點思路
何戈州<hotdefans@qq.com> 13:53:05
socket 問老魏
金靚(123140395) 13:53:14
基於WCF

魏瓊東(47920381) 14:19:02
@納尼 雙工模式貌似ESB實現不了吧。

納尼(123140395) 14:19:27
BIZTALK裡也不能嗎

納尼(123140395) 14:19:48
@魏瓊東 貌似可以的

魏瓊東(47920381) 14:21:06
但是全雙工的通論,讓ESB通知應用這事難了點

納尼(123140395) 14:21:23
所以我有點鬱悶
納尼(123140395) 14:21:41
其實本來沒去設計雙向通訊
魏瓊東(47920381) 14:21:46
實現全雙方都是socket吧
魏瓊東(47920381) 14:22:10
除非用ESB回撥某個系統的服務
納尼(123140395) 14:22:27
對的
魏瓊東(47920381) 14:22:32
即應用掉用===》ESB===》應用的服務
魏瓊東(47920381) 14:22:40
那你說的是ESB的服務路由了

納尼(123140395) 15:35:20
雖然沒有什麼含量,而且是在H.O.T指導下才弄明白的,但還是應該分享一下給大家

納尼(123140395) 15:36:06
剛才我說的那個客戶端需要呼叫服務實現雙向通訊,基於ESB
納尼(123140395) 15:36:52
ESB提供雙向介面服務

納尼(123140395) 15:37:54
其實我想做的ESB,要實現服務的統一呼叫
納尼(123140395) 15:38:09
所有的客戶端都通過ESB來呼叫業務服務


納尼(123140395) 15:38:39
這樣的話,勢必需要ESB對客戶端公開的介面都要相對穩定
納尼(123140395) 15:38:47
自己要做

納尼(123140395) 15:39:24
也就是說A->ESB->B->ESB->A

納尼(123140395) 15:38:39
這樣的話,勢必需要ESB對客戶端公開的介面都要相對穩定
納尼(123140395) 15:38:47
自己要做


納尼(123140395) 15:39:24
也就是說A->ESB->B->ESB->A
過錯  <wang2650@sohu.com> 15:39:36
java 不怕麻煩用mule 哈哈
魏瓊東(47920381) 15:39:37
這個做法算是ESB的濫用吧
納尼(123140395) 15:39:51
基於WCF下實現,也就是ESB公開一個回到契約
魏瓊東(47920381) 15:40:21
WCF本身在TCP通訊下本身就回回撥
魏瓊東(47920381) 15:40:28
但是是要選擇TCP通訊的前提
納尼(123140395) 15:40:28
@魏瓊東 您指的是統一呼叫嗎?

納尼(123140395) 15:43:12 
ME TOO
魏瓊東(47920381) 15:43:18 
這說明在找抽
納尼(123140395) 15:43:30 
我也這麼覺得
魏瓊東(47920381) 15:43:34 
是在搞為了ESB搞ESB
魏瓊東(47920381) 15:43:42 
是沒有需求搞有ESB
魏瓊東(47920381) 15:43:47 
真正企業有很多不同的系統
魏瓊東(47920381) 15:43:53 
比如PB開發的,VB開發的
魏瓊東(47920381) 15:43:56 
JAVA開發的的
魏瓊東(47920381) 15:44:00 
.NET開發的
魏瓊東(47920381) 15:44:04 
資料庫跑在ORACLE上的
魏瓊東(47920381) 15:44:08 
SQLServer上的
馮永博(309805629) 15:44:10 
sharepoint 搞麼
魏瓊東(47920381) 15:44:11 
還有MYSQL的
納尼(123140395) 15:44:12 
是的
魏瓊東(47920381) 15:44:28 
那麼在這種情況下ESB就是解決問題的存在的先決條件之一
魏瓊東(47920381) 15:44:39 
ESB是因為大家做介面做鬱悶了,才上的。
魏瓊東(47920381) 15:44:42 
不是一開始就上的。
納尼(123140395) 15:44:54 
是的
魏瓊東(47920381) 15:45:01 
ESB的設計更多的是解決不修改各個系統而實現與系統的對接
納尼(123140395) 15:45:14 
但是ESB更多的是更好的管理服務
魏瓊東(47920381) 15:45:18 
不是了你把所有服務都通過ESB,所有系統都修改一通
納尼(123140395) 15:45:27 
您說的是系統的整合
魏瓊東(47920381) 15:45:29 
那不是沒事找抽嘛
納尼(123140395) 15:45:58 
您說的正在做,只不過是其他人
魏瓊東(47920381) 15:46:04 
ESB的做用不就是做這事的嘛
魏瓊東(47920381) 15:46:21 
當然,ESB也可以是SOA的基礎設施
魏瓊東(47920381) 15:46:26 
所有的服務都經由
魏瓊東(47920381) 15:46:28 
ESB
魏瓊東(47920381) 15:46:31 
這個也沒錯
納尼(123140395) 15:46:38 
是的
納尼(123140395) 15:46:53 
一個完整得SOA平臺
魏瓊東(47920381) 15:47:06 
是啊
納尼(123140395) 15:47:12 
服務的管理需要禁得其考研
魏瓊東(47920381) 15:47:16 
@納尼 把你的ESB Show一下
納尼(123140395) 15:47:32 
如果不走ESB,那麼服務很難管好
魏瓊東(47920381) 15:47:35 
“需要禁得其考研“,這個好
納尼(123140395) 15:47:38 
對不起,我剛剛開始
納尼(123140395) 15:47:47 
X@8}U9MLE}EBUE273)]9PGF_thumb
魏瓊東(47920381) 15:47:56 
現實之中就沒有這樣的需要
納尼(123140395) 15:47:58 
等我把這個做差不多了
魏瓊東(47920381) 15:48:06 
為了輪子造輪子
納尼(123140395) 15:48:06 
我會共享出來的
納尼(123140395) 15:48:17 
SOA是騙人的
魏瓊東(47920381) 15:48:22 
我定位做異構系統的整合之用
魏瓊東(47920381) 15:48:27 
也不是騙人的
魏瓊東(47920381) 15:48:44 
SOA架構是服務於合作伙伴的
納尼(123140395) 15:48:48 
那畢竟只是SOA的一部分
魏瓊東(47920381) 15:48:55 
內部一系統搞的那麼複雜就有問題了
納尼(123140395) 15:49:29 
但是對於龐大的企業,業務很大
納尼(123140395) 15:49:39 
所有的業務都要是釋出成服務的
納尼(123140395) 15:50:07 
如果隨便的去呼叫服務,那麼是很雜亂的
納尼(123140395) 15:50:19 
我也很贊同您說的
納尼(123140395) 15:50:36 
就是系統內的服務不走ESB
納尼(123140395) 15:50:48 
但是,什麼又是系統內的呢
納尼(123140395) 15:51:01 
很多資料慢慢會被公有化
....(879621940) 15:51:13 
請問一下,如果一套系統,包括HR,CMR,ERP,OA,BI等要實現資料共享,是不是也可以用SOA技術呢?
納尼(123140395) 15:51:41 
至少中石油正在做
納尼(123140395) 15:51:53 
@。。。 如上回答
納尼(123140395) 15:52:09 
包括國內的擁有
納尼(123140395) 15:52:12 
用友
....(879621940) 15:52:26 
就是說都是使用SOA技術對吧?
納尼(123140395) 15:52:37 
他們的平臺也是基於SOA的(2010年前,現在不知)
納尼(123140395) 15:52:50 
SOA更多是個理念
魏瓊東(47920381) 15:52:50 
你有一個假設已經錯了
納尼(123140395) 15:52:55 
“騙人的”
魏瓊東(47920381) 15:53:03 
你假設企業內部系統是統一的
納尼(123140395) 15:53:06 
@魏瓊東 您說
魏瓊東(47920381) 15:53:12 
納尼(123140395)  15:49:29
但是對於龐大的企業,業務很大
所有的業務都要是釋出成服務的
如果隨便的去呼叫服務,那麼是很雜亂的
我也很贊同您說的
魏瓊東(47920381) 15:53:30 
你的假設就是要早一部非常完美的東西
魏瓊東(47920381) 15:53:39 
比如說你的服務是完美的
納尼(123140395) 15:53:42 

魏瓊東(47920381) 15:53:59 
而事實是當系統龐大到這個份上就有一個問題
魏瓊東(47920381) 15:54:05 
這個東西永遠都不成熟
魏瓊東(47920381) 15:54:07 
OK
魏瓊東(47920381) 15:54:09 
明白
納尼(123140395) 15:54:15 
SOA的理念不僅僅是關注現在,還要展望未來(說出這種話,有點噁心)
魏瓊東(47920381) 15:54:19 
那麼更實現做的做法是什麼
納尼(123140395) 15:54:43 
@魏瓊東 BPM可能會解決您所說的
魏瓊東(47920381) 15:54:51 
更現實的做法是企業內部的系統都是由不同的供應商來供應和開發
納尼(123140395) 15:54:54 
快速應對需求的變化
納尼(123140395) 15:55:06 
贊同
馮永博(309805629) 15:55:13 
這個應該沒法避免,要資訊化建設有個規劃和統籌
魏瓊東(47920381) 15:55:15 
因為比始做HR的對HR業務一定是擅長的
魏瓊東(47920381) 15:55:28 
做PLM的也是擅長PLM的
魏瓊東(47920381) 15:55:41 
並且這樣的成本也就會低很多
魏瓊東(47920381) 15:55:49 
就如同軟體工程之中的敏捷方法一樣
魏瓊東(47920381) 15:55:57 
拆成小的,一個一個人搞
納尼(123140395) 15:55:58 
非常贊同
....(879621940) 15:55:59 
如果這些系統都是自己開發呢?
魏瓊東(47920381) 15:56:08 
一個搞壞也只是一個
魏瓊東(47920381) 15:56:16 
不是一個搞壞全搞完完了
馮永博(309805629) 15:56:22 
自己開發的也不一樣就用的好
魏瓊東(47920381) 15:56:26 
我為什麼支援這些觀點呢
魏瓊東(47920381) 15:56:34 
是因為我做10多年的醫療業務
魏瓊東(47920381) 15:56:38 
大家都走過一個過程
魏瓊東(47920381) 15:56:48 
前些年大家都追求一個醫院全是一家的
納尼(123140395) 15:56:57 

魏瓊東(47920381) 15:56:59 
但是企業做的累,醫院覺得都不專業
魏瓊東(47920381) 15:57:04 
所以現在慢慢的都是開放式的
魏瓊東(47920381) 15:57:10 
專業的各做各的

納尼(123140395) 15:57:51
我覺得BPM足夠用了
魏瓊東(47920381) 15:57:57
客戶也覺得這樣挺好
馮永博(309805629) 15:58:05
現在的趨勢是越做越大
納尼(123140395) 15:58:14
但是領導玩的都是趨勢
納尼(123140395) 15:58:24
政府上SOA
魏瓊東(47920381) 15:58:30
@刺客 哥們,你的腦袋在想什麼呢
納尼(123140395) 15:58:34
移動、聯通
魏瓊東(47920381) 15:58:44
領導的事我們不想了
納尼(123140395) 15:58:45
還有中石油
魏瓊東(47920381) 15:58:50
反正 你做出ESB那樣搞也行。
納尼(123140395) 15:59:13
領導從別人那抄點想法,害苦我們啊
馮永博(309805629) 15:59:19
比如 SAP的ERP 整合的子系統是越來越多
納尼(123140395) 15:59:22
我是這麼想的
過錯  <wang2650@sohu.com> 15:59:31
soa通常解決是服務釋出的問題  esb通常解決的是異構通訊的問題
納尼(123140395) 15:59:42
最好是適應特定的場景
過錯  <wang2650@sohu.com> 16:00:53
有的時候目的不同 但是會用同一樣的東西
過錯  <wang2650@sohu.com> 16:02:04
soa不過是esb的一部分罷了
納尼(123140395) 16:02:49
@過錯  呵呵

      那麼在建設和使用ESB到底是偏向那一個重點呢,歡迎各位部落格園朋友討論本話題。

相關文章