昨天剛分析完分布式服務框架，今天便看到Spring Integration 1.0 M1發布的消息，這也為Spring進軍SOA領域拉開了序幕。
Spring的動作一直就頗多，其實它自己就是個非官方的標準，不過它顯然更聰明，因為它基于一個強大的pojo container結合pojo enhanced機制使得它可以很容易的集成在其他領域極為專業的東西，而不是自己去競爭，更加好的是它提供的是選擇，這也就使得Spring很容易的成為了最為流行的框架，而Spring和OSGi的結合更是進一步的提升了它的應用面，因為估計有很多人忌諱spring的巨大而不使用它了，至少我以前就這么選擇過，選用OSGi這樣的模塊化框架固然是缺少了很多企業應用需求的東西的支持，但對于有些應用來講完全可以自己去實現，但對于大而復雜的應用來說直接選用OSGi幾乎是不可能的，因為要自己去實現太多的東西，還好Spring和OSGi結合在一起了。
說了這么多和標題無關的話，只是想表明Spring其實已經具備了分布式服務框架中很重要的一些因素：可插拔(這樣的話完全可以根據應用的需求來搭建微小還是巨大的東西)、強大的集成能力，而且Spring本身之前就已經提供了一些分布式交互的支持，如JNDIObjectFactoryBean、HessianServiceExporter等等，回到正題，由于Spring本身就具備了這些特征，因此其實以它來實現分布式服務框架確實是個很好的選擇，Spring自己果然也沒浪費這樣的機會，順理成章的推出了Spring Integration。
Spring Integration是基于Message機制來達到Bean交互的，這個在上篇分析分布式服務框架的blog里已經有所提及，在服務的交互上是有多種協議可去選擇的，Spring Integration選擇了JMS機制，從它目前公布的例子也能看出，使用起來有點的晦澀，但是功能方面確實還不錯，已經具備了分布式服務框架的整個的架子：
1、服務模型
在Spring Integration里準確的說應該是一個供bean使用的Message Queue或Channel就是服務了。
2、服務的注冊中心
由于在Spring Integration里交互其實是通過message來完成的，因此服務的注冊中心中其實只需要能提供message的地址和queue名或Topic名就可以了，這個在現在的IBMMQ Broker這樣的東西是直接支持的。
不過在目前的Spring Integration還沒看到這塊。
3、發布服務的方式
源于上面服務的注冊中心，其實就是發布mq server地址和queue名了。
4、查找服務和調用服務的方式
目前由于無服務中心，沒有查找這回事。
調用服務目前是通過直接往目的地發消息來實現，當然Spring Integration已經屏蔽了調用JMS的細節。
5、服務的組裝
組裝這塊目前Spring Integration也沒有清晰的提供。
6、穩定性和性能
由于是基于message機制的，穩定性和性能主要就取決于MQ了。
根據這個可以看出，目前雖然是有架子了，但還是有一定的距離，不過畢竟是1.0 M1，希望等1.0 release的時候能讓大家眼前一亮吧。
由于和自己想象中的分布式服務框架還是有很多的不同，因此還是繼續去實現自己的分布式服務框架。