昨天刚分析完分布式服务框架，今天便看到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的时候能让大家眼前一亮吧。
由于和自己想象中的分布式服务框架还是有很多的不同，因此还是继续去实现自己的分布式服务框架。