[翻译作品]2008年9月《WOA治理不同于SOA治理》

全文于2008年9月1日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/09/woa-governance 摘要 先不论它讲的是WOA而不是REST这点,在最近的一篇文章里,Dan Foody讨论了治理基于Web的架构。 有人可能会说,是SOA自身的复杂性(受企业自上而下的宗旨影响)造成了它需要正规的SOA治理活动。若没有正规的SOA治理,你就不能指望SOA成功,因为它太容易出错了。 他认为,WOA设法避免了SOA的许多复杂性,因而就不需要复杂的工具或WS-*架构了。(我们假定Dan Foody是知道许多人不乐意在SOA和WS-*之间划等号的。)当然,也有人认为,在必须要实现复杂应用且需要WS-*时,采用REST(也就是WOA)并不简单,但我们先不管这些,因为这里我们主要关注的是Dan Foody的核心问题:“WOA仍然需要治理吗?“。 回答多半是肯定的(如果你是一名企业架构师的话,现在可以不用紧张了)。但我认为“WOA治理“的方式将与SOA治理存在根本的不同(好,这下企业架构师们又该紧张了)。 原因是什么?在传统的SOA中,你通常会任命一名企业架构师来设置规则,对提供者与消费者之间的交互加以治理。 假如企业中所有信息经过逐级向上汇报之后最终能汇聚于同一个人,那么这个办法很好。 <以下略>



[翻译作品]2008年9月《调查显示,SOA失败?》

全文于2008年9月1日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/09/survey-soa-failure 摘要 最近有篇报道指出SOA失败、而面向Web的架构(Web Oriented Architecture,WOA)成功,对此Assaf Arkin提出了质疑。他针对的是一篇Information Week文章中的调查结果,该文说道: IT专业人士们已经对SOA许诺的投资回报表示出了怀疑。InformationWeek 2007年对278位IT专业人士进行的一次网络调查显示,有32%的SOA使用者说他们的项目没有达到期望目标。而这些人之中,有58%说SOA项目给他们的IT环境增添了更多复杂性,有30%说他们花去的成本超过了预期。在所有提供反馈的SOA用户之中,只有10%说结果超出预期——这一结果与Nucleus研究公司的调查结果一致,他们调查发现,在106家接受调查的机构中,只有37%真正通过SOA技术和计划实现了投资回报。 他将此看成是软件开发的行业平均水平,并认为“考虑到行业水平就那样,这个结果并不是那么糟糕或令人沮丧。这就是平均水平”。他说: 会发生改变的,并不是成功率,而是成功者做更多有意义工作、并做得更好的能力。 你有可能实现的事物范围,那才是会发生改变的地方。 不会改变的是行业平均水平,以及那些讲述平均水平的文章,它们脱离实际地运用统计数字来证明观点,看似不错实则什么也没说。这篇文章还有另一些可怕的错误,不过就这个错误是引人注意的,因为谬论往往传播得广泛而深远。 <以下略>



[翻译作品]2008年8月《为SOA设立卓越中心》

