浅析SOA面向服务架构

首先来看看什么是服务？咱们常谈到的业务组件，业务方法或操做是否都是服务？而真正的服务必须知足两个条件，一个服务自己是能力供给，必须有外界的需求；一个是服务自己是可复用或重用。因此简单的讲服务应该是可重用的任务。这种任务能够是业务方面的操做组合，也能够是一种技术能力。

面向服务则重点就是一切以服务为中心，从服务识别，服务分析，服务设计，服务开发和服务上线使用一切都是以服务为中心。可是要注意到面向服务自己不是在传统面向结构或面向对象基础上的一个新方法，而是对传统面向对象和组件化思想的提高。

面向服务架构很容易将SOA理解为一种技术架构，而SOA自己更多的是一种架构风格，这种架构风格和传统软件开发最大的不一样则是更加体现了业务和流程驱动IT的思想，体现了IT系统组件化和服务化构建思想，体现了因为服务自己能够重用，能够经过服务的组合和编排来知足业务的实现。SOA做为一种架构风格，使需求方和供给方有了共同的语言和价值约定；SOA做为一种架构风格，使服务不在单纯的是一种技术能力，而更多的是一种业务能力和IT资产。



再来看SOA的完整定义，通常说SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提高他们的互操做性，从而能够更好地共享、重用和组装，快速构建复合的应用从而知足业务需求的变化。在这里面能够看到两个重点，一个是要找到可重用的服务，同时这些服务知足离散，自治和无状态等基本条件；其次是服务自己能够组合和编排，以知足流程整合的须要。

第一步找服务的过程，是系统分析和建模从顶向下得过程，要充分体现流程驱动IT的实现，经过流程的分解，业务建模和数据建模，识别业务组件和业务能力，经过跨系统或组件的流程交互识别可重用的服务。最终造成可重用的服务资产库。第二步服务的组装和编排则更可能是从底向下得过程，对于原子服务咱们能够组合为组合服务，对于业务服务咱们能够经过组合和编排造成流程子服务和流程服务；最终使可重用的服务知足流程交互的须要。

在跨系统的流程集成和SOA应用集成过程当中，高端建模重点则是EA企业架构或TOGAF方法论，从业务架构，数据架构和应用架构入手，逐层分解和展开分析来得出整体的跨业务系统流程交互和集成架构。而对于系统内的SOA应用，则重点仍然是业务组件识别，经过组件间交互获得的服务组件和服务识别，可重用的服务组件单元的提取。

那么对于应用系统自己基于SOA架构又如何理解？若是说一个应用系统基于SOA架构，咱们至少须要看到该应用系统有明确的业务组件和服务组件定义，并且组件之间知足高内聚松耦合的要求；其次对于组件间的交互都经过服务的方式进行，或者至少预留了服务接口；其次内部这些服务能够灵活的重用或组合。至因而否有内部的ESB总线反而不是重点，可是咱们看到如Java开发内部的IOC机制基本也基于内部的软总线思路，实现良好的互操做性和位置透明。

SOA另一个核心是实现两个层面的解耦，一个是业务和技术的解耦，业务实现再也不依赖于某种特定的技术或语言，只要知足业务标准均可以来实现SOA和服务，正是由于业务和技术松耦合，技术的变化对业务影响越小。另一个方面则是操做方法和业务数据实体的解耦，对于操做方法咱们后续能够经过WSDL文件定义，而传输的数据实体又能够经过XSD定义，对于传统RUP开发方法中，相似于控制类和实体类的分离。

SOA有一些基本特性，在这里再作一下简单解释：

• 粗粒度：仅仅暴露须要暴露的东西，方法和传输都简单，可是实现方法的内部过程则很复杂，业务规则或逻辑所有隐含在业务组件内部，不须要暴露。

• 无状态：每次服务调用完成即完成，不会存储任何全局状态信息，这也是WebService的特性。

• 互操做：包括位置透明，经过ESB和UDDI，只须要关心服务目录，而不须要关心具体提供服务的源系统。

• 标准化：有精确的服务契约和服务接口，这也是在SOA方法论中在服务识别和服务分析阶段重要输出。

若是再举了简单的例子来讲明SOA，能够用传统的活字印刷术来讲明，用于印刷的3000-4000个字便是最基础的原子服务，有了这些原子服务咱们很容易经过这些活字去排版整篇文章。文章内容有调整咱们也只是须要调整这些原子服务的顺序。可是若是全是单个汉字咱们其实排版工做量仍是很大，因此再向上咱们会出现词组或经常使用短句，这些便是组合服务，这样咱们排版速度能够增长。可是能够看到词组或短语的可重用程度下降了。因此越到组合服务或流程服务，复用越困难，可是要是可以复用却能大大提高效率。