博文

目前显示的是标签为“SOA”的博文

SOA(Service-oriented architecture) - cloud

From :  b log .sina.com.cn/ s /blog_493a845501017oyh.html SOA系统的松耦合特性决定了这样的系统天生具有灵活性——当外部环境发生改变时,SOA系统可以随之简便而快捷地进行调整。在云计算、企业移动、大数据 和社交商务兴起之际,依靠与生俱来的灵活性,下一代SOA化解了IT环境所拥有的高复杂性,简化了企业IT架构的建设,并充分外延,打上了云计算和企业移 动的新标签——传统SOA专注于企业内部信息和应用的整合,下一代SOA则从企业内部延伸到外部,从技术层面上升到业务层面。 集成范围的变化 集成的类型,原来关注业务系统间的集成,扩展到物联网更多硬件终端集成,移动客户端的集成。SOA集成的组织范围会从企业内扩展到企业外,特别是云计算推荐,很多企业私有能力会转化为公有云提供的公有云服务。 再说集成对象的进一步深入,原来关注的是业务系统间的集成,但是随着SOA组件化架构概念的推进,会强化业务组件而弱化业务系统,原有业务系统的集成会转化为业务组件间的集成。同时对于业务组件内部也推进SOA架构和领域服务思想,推动内部应用和服务的软总线集成。 SOA和云的融合 在前面文章谈SOA和云计算的关系,说到过SOA重点是集成能力本身不产生能力,云平台是既产生能力又提供能力。在融合以后我们看到核心就是服务能力提供中心,应用从用户和消费者的角度来看,并不关心是集成的能力还是集中提供的能力,只要最终满足需求即可。 在云平台推进过程中,可以看到不断有共性能力从原有的业务系统中移出,转化为云平台统一提供的能力和服务,因此从SOA集成角度也发生变化,需要和提供这些服务的云平台进行服务集成。 从远期规划来看,云平台提供共性的平台层能力,包括各种技术能力(消息,日志,缓存),也包括各种平台能力(流程引擎,规则引擎,4A)等。原有的业务系统转化为业务组件,业务组件提供业务能力和服务,这些服务最终都接入到服务总线,提供统一的服务目录。 SOA和BPM的融合 这个相当重要,SOA两大基本功能,一个是识别可重用服务并接入ESB,形成服务目录库和能力提供中心;第二就是服务组装和编排,为BPM业务流程整合服 务。没有可复用的服务资产库做支撑,BPM基本无法落地,没有真正做到BPM这一层,那么SOA的业...

SOA(Service-oriented architecture)

图片
 From : b log.sina.com.cn/ s/blog_7ea3d46f01017jjw.html 2007 年,在一个偶然的机会投入到了移动集团级全国范围内的大型项目建设,也就是从那里开始了我的 SOA 职业生涯。至今还一直从事着这样事业,大大小小数十个项目,不乏接触很多系统间集成、很多业务流程梳理,从研发 -- 实施 -- 推广 -- 维护 -- 治理,通过各个环节的不同视角反复推敲 SOA 的实施究竟为企业信息化产生了多少价值。常思考、多总结的习惯也让自己对 SOA 有了更深入的一些认识。 认识 SOA                 那么什么是 SOA 呢? SOA 的技术体系标准规范是什么呢? SOA 的产品家族都有什么功能? roadmap 是什么?标准模型是什么?学习成本有多高?最佳实践是什么?是不是找一个技术框架发布或消费调用几个 Web Service 就叫做 SOA 了呢?带着这些疑问,查找了很多资料,也得到了很多定义,比如 SOA 是一门架构方法、 SOA 是一个组件模型、 SOA 是一个 IT 体系结构、 SOA 是一套设计思想,等等。定义相当的多,或许是不同的书本看问题的角度不同,就像盲人摸象得到了不同结论。而这往往造成雾里看花,貌似总是隔着一层纸,始终看不清,究竟 SOA 是什么!                 其实看待任何事物是什么的时候,从古至今最为直接的方式无非就三个步骤。第一,认识其外观;第二,了解其特性与功能;第三,分析其使用价值。因此在给 SOA 下定义之前,我们不妨通过这三个步骤了解一下 SOA 。 1 )第一步洞悉 SOA 的外观与组成 : SOA 并不是一个看得见摸得着的软件产品,也不是一套技术体系或标准规范。很多时候,会对 SOA 和 Web Service 产生混淆或误解。 从本质上来说, SOA 是一种架构模式,而 Web 服务是利用一组标准实现的服务。 Web 服务是实现 SOA 的方式之一。 那么究竟 SOA 的外观样貌是什么呢?下图可以对其技术体系结构有所...