全文于2008年8月27日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/08/SOACOE 摘要 卓越中心(Centers of excellence,COEs)是成功引入新的架构、技术和方法的有效方式。许多公司EAI/B2B的成功实施均得益于卓越中心的设立。Ravi Subramaniam最近探讨了为SOA设立卓越中心的过程 SOA卓越中心是一个负责吸收并推广最佳实践、知识及实用性前沿方案的组织。卓越中心(COE)为各SOA行动确立了严格性与纪律性,并给SOA行动带来好处:增强技能与能力,保持愈渐复杂的SOA行动的成功执行。 按照Ravi的说法,设立SOA卓越中心涉及以下主要活动: 定义任务说明、章程及目标。尽管不同机构会有不同的实际定义,但回答以下问题有助于把定义明确和精确化: SOA卓越中心要解决什么业务问题?一个典型的回答可能是:提高新流程或服务的上市速度,以期提高投资回报。 SOA卓越中心要解决什么技术问题?对此的回答可能是:在技术标准及最佳实践方面提供指导,确保架构符合机构的长期需要。另外,CIO也许会指出,它要成为一种确保正确实现SOA的治理机制。 就广泛的范围来讲,SOA卓越中心有哪些活动?答案也许是:跨越服务生命周期(从构思,到创建,到停用)的各种活动。积极参与选择技术标准、评估和挑选工具、宏观和微观设计、开发、测试、实现、重用以及安全方面等等。 SOA卓越中心将如何与项目团队来往? SOA卓越中心将如何贯彻治理活动? SOA卓越中心将如何贯彻质量标准并确保遵守设计方针与最佳实践? 定义卓越中心的组织架构。对卓越中心来说,极其重要的一点就是要有来自全公司各主要营业范围的业务与技术代表。另外,卓越中心还要有对以下领域有知识与经验的全职IT架构师: 企业架构(Enterprise architecture) 安全(Security) 风险与合规管理(Risk and compliance management) 质量管理(Quality management) 基础设施与应用执行(In



[原创作品]2008年8月《SOAP协议栈是令人尴尬的失败?》

本文于2008年8月12日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/08/rest-vs-soap-stack 摘要 关于REST vs. SOAP的争论已不是什么新鲜事了。然而,现就职于Sun公司的XML权威Tim Bray近期的一番话再次引发了这一争论。在OSCON上接受采访时,Tim Bray说:
目前,SOAP协议栈通常被认为是一个令人尴尬的失败……SOAP协议栈能做的,REST也能做,而且在可行性、优美性、代价和经济上更优于前者,只是我们尚缺乏相关工具。
跟以往的情况一样,双方的支持者们纷纷出动并发言支持自己所钟爱的风格。他们在Service-Oriented-Architecture Yahoo!讨论组上的辩论已经形成了一个有超过150条回复的主题。争论中,Nick Gall给出了一个已抛弃SOAP技术的大公司的案例: 好几年前,沃尔玛将其供应链的VAN EDI基础设施替换成为EDIINT AS2,并一直愉快地沿用至今。AS2本质上属于普通老式XML(Plain Old XML,POX),它用自己的方法实现了可靠消息传递的幂等性。
Mark Baker补充道: 我一直都说SOAP不会在防火墙以外获得广泛使用的。
在谈到什么样的例子才能被算作一个使用SOAP的成功案例时,Nick Gall


[翻译作品]2008年8月《Gartner:企业中新兴的SOA模式》

全文于2008年8月15日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/08/gartner-emerging-soa-patterns 摘要 正如Tony Cook在Jeff Schneider的博客上发文所说,Gartner分析师们发现以下5种SOA设计模式获得了较多地采用 1. 多渠道应用(Multi-channel Applications) 2. 合成应用(Composite Applications)3. 业务流程编配(Business Process Orchestration)4. 面向服务的企业(Service Oriented Enterprise)5. 联邦的SOA(Federated SOA) 文中的战略规划假定(strategic planning assumptions)指出了在企业采用这些模式的活动时间表中的某些关键趋势。 <以下略>  



[翻译作品]2008年9月《用消费者驱动的契约进行面向服务开发 》

全文于2008年9月8日发布于InfoQ中文站上:http://www.infoq.com/cn/articles/consumer-driven-contracts 摘要 向SOA过渡给软件开发生命周期带来了许多新的挑战:机构只有形成一种明确面向服务的开发能力,才能战胜这些挑战。 本文为提高机构的服务开发能力提供了一些实践性建议。本文将先概述SOA给软件开发生命周期带来的一些挑战,然后讲述以“服务故事(stories for services)”和服务开发线(service development streams)间交换的单元测试为形式的消费者驱动的契约(consumer-driven contracts)何以能够增强面向服务开发的生命周期。 SOA给开发带来的挑战 面向服务(service orientation)不仅仅是采纳一种新的架构这么简单。若机构仅使其架构变得更加面向服务、而不对其开发技术作相应改变的话,那么SOA行动肯定要失败。 在启动、构建及运营服务方面的一些挑战包括: 在启动阶段,服务功能的描述必须能在多种场合下被重用:粒度既不能粗到仅在一种特定场合下能被重用,也不能细到要做大量补充工作方可在不同场合下被重用。 在构建服务时,我们必须确保提供者与消费者可彼此独立地进行演化。如果一项服务功能的消费者们必须随提供者改变而改变,那么该服务就不是真正松耦合的。 在运营服务时,我们需要理解各个服务之间的关系,以便我们可以诊断问题、评估服务可用性(availability)发生变化(常常是去除)时将产生的影响、并为各服务针对新的或变化的业务需求而演化设计计划。 从整体资产的角度来看,各服务的具体开发生命周期必须彼此协调一致,且没有不恰当地将各方拴在一个一体的、极其缓慢的、最终无法实行的活动时间表之上。 SOA给软件开发生命周期带来的挑战源于服务资产的联邦特性。有价值的业务成果不再是由那些“具有单向时间活动表,以及所有权、预算和运营边界都分散”彼此相隔的应用实现了;相反,它们是通过那些“拥有各自独特的服务开发生命周期的”服务之间的交互实现的。然而,协调好这些生命周期并不是一次搞定就完事了的。相反,正如我们将看到的,我们需要识别出一组代表着“对交付一个共同结果的承诺”的协作活动与制品(collaborative activities and artefacts)。这些活动与制品为时刻(若简单地看)将各条开发线联合起来提供了基础。 用敏捷方法实现SOA,意味着及早交付高价值业务成果且常常需要频繁地发布版本。若机构试图采用这种方法,那只会进一步加剧开发挑战。尽管其名称如此,但许多人认为敏捷的软件交付方式对与SOA相关的机构敏捷效益是不利的。由于在一个服务间存在着很多已知关联的环境中发布新版本的服务会有运营风险,所以敏捷方法频繁发布版本这一做法常被免去。而且,虽然敏捷鼓励各方进行密切及时地协作,但这种活动难以跨越多个不同服务及其生命周期进行协调。 联邦期望 传统的烟囱式应用开发把



[翻译作品]2008年7月《真正成功的SOA项目5个里才1个》

全文于2008年7月28日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/07/Only1 摘要尽管SOA渐受欢迎且SOA技术在不断进步,但根据Burton集团Anne Thomas Manes所做的SOA调查, ……对20家公司的深入调查发现,完败率达50%,未完败亦未成功者比例达30%……它们中有许多已部署了多个成功的项目,但这些项目大多只关注于一种集成问题。它只是一堆Web服务……该服务只为一个应用而构建,而且肯定不会被再次使用 该调查结果得到了若干新闻报道的响应,比如Joe McKendrick和Michael Meehan均同意Anne的观点:这些失败案例的原因,总的说来不是技术做得不好,而是在业务/架构上缺少SOA的眼光,更确切地说 缺乏已定义的业务模型 基础设施焦点 治理仅涉及基于SOAP的系统,若存在治理的话 开发者未能利用现有的运行时治理 行动由应用开发组独立参与并领导 路线图不够具体 无力衡量投资回报(ROI) 以项目为中心的文化 “我特殊”的态度 按Burton集团应用平台战略与数据管理战略副总裁Chris Haddad的话说: 失败的SOA项目将过多的关注投在了方法而非目标上。问题在于未能关注业务目标,所以对它们予以关注即可解决问题。有时在构建SOA的业务案例时未能对最基本的问题进行提问,如:我们为什么要构建服务?最后结束时意味着什么?……虽然SOA的业务驱动力之一是降低成本与赢得投资回报(ROI),但SOA的投资回报仍是一个难以捉摸的目标,于是SOA项目负责人常在涉及投资回报的地方赌运气。 Burton集团发现成功的SOA项目具有以下共同点: 业务与IT重组,常常



[翻译作品]2008年7月《Progress软件收购IONA和Mindreef》

全文于2008年7月27日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/07/progress-aquisitions 摘要 在过去的两周里, Progress软件收购了两家公司——IONA科技和Mindreef,以期拓展其SOA产品系列。该产品系列包括以下种类的产品:企业服务总线(Sonic ESB)、企业消息传递(Sonic MQ)、数据互操作(DataXtend)、主机集成(Shadow)、复杂事件处理(Apama)及SOA管理(Actional)。IONA是CORBA集成技术方面的业界领军者,它所销售的SOA基础设施产品套件Artix由一个ESB,以及SOA注册库、编配引擎、主机集成与元数据管理等构成。它还通过其FUSE产品线提供开源的SOA集成组件。Mindreef是SOAPscope的生产厂商,那是一个受欢迎的SOAP质量、测试与诊断套件。 Bulter Group分析师Rob Hailstone分析了本次收购: 它是一个模块化的产品集合,用户可以只选取那些当前项目需要的部分、以后再进行功能扩展。这与Progress不试图向其客户强加单一厂商方案的做法很是相称。 Rob指出,由于两家公司目前有着不同的伙伴关系,所以“还存在一些伙伴牵连”



[翻译作品]2008年7月《IT的工业化?》

全文于2008年7月22日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/07/it-cdl 摘要 这些年来,我们看到了不少关于WS-CDL的讨论。比如,Gregor Hohpe在会谈中提到过它,另外目前至少有两个实现。但跟它的远房兄弟WS-BPEL不同的是,WS-CDL尚未能够引起关注(在技术发展曲线上亦处于落后地位)。这是件令人遗憾的事,就如我们之前所评论的那样:如Jeff Schneider 所说: 虽然原始的WS-CDL规范不足以给人留下深刻的印象,然而,这个概念是非常好的。我还没有回过头来重新审视这份规范,但我迟早会这样做。人们要花上一段时间才能理解BPEL其本质中存在的“集中化(centralization)”问题。在此之前,其它可选方案都被极大的忽视了。 或如Charlton Barretto所述: CDL提供了一种方法,可以掌握每一利益相关者其各自每一层次的细节,而不必将这些细节暴露于他人。这使得企业利益相关者、业务分析师、企业架构师及应用工程师们可以同步的分享他们关于同一系统的看法。而且,CDL提供了必要的出处(provenance),以在各层面贯彻需求。以这种方式,CDL提供了模型化、描述及实现架构(architecture)的方式,做到了对SOA中的“A”的支持。 为助一臂之力,Steve Ross-Talbot打了个有趣的比方。他



[翻译作品]2008年6月《SOA定义的松耦合》

全文于2008年6月19日发布于InfoQ中文站上:http://www.infoq.com/cn/news/2008/06/loose-coupling-soa 摘要 在那场关于内聚对SOA是否重要的争论中,Carlos Perez表达了他关于软件构造中的耦合(coupling)及其在SOA领域的演变的观点。他首先给出了Bertrand Meyer的模块性原理(principles of modularity),然后将之延伸到自己的一套面向服务的原则上。 Carlos首先引用了Bertrand Meyer的模块性原理的原文: 模块可分解性(Modular Decomposability)——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足模块可分解性。 模块可组合性(Modular Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足模块可组合性。 模块可理解性(Modular Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于模块可理解性。 模块连续性(Modular Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足模块连续性。 模块保护性(Modular Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足模块保护性。 <



« 1 2 3 4 5 6 7 8 9 10 »

日历 | CALENDAR

«Mar.2020»
1234567
891011121314
15161718192021
22232425262728
293031
blog名称:World Wide Web Watch
日志总数:193
评论数量:664
留言数量:75
访问次数:5741132
建立时间:2004年10月30日
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.063 second(s), page refreshed 144382249 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号