SOA大家谈-SOA的基本概念与企业应用集成

最近两年都在做与企业应用集成和SOA相关的一些工作，并且有一些心得和总结，但总觉得在一个小的范围内难以获得思维的碰撞，总是希望更多的人参与进来一起讨论，一起提高。
所以准备把我个人以前的一些总结和PPT拿出来，与大家一起谈谈SOA这个不算新但却十分活跃的话题。


该贴描述的是我自己两年前对SOA的理解，现在可能已经有所不同了，但是为了追寻思维的轨迹，并引起大家的话题，还是从基础的说起。
首先说说SOA的基本概念，然后重点讨论它的主要应用方向——企业级应用和集成应用问题，并把落脚点放到中小型的制造企业，尤其是典型的企业应用（可能有些朋友不了解，不过没关系，很容易理解）。


给别人或者师弟师妹们谈到“面向服务的架构”，我总会给他们解释什么是“架构”。我会回答：架构是一种风格。就像“架构”的英文单词来源于建筑一样，构建软件与建筑很类似。那么架构就是某种建筑所体现的风格，比如一说到“亭台楼阁”大家就联想到苏州园林，说到“教堂”可能想到哥特风格的建筑，这两者很容易区分，为什么呢？那就是因为他们具有迥异的“建筑风格”。所以SOA刚开始流行的时候，很多人就在强调，SOA与实现无关，它是一种新的软件思维方式，这就好比不同风格的建筑都可以用钢筋水泥做成一样。


框架应该是我们谈论最多的，什么Spring，Strust2，Seam或者.Net，那么这些框架与架构之间怎么区别呢？
我的理解是架构是一种软件的应用模式，而框架是一个实实在在的软件系统，并且框架是与实现和语言密切相关的。
我们可以用某种框架去实现某种架构风格，而架构思想又指导框架的实现方式。典型就是SOA的思想催生了SCA、SDO等规范和实现。


理解架构之后，那么SOA的核心理念应该就是服务了。


这个是当初被Copy烂了的图，应该是SOA的雏形，但更加确切的说，它描述的是Web services应用的一种模式，因为目前SOA典型的实现方式仍然是Web services


Thomas Erl的那本经典的SOA著作中描述了服务的许多特性和之间的关系，而在我看来，对于中小型的企业应用，首要的问题应该是“服务的松散耦合性”，这是我个人最为看重的。和许多小公司开发人员一样，有过系统逻辑耦合紧密，用户需求的不断变化（我们戏称为变态需求）导致系统配置项不断增多用以应付不同的客户和不同的需求，最后结果确是改好一个BUG，引出十个BUG。所以我认为SOA让我们看到了松散耦合的希望（有希望总是好的）


除了单个的应用系统，已有系统和新系统的集成问题对于中小企业也日渐显现。比如一般企业都会有财务软件，后续为了办公规范上了OA，之后规模扩大，生产管理问题突出，引入了行业ERP，但这些系统如何融合，如何实现数据、流程等多方面的集成，就变得很困难。传统的有一些EAI产品，但是价格昂贵且负责，不适合小企业，SOA的出现也为应用集成开辟了新的方向。有人会说SOA也很复杂啊（像SAP的NetWeave），但正像SOA承诺的那样，渐进式的慢慢来，如果有一个简单易用的SOA集成平台满足特定行业的需求，将典型应用作为服务挂接上去，不是挺好吗？（本帖目的就和大家探讨如何构建自己的SOA平台，希望有经验的朋友发表看法）


比如一个典型的模具制造企业，规模不大，但是慢慢随着发展，管理系统和IT应用也会不少，也有需求将各个系统串起来，这就引导我们去思考简单、易用、廉价的集成平台的问题。


那么如何根据我们实际的需求去设计一个集成平台框架呢？架构思想这时就起到了关键的作用。相信很多朋友看到开源文档——Roy Thomas Fielding(REST架构创始人)的那篇经典的论文，它为我们思考架构提供了很好的思路。
这又使我联想到了“建筑”，可能第一种方法比较适合于设计创造性的建筑，比如鸟巢，第二种可能适合于实用性建筑，比如杭州湾跨海大桥。那么我们做软件的目的当然是为了满足客户需求，而不是炫耀自己的架构多么的优秀，自然会选择第二种方式去设计我们的架构。


