spring SOA architecture

在谈这个之前，还得再说下SOA和平台。SOA做两件事情，一个是解耦并识别可重用的服务，一个是对服务进行灵活组装和编排满足业务需求，SOA核心是业务和技术的解耦，服务和能力的复用。而在IT领域的平台平台的概念目前基本上有三种，一种是基于快速开发目的技术平台，第二种是基于业务逻辑复用的业务平台。第三种平台基于系统自维护，自扩展的应用平台。技术平台和业务平台都是软件开发人员使用的平台，而应用平台则是应用软件用户使用的平台。

　　SOA本身是一个平台

　　首先要认识到SOA产品本身就是一个集成平台，为了完成数据集成，应用集成和流程集成，我们需要一个基础平台来集中统一的完成这个事情。因此SOA集成平台重点则是将服务集成和服务组装的能力全部管理起来，从这个概念上理解自然涉及到SOA最核心的UDDI，ESB和BPEL等功能。这些集成的特性和功能完全是在各个业务系统外的，又是大家都需要的基础公共功能，则应该纳入到平台集中管理。

　　SOA称之为平台的原因则是它提供了业务系统都需要的通用基础架构和技术，这种能力是大家都需要的公共基础能力。但是如果我们买入一个SOA套装产品，这个产品可能刚开始没有任何服务接入，也无法提供任何服务能力，那么这个产品本身就是一个技术平台。如果后面我们将数据服务，业务服务，流程服务全部识别，开发后发布到平台上，那么SOA平台本身就是一个专属某个业务域的业务平台。

　　平台本身要考虑SOA化

　　平台的核心是它是一个公共的基础能力提供中心，平台本身已经集中了所有可复用的能力，开发框架和技术。通过平台我们可以快速的开发平台和应用。

　　在软件开发里面我们比较关注技术平台，而技术平台简单理解就是所有业务系统标准的技术能力的抽象和封装形成了一个不承载具体业务的空框架。这个空框架不仅仅是简单的技术开发框架，而是融入了更多的基础服务能力。

　　基础服务能力包括两个层面，一个是纯粹技术方面的基础服务能力，包括日志，异常，消息，事务，国际化，缓存等内容。一个是业务抽象后和业务无关的技术能力，包括通用权限模型，通用流程模型，邮件短信组件，常用UI组件。有了这些，你会发现技术平台本身就是一个完完整整可以独立运行起来的应用，除了没有具体业务功能外其他一应俱全。

　　基于该平台我们可以开发业务应用，那如果平台本身是基于SOA架构的，那么开发的应用自然也就满足SOA架构风格。一个应用功能应该包括资源层，技术组件，服务组件层，流程层等。一个应用功能在实现业务过程中能够看到业务和技术实现是剥离和松耦合的。一个应用它本身是基于在技术平台上开发的多个业务组件构成的，业务组件间本身松耦合，业务组件间通过服务进行交互。

　　基于平台开发的业务应用，本身业务组件之间可能基于ESB总线方式进行消息交换，我们可以联想下Java里面的IOC控制反转模式，和通过ESB总线进行交互的思路是很类似的，只有这样才能够实现组件之间进一步的解耦。

　　传统的很多快速软件开发平台是完全不能符合SOA架构风格要求的，因为基于某些快速开发平台开发出来的应用本身就是紧耦合和封闭的应用。而基于SOA架构风格的平台开发出来的应用本身就是完全组件化和服务化的应用，应用内部SOA化和松耦合，应用和应用之间也松耦合，应用本身可复用的能力很容易通过服务方式暴露出来。

　　技术平台和业务平台

　　首先要说明技术平台和业务平台都是开发人员关注的平台，而应用平台可能是最终用户关注的平台。可以看到技术平台和业务平台的划分正好体现了业务和技术本身的一次解耦。

　　技术平台只关注和业务完全无关的技术本身，将各种技术能力组件化和服务化，提供各种通用的基础服务和技术服务。技术平台提供一套完整的开发框架和开发环境，同时也提供一套完整的执行环境。技术平台既为产品服务，也为业务平台服务。

　　而细分到某个专业的业务域后可能出现业务平台，业务平台也可以叫做产品平台，比如电信的BOSS平台，网管平台都是很常见的业务平台。那业务平台和技术平台最大的不同是业务平台本身提供了开发多个产品都可复用的业务组件和业务能力。业务平台本身是对多个同类产品通用业务能力的抽取，提炼和下沉。

　　应用产品->产品平台->技术平台，正好体现了可复用能力的逐层下移，下移的目的只有一个即最大限度的复用，而复用的好处是对通用能力统一管理和统一维护。我们可以试想下，如果没有这种平台，当我们面对N个产品开发对应N套产品开发源代码的时候，对用通用功能的修改调整和升级将是一件巨大的麻烦。