再谈SOA集成平台建设必要性
- - 人月神话的BLOG对于SOA集成平台建设的必要性是任何一个SOA建设项目首先必须解释清楚的问题，在原来我们强调的比较多的是通过SOA服务总线从传统的点对点集成变化为了总线式的标准化服务集成. 但是要注意到即使服务不接入ESB，我们仍然可以按照SOAP
WebSerivce的设计规范和标准进行服务的契约设计，服务的开发和实施.
再谈SOA集成平台建设必要性
标签：
IT咨询
| 发表时间：2013-12-17 21:04 | 作者：人月神话
出处：http://blog.sina.com.cn/cmmi
对于SOA集成平台建设的必要性是任何一个SOA建设项目首先必须解释清楚的问题，在原来我们强调的比较多的是通过SOA服务总线从传统的点对点集成变化为了总线式的标准化服务集成。
但是要注意到即使服务不接入ESB，我们仍然可以按照SOAP WebSerivce的设计规范和标准进行服务的契约设计，服务的开发和实施。虽然是点对点，但是仍然可以满足服务是标准化的，是可重用的。除掉这点，我们谈的比较多的是ESB有很多的适配器，可以做遗留系统的适配，可以做消息协议的转换，这些系统不用遗留系统关心，但是对于全新规划建设的业务系统，往往我们一开始就采用的标准SOA架构和服务设计方法，不存在传统的EAI需要大量进行适配的问题。至于ESB的UDDI服务目录往往意义更不大，要注意是企业内部的服务共享，并不存在太强的服务查找和发现需求。
把以上所有SOA集成平台优势去除后，真正当前上SOA平台的优势往往会体现在统一的服务目录提供（实现原生服务提供系统的透明），服务的鉴权，服务的路由，服务的运行监控。这些将成为搭建一个SOA集成平台的重要目的，即对整个企业内部大集成架构下，系统间的交互，业务协同和数据交换，我们可以通过总线提供的能力更好的进行管控和治理，这些能力全部集中在SOA集成平台上统一灵活配置。同时SOA集成平台提供共享服务目录，提供唯一的服务访问出口，这些才是后续建设SOA集成平台的一个重要目的。
在SOA集成平台上可复用的原子服务，组合服务逐步形成后，我们才会考虑进一步的服务编排，流程编排等。有了统一的服务目录库，有了统一的服务管控和治理，有了可复用的服务，流程组合和编排才成为可能。这也是我原来写文章强调过多次，SOA总线上的服务需要由数据服务准备转化为业务服务的原因。
通过服务的复用来降低业务系统构建成本和构建周期，通过服务的组合编排来提升对业务变化的敏捷响应能力，这也是我们常说的SOA思想引入了实现的业务目标。我一直强调SOA是一种架构思想，这种架构思想强调了将企业内的多个业务系统划分为多个松耦合的业务组件，这些业务组件提供可复用的原子服务能力，这些原子服务能力可以进一步组合和编排以满足业务流程的变化。而其它的ESB，BPEL仅仅是实现的技术手段或标准体系。
这种架构思想真正难以被大家理解或接受的原因就是我们在SOA实施过程中经常将SOA仅仅提留在了接口平台或集成平台的层面，而忽视了SOA和企业架构的关系，SOA和云计算的关系，只有真正理解了业务驱动IT，业务和技术通过SOA服务来解耦，才能真正这种架构思想引入后带来的巨大作用。
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密 
但是要注意到即使服务不接入ESB，我们仍然可以按照SOAP WebSerivce的设计规范和标准进行服务的契约设计，服务的开发和实施。虽然是点对点，但是仍然可以满足服务是标准化的，是可重用的。除掉这点，我们谈的比较多的是ESB有很多的适配器，可以做遗留系统的适配，可以做消息协议的转换，这些系统不用遗留系统关心，但是对于全新规划建设的业务系统，往往我们一开始就采用的标准SOA架构和服务设计方法，不存在传统的EAI需要大量进行适配的问题。至于ESB的UDDI服务目录往往意义更不大，要注意是企业内部的服务共享，并不存在太强的服务查找和发现需求。
把以上所有SOA集成平台优势去除后，真正当前上SOA平台的优势往往会体现在统一的服务目录提供（实现原生服务提供系统的透明），服务的鉴权，服务的路由，服务的运行监控。这些将成为搭建一个SOA集成平台的重要目的，即对整个企业内部大集成架构下，系统间的交互，业务协同和数据交换，我们可以通过总线提供的能力更好的进行管控和治理，这些能力全部集中在SOA集成平台上统一灵活配置。同时SOA集成平台提供共享服务目录，提供唯一的服务访问出口，这些才是后续建设SOA集成平台的一个重要目的。
在SOA集成平台上可复用的原子服务，组合服务逐步形成后，我们才会考虑进一步的服务编排，流程编排等。有了统一的服务目录库，有了统一的服务管控和治理，有了可复用的服务，流程组合和编排才成为可能。这也是我原来写文章强调过多次，SOA总线上的服务需要由数据服务准备转化为业务服务的原因。
通过服务的复用来降低业务系统构建成本和构建周期，通过服务的组合编排来提升对业务变化的敏捷响应能力，这也是我们常说的SOA思想引入了实现的业务目标。我一直强调SOA是一种架构思想，这种架构思想强调了将企业内的多个业务系统划分为多个松耦合的业务组件，这些业务组件提供可复用的原子服务能力，这些原子服务能力可以进一步组合和编排以满足业务流程的变化。而其它的ESB，BPEL仅仅是实现的技术手段或标准体系。
这种架构思想真正难以被大家理解或接受的原因就是我们在SOA实施过程中经常将SOA仅仅提留在了接口平台或集成平台的层面，而忽视了SOA和企业架构的关系，SOA和云计算的关系，只有真正理解了业务驱动IT，业务和技术通过SOA服务来解耦，才能真正这种架构思想引入后带来的巨大作用。
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密 相关 [soa 成平 台建] 推荐：
SOA资料学习
- - 人月神话的BLOG从对象到组件，首先可以把对象理解为更细粒度东西，而组件是更加粗粒度的模块，对象更多关注技术，而组件应该更加关注业务. 前面我们谈过技术组件和业务组件，在SOA思想下业务组件化的思想就更加重要. 组件本身而言很简单，南向接口和北向接口，或者再有底座平台支撑. 接口通过服务方式来实现，组件通过OSGI等技术实现高度的解耦和可热插拔性.
SOA架构咨询
- - 人月神话的BLOG对于SOA架构咨询，其核心还是在于组件化和服务化，然后才是服务管控和治理，基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构，或者更多的人仅仅是将SOA理解为service服务接口，这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT，而非单纯的IT架构咨询，SOA咨询一般都会结合企业架构和云的思想，结合组件化架构和领域服务的思想，高层结合BPM端到端流程整合目标，并对这些内容进行有效的融合.
从流水程序到SOA
- Allen - 阿朱=行业趋势+开发管理+架构咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了. 函数和变量写多了，自然也就发现有些函数和变量互相粘在一起很高耦合，而与其它的一些却没多达关系，于是为了显性化让其他的开发人员知道哪些函数和变量确实关联性很紧密，于是创造了类. 面向对象在80年代的国外代码开发界颇为流行. 但接口思想的风潮在90年代刮起了.
eBay开源SOA-Turmeric架构
- - 人月神话的BLOG参考： https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台，提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.
SOA面向服务架构
- - 人月神话的BLOG今年在这点上谈的比较多，也逐步开始落地实施，将SOA咨询和实施方法论从系统间真正的引入到系统内，将面向对象的需求分析方法和SOA思想进一步融合，从业务建模到系统用例建模，从流程分析到服务识别和分析，从业务组件化到系统模块化，这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值，真正的做到业务组件化和组件能力化.
[SOA] Mule ESB Linux 部署
- - CSDN博客架构设计推荐文章本文介绍如何在 Linux 上部署 Mule ESB. Mule 是一个以Java为核心的轻量级的消息框架和整合平台，基于EIP（Enterprise Integeration Patterns，由Hohpe和Woolf编写的一本书）而实现的. Mule的核心组件是UMO(Universal Message Objects，从Mule2.0开始UMO这一概念已经被组件Componse所代替)，UMO实现整合逻辑.
集成ESB实现SOA
- - 企业架构 - ITeye博客 服务消费者，服务提供者， 服务注册中心（UDDI模型）. 由于UDDI模型过于复杂，而服务提供者与消费者点对点的进行协作依赖性大大增强，因此产生演变. 服务代理 -- ESB. 基于ESB总线，使得服务请求者统一入口，而ESB管理服务，使得耦合降低，由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改.
SOA实施收益分析
- - 人月神话的BLOG远行科技自2007年开始即参加了中国移动集团SOA接口平台的建设和实施工作，在SOA规划咨询，建设实施方面有丰富的实践经验积累. 对于SOA实施收益，先以某客户的一个真正业务背景进行分析：. 业务场景：我们现在的工程项目管理，其规划，立项和工程实施计划在项目管理相关系统；工程物资采购在采购管理系统；审批在
OA系统，财务的信息又在ERP核心系统.
数据交换和SOA服务共享
- - 人月神话的BLOG数据本身只是一种资源，而服务是一种能力；数据仅限于各种结构化和非结构化的数据资源，对于数据资源提供的能力可以使一种数据服务，而数据资源+业务规则形成的某种业务能力也可以作为一种服务提供，也就是说各种技术，数据，业务，平台，流程能力都可以做为服务提供. 交换本质是资源会从一个系统通过传输的方式进入到多个系统，资源在多个系统中形成多种拷贝.