spring与SOA

在面向对象方法中，系统的功能是通过一组相互协作的对象来实现，对象之间的协作通过对象间的相互关联来实现。 这种关联通常表现为对象或接口的引用，在早期的面向对象方法中，对关联对象的使用都是在代码中以编码方式得到，由对象的使用者负责对象的创建和清除，之间是调用对象的方法代码。这种方法将与业务无关的对象创建和清除和业务代码绑定在一起，使对象紧密耦合在一起，使对象难以测试和重用。spring 通过反转控制(IoC) 方式将对象的关联关系以及对象的创建和清除抽象出来，放在一个公共容器中来完成这些与业务无关的操作。

在spring中，对象之间的关系定义在一个spring容器能识别的配置文件中，要使用对象时，向spring容器申请一个对象的引用，spring容器会根据配置文件创建一个对象实例，并且会创建（或获取）该对象引用到的其他关联对象，然后将对象引用返回给申请者。 对申请者而言，对象间复杂的关联处理和对象的创建被spring容器屏蔽了，代码会变得更加简洁清晰。 当对象之间的关联关系发生变化或替换关联对象时，只要修改配置文件即可，不许要对申请使用对象部分代码作修改， 提高了系统可维护性。

现在来看一下SOA的情况。 SOA方法以服务作为基本元素来抽象系统， 服务的粒度比对象粗，通常一个服务需要一组对象相互协作来实现其功能。 同样，系统的功能也不是由单一的服务来完成的，通常也需要一组服务相互协作才能完成一项业务功能。那么SOA又是如何来组装服务的呢？ 答案是ESB（Enterprise Service Bus）。

在SOA方法中，服务都在ESB中注册，由ESB对外提供统一的服务使用接口。服务之间的协作也在ESB中定义，目前的商业产品都提供可视化的界面来设计服务之间的调用关系。 通常都支持将若干服务组合为一个业务流程，可根据提供给服务的数据来动态决定下一步要调用的服务。 这种对流程的增强功能是spring容器所没有，在spring容器中目前还不能通过初始化数据来决定创建哪个对象。 这也和对象与服务的自治程度有关，服务比对象有更好的重用度，能更加容易地组合成业务流程。

服务的使用者向ESB申请服务，服务的使用者对ESB内部服务的组合完全透明， 只要访问接口不变，ESB内部的变化不会对服务的使用者造成任何附加修改， 有效实现了服务使用者和提供者之间的松耦合。

无论spring还是SOA， 都是将和业务无关的基础设施功能抽象出来，放在一个公共的地方处理， 简化了对象和服务的使用， 使代码更加关注于业务问题。 并且对对象和服务都实现了有效的解耦， 使对象和服务更易重用和测试。