SOA面向服务架构

基于SOA的需求分析

今年在这点上谈的比较多，也逐步开始落地实施，将SOA咨询和实施方法论从系统间真正的引入到系统内，将面向对象的需求分析方法和SOA思想进一步融合，从业务建模到系统用例建模，从流程分析到服务识别和分析，从业务组件化到系统模块化，这些工作都逐步开始落地实施。这样做的好处就是进一步的体现SOA可复用组件的价值，真正的做到业务组件化和组件能力化。

谈SOA业务价值的实现： http://blog.sina.com.cn/s/blog_493a84550100ytap.html
浅析SOA面向服务架构： http://blog.sina.com.cn/s/blog_493a84550100zpp9.html

SOA和业务组件（BC）的思考： http://blog.sina.com.cn/s/blog_493a84550100mv7l.html
SOA和数据仓库的思考： http://blog.sina.com.cn/s/blog_493a84550100mv7z.html

再谈基于SOA的需求分析： http://blog.sina.com.cn/s/blog_493a84550100pn8f.html
谈SOA业务组件的识别： http://blog.sina.com.cn/s/blog_493a84550100q13a.html
谈SOA业务组件和技术组件： http://blog.sina.com.cn/s/blog_493a84550100qduh.html
业务组件化和组件能力化： http://blog.sina.com.cn/s/blog_493a84550100qycb.html
谈通过SOA打破系统边界： http://blog.sina.com.cn/s/blog_493a84550100puwx.html
谈SOA思想在系统分析建模中的使用： http://blog.sina.com.cn/s/blog_493a84550100u9sl.html

基于SOA的业务和IT调研核心逻辑： http://blog.sina.com.cn/s/blog_493a84550100l1f3.html
SOA-ESB的需求分析(转载)： http://blog.sina.com.cn/s/blog_493a84550100l3js.html
EPC-事件驱动的流程链(转载)： http://blog.sina.com.cn/s/blog_493a84550100l44r.html

基于SOA的服务设计

在SOA服务设计部分重点考虑的是服务设计原则，服务设计粒度，SOA服务设计模式等关键内容。服务设计的好坏和粒度将直接影响到服务本身的可复用性和服务性能。

SOA服务设计原则-转载： http://blog.sina.com.cn/s/blog_493a84550100l8rv.html
谈SOA服务设计粒度： http://blog.sina.com.cn/s/blog_493a84550100ljp5.html
再谈SOA服务设计粒度： http://blog.sina.com.cn/s/blog_493a84550100mq7m.html
再谈SOA服务设计粒度（2）： http://blog.sina.com.cn/s/blog_493a84550100pl7w.html

读《SOA设计模型》第一部分： http://blog.sina.com.cn/s/blog_493a84550100wi2l.html
读《SOA设计模型》第二部分： http://blog.sina.com.cn/s/blog_493a84550100wk53.html

谈SOA服务提供模拟： http://blog.sina.com.cn/s/blog_493a845501015vok.html
谈SOA服务消费模拟： http://blog.sina.com.cn/s/blog_493a845501015vr9.html
谈SOA业务组件和技术组件： http://blog.sina.com.cn/s/blog_493a84550100qduh.html
服务契约和服务实现： http://blog.sina.com.cn/s/blog_493a84550100qqeo.html

SOA和云计算

对于SOA和云计算的关系，今年完全做到透彻的理解，SOA是偏于集成本身并不产生能力，SOA解耦重点是业务和IT的解耦。而云计算重点则是真正的集中，既本身产生能力又向外提供能力，云计算也谈解耦，但是更多是软件层面和硬件层面的解耦，软件应用和中间件的解耦等。

SOA和云特别是在大型企业内部本身就是相互融合，包括我们说的企业内的PAAS平台，两者本身可以做到完全融合，包括SOA本身的ESB，BPEL等组件，本身就是PAAS云平台的一个部分内容。而对于企业内的PAAS平台一方面是提供中间件，数据库等弹性资源能力，一方面则是ESB，BPEL，共享数据中心本身就属于PAAS平台的内容。而真正的在线开发，在线测试，在线执行等内容并不是企业内PAAS的重点，自动部署除外，因为自动部署本身就是实现资源动态调度和IAAS层集成的关键。

谈SOA和云计算的关系： http://blog.sina.com.cn/s/blog_493a84550100q7nh.html
谈SOA和云计算-能力的提供： http://blog.sina.com.cn/s/blog_493a84550100qqcq.html
再谈SOA和云计算的关系： http://blog.sina.com.cn/s/blog_493a84550100t44t.html
再谈SOA和云计算的相互演进： http://blog.sina.com.cn/s/blog_493a84550100t88x.html
谈云计算中间件： http://blog.sina.com.cn/s/blog_493a84550100q6d1.html
企业PAAS-数据库的集中化： http://blog.sina.com.cn/s/blog_493a8455010116bx.html

谈SOA和平台： http://blog.sina.com.cn/s/blog_493a84550100tsh7.html
谈SOA和BI: http://blog.sina.com.cn/s/blog_493a84550100whcp.html
再谈SOA和云的分层架构： http://blog.sina.com.cn/s/blog_493a845501017w57.html