从用户需求推导出系统约束，由约束来添加满足约束的架构方式或组件，最后由导出的架构风格指导我们选择一些已有的东西去搭建我们的架构实例。

以下就是一般制造型企业架构的推导过程（可能略显粗糙，主要只是表达这个过程）












好了！现在架构风格已经基本成形了。它与SOA风格不谋而合，应用系统的功能暴露为服务，服务无状态，因此和相互组合成新的流程（BPEL）和应用，状态管理由服务端拿到了客户端（广义的客户端），中间通过统一的数据格式来交换数据（XML）


咦！既然这样，是不是也可以利用一些开源的组件构建我们自己的SOA集成平台呢？上图就是一个简单的框架说明


那么各个核心组件之间的调用关系如何呢？上图描述了大致的过程。用Portal作为统一的用户界面，调用由ESB处理的各种数据消息（不管这些数据从何而来，去向何方），UDDI中存放着已有的服务，BPEL将需要的服务组合起来，形成流程，并发布为新的服务，注册到UDDI，ESB只需要根据配置找到对应的服务和业务规则，对XML文件进行传递、映射等等，这样数据不就集成了嘛，通过Portal也可以看到集成的效果了吗？虽然不够理想，但应该就是这样，呵呵


好了，有了大致框架，应该分析一下某些应用了。我们很清醒，小团队是做不出通用的产品的（要不SAP就倒闭了，呵呵），通用的产品中小企业也是买不起的，那么我们就应该重点放在SOA能解决什么具体问题。
比如CAD、CAE的集成问题，这些常用的软件通常需要与管理系统管理，但绝大部分企业就是Excel导出、导入来实现数据交互，我们就可以尝试用Web services通过SOA平台来实现无缝的集成。


好了，今天就写一些关于SOA和集成有关的感触，后续有时间将一点一点展开，希望大家来拍砖：）

好文章，不过约束4 与 约束5 之间的差异没感觉出来。

不过我认为
    在SOA方面，业内似乎更关注 如何去整合 原有的应用
返而在构建新的应用中如何遵循SOA的架构，却很少注意。。。。。

拍砖，呵呵：

   "what is SOA"中讲到的概念“面向服务”，个人认为：业务即为服务，服务即为业务。在不同的架构中，业务有不同的标准，不同的体现，不同的定义，SOA中其以服务来标准化业务，体现业务。显然“用业务表达流程”的说法不太确切。面向对象将一切都体现为对象，面向服务，即是“一切皆为服务”。
 
    另外，其中一些图 描述的思想已经有些过时了，我想楼主的一些内容是06年前后的，现在已经发生了很大的变化。

   

哦，楼上的，那些思想过时了，愿听其详

不要忘记了SOA平台也可以提供自己的服务,因为SOA有自己的流程.业务不是服务,也许是业务和业务的协同才是SOA的服务.

我对  业务即服务 这句话不敢苟同。

在大多的场景下，业务 表现为 流程，是 服务的 编排和协同。

SOA是面向服务的，具体分为如下：服务的构造（包括开发和组合），服务的管理（包括服务的注册和治理），服务的编排（包括服务的编排和编制）。

顶楼上的。

   其实业务 和 服务的关系
    有点像 服务于数据的关系

套用楼上的话，我也可以这么解释

在大多的场景下，服务 表现为 流程，是 数据的 编排和协同。

具体分为如下： 数据的构造（包括开发和组合）， 数据的管理（包括 数据的注册和治理）， 数据的编排（包括 数据的编排和编制）。

但我认为服务和业务还是有区别的

  第一操作的元素是不一样的，一个是数据，一个是服务
  第二编排和协同的定制者不一样，第一个是百分百的程序员，第二个有可能是实际业务人员！