谈MDM和BI及SOA三者关系： http://blog.sina.com.cn/s/blog_493a84550100nklm.html
谈SOA和BI关系： http://blog.sina.com.cn/s/blog_493a84550100whcp.html

SOA和流程整合

对于已有大量遗留系统情况下基于SOA的流程整合。我们提出关键思路如下:

流程整合前期重点关注端到端流程监控，以端到端流程监控为整合的切入点，这种方式下不会影响到已经固化在业务系统内部的业务功能，而解决了原有业务系统无法提供全流程视图的问题。如项目管理，供应链，财务，物流都存在可以选择的端到端监控流程。

重新定位BPM和BPEL工具，对于BPEL仅作为服务的组装和编排，跨流程的整合启用BPM提供的功能，BPEL编排的内容作为BPM端到端流程的子流程，这样充分利用BPM的HWF人工工作流引擎，已有的界面建模和数据建模等能力。对于BPM工具本身需要支持SOA架构，支持和SOA平台的ESB和BPEL的集成。对于BPM提供的业务流程建模工具倒是次要的。

再谈基于SOA的流程整合： http://blog.sina.com.cn/s/blog_493a84550100qmgv.html
谈通过SOA打破应用系统边界： http://blog.sina.com.cn/s/blog_493a84550100puwx.html
再谈BPM和SOA的整合： http://blog.sina.com.cn/s/blog_493a84550100qtjn.html
谈SOA业务价值的实现： http://blog.sina.com.cn/s/blog_493a84550100ytap.html

谈BPM和工作流1： http://blog.sina.com.cn/s/blog_493a84550100wju5.html
谈BPM和工作流2： http://blog.sina.com.cn/s/blog_493a84550100xwlp.html
谈BPM和工作流3： http://blog.sina.com.cn/s/blog_493a84550100yeej.html

基于SOA的能力中心

这是今年谈到的另外一个重点，即SOA不是简单的服务目录库，而是企业的IT资产库，是企业的能力提供中心，既然是能力中心自然存在能力的产生，能力的申请，能力的使用和消费，能力的监控的全流程的管理和运营。在这里我们借鉴了电信OSS域相关能力管理的思路。

谈SOA服务视图的构建思路: http://blog.sina.com.cn/s/blog_493a84550100s5qf.html
基于SOA下的能力中心： http://blog.sina.com.cn/s/blog_493a84550100sqjd.html
云计算和SOA-能力的提供： http://blog.sina.com.cn/s/blog_493a84550100qqcq.html

EDA事件驱动架构

一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。

构建一个包含事件驱动构架的应用程序和系统，会使这些应用程序和系统响应更灵敏，因为事件驱动的系统更适合应用在不可预知的和异步的环境里。

EDA事件驱动架构(转载)： http://blog.sina.com.cn/s/blog_493a84550100glu2.html
再谈EDA和CEP复杂事件处理： http://blog.sina.com.cn/s/blog_493a845501019ctu.html
再谈EDA事件驱动架构： http://blog.sina.com.cn/s/blog_493a84550101a6wz.html
再谈EDA和SOA的关系： http://blog.sina.com.cn/s/blog_493a84550100id77.html
eBay开源SOA-Turmeric架构： http://blog.sina.com.cn/s/blog_493a8455010165zq.html
消息中间件的比较： http://blog.sina.com.cn/s/blog_493a8455010160jc.html
对事件驱动的消息订阅的再思考： http://blog.sina.com.cn/s/blog_493a84550101243z.html

SOA管控和治理

IT 治理是指针对 IT 的治理；即：针对 IT 组织及其人员、流程和信息应用治理，以提供指导，使这些资产支持业务需求。SOA 治理是 IT 治理的一种特殊化，其将关键 IT 治理决策置于服务组件、服务和业务流程的生命周期上下文中。SOA 治理对生命周期进行有效管理，生命周期是其关键目标。IT 治理比SOA 治理更广泛。IT 治理涉及 IT 的所有方面，包括影响 SOA 的问题（如数据模型和安全性）以及 SOA 之外的问题（如数据存储和桌面支持）。SOA 治理重点关注服务生命周期的一些方面，例如：计划、发布、发现、版本治理、管理和安全性。

SOA治理简介-转载整理： http://blog.sina.com.cn/s/blog_493a84550100mui8.html
Oracle-SOA治理关键杠杆点： http://blog.sina.com.cn/s/blog_493a84550100rvqt.html
谈SOA治理和框架业务架构的构建： http://blog.sina.com.cn/s/blog_493a84550100s3ef.html
SOA治理流程-IBM： http://blog.sina.com.cn/s/blog_493a84550100f9vk.html
谈IBM新一代SOA思路： http://blog.sina.com.cn/s/blog_493a845501017oyh.html
TOGAF和SOA： http://blog.sina.com.cn/s/blog_493a84550100f1b2.html
基于TOGAF的SOA实施方法论： http://blog.sina.com.cn/s/blog_493a84550100f5c1.html
  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密