World Wide Web Watch | Han XU's Weblog

[翻译作品]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相关的机构敏捷效益是不利的。由于在一个服务间存在着很多已知关联的环境中发布新版本的服务会有运营风险，所以敏捷方法频繁发布版本这一做法常被免去。而且，虽然敏捷鼓励各方进行密切及时地协作，但这种活动难以跨越多个不同服务及其生命周期进行协调。 联邦期望 传统的烟囱式应用开发把 徐涵（Han Xu） 发表于 2008/9/19 19:23:09 | 阅读全文(1960) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]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重组，常常 徐涵（Han Xu） 发表于 2008/9/19 19:19:22 | 阅读全文(4990) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]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指出，由于两家公司目前有着不同的伙伴关系，所以“还存在一些伙伴牵连” 徐涵（Han Xu） 发表于 2008/9/19 18:30:10 | 阅读全文(2006) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]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打了个有趣的比方。他 徐涵（Han Xu） 发表于 2008/9/19 18:28:34 | 阅读全文(1990) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]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）——如果一种方法，在由它得到的架构中，一个模块在运行时出现异常条件不会影响到该模块之外（或最多只蔓延到少数周边模块），那么该方法就满足模块保护性。 < 徐涵（Han Xu） 发表于 2008/9/19 18:26:35 | 阅读全文(2041) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008年6月《SOA卓越中心是必需的吗？》 原创空间,  事件记录 　全文于2008年6月17日发布于InfoQ中文站上：http://www.infoq.com/cn/news/2008/06/soa-coe 摘要 上周，SOA联盟（SOA Consortium）发布了一个座谈会的音频文档，该座谈会讨论了SOA卓越中心（Center of Excellence，CoE）的作用与实用性，以及人员技能。[译注：SOA卓越中心（Center of Excellence，CoE）或能力中心（Competency Center，CC）是一个跨职能的团队，他们负责处理在实施SOA的过程中新出现的组织性问题。] Bruce Henderson（Savant）、David Butler（HP）、Rich Reba（CSC）和Melvin Greer（Lockheed Martin）等参加了本次座谈。 Bruce认为：     洞察力、政治头脑以及沟通是极为重要的技能……缺乏这些技能，卓越中心（CoEs）是难以成功的。寻找技术型与学术型人才并不难。 David首先认为： 卓越中心（COE）意味着“传道中心（Center of Evangelism）”。 他认为，首先要看组织的成熟等级。通常在流程、文化和架构等多个方面会发生转变。在准备对应用进行革新时： 卓越中心的部分工作是考虑哪些资产（asset）可以革新，然后为它们定义有价值的业务服务。他们将以多种不同的方式负责将治理（Governance）自动化……了解服务生命周期（Service Lifecycle）与代码生命周期（Code Lifecycle）或方案生命周期（Solution Lifecycle）存在很大不同，这是很重要的。 David建议分别设立管理组、技术组与财务组。他认为： 如果你认为不需要CoE，那么你就无法得到SOA。SOA CoE是给你带来SOA的“产品”[1]。 Rich谈了他的三个“三”： 三种技能：业务、技术与管理，这些是至关重要的。 三种能力：预见力、创新力与领导力。 三种性格特征：激情、亲和、坚韧。 徐涵（Han Xu） 发表于 2008/9/19 18:07:46 | 阅读全文(2126) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008年6月《WfXML-R：基于REST的流程整合》 原创空间,  事件记录 全文于2008年6月5日发布于InfoQ中文站上：http://www.infoq.com/cn/news/2008/06/wfxml-r 摘要 Patrice Cappelaere最近宣布，WfXML-R——一种为WF-XML 2.0提供REST式绑定的提议——已经得到了工作流管理联盟（Workflow Management Coalition，WfMC）的接纳。 WfXML-R旨在围绕WfMC的参考模型里的5个接口建立规范： 接口1：在流程定义（process definition）与建模工具和工作流引擎之间定义一个标准接口。 接口2：为客户端应用向工作流引擎请求服务（为了控制流程行进、活动及工作项目等）定义APIs。 接口3：为APIs定义一个标准接口，以便工作流引擎可以通过公共代理软件来调用各种各样的应用。 接口4：定义工作流互操作模型以及相应的支撑标准。 接口5：定义监测和控制功能。 目前在0.4版中，WfXML-R考虑了对以下用例（use cases）的支持： 远程应用需要发现并从服务器获取一个可用工作流、定义及其他可用资源的列表。 远程应用需要能够启动（和停止）一个流程实例（process instance）。 徐涵（Han Xu） 发表于 2008/9/19 18:04:18 | 阅读全文(2152) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008月5月《RESTful Web Services 中文版》 原创空间,  事件记录 - 全球唯一REST专著 - Rails框架发明人David Heinemeier Hansson作序推荐 本书官方网站：http://restfulwebservices.cn 本书China-pub链接：http://www.china-pub.com/39902 徐涵（Han Xu） 发表于 2008/9/19 17:57:41 | 阅读全文(1915) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008年8月《REST反模式》 原创空间,  事件记录 全文于2008年8月4日发布于InfoQ中文站上：http://www.infoq.com/cn/articles/rest-anti-patterns 并转载于2008年9月出版的《程序员》杂志上：http://blog.csdn.net/programmer_editor/archive/2008/08/26/2831730.aspx 摘要 人们在试验REST时，通常会四处寻找样例——而他们往往不仅能找到一大堆自称“符合REST”或标榜为“REST API”的样例，还会发现许多关于某个自称符合REST的特定服务名不副实的讨论。 为什么会这样？HTTP虽不是什么新事物，但人们使用它的方式却五花八门。其中有些做法符合Web设计者的初衷，但许多并非如此。要为你的HTTP应用（无论是面向人类、还是计算机、或同时面向这两者使用的）应用REST原则，意味着你要恰好反过来：尽量“正确地”使用Web，或者说按符合REST的方式使用Web（倘若你不喜欢用对或错来评判的话）。对许多人来说，这的确是一种崭新的方式方法。 我经常在文章里作同样的声明：REST、Web和HTTP是不同的事物；REST可以用多种不同技术来实现，而HTTP只是一种恰好符合REST架构风格的具体架构。所以，其实我应该小心区分“REST”与“REST式HTTP”这两个概念的。但我没有这么做，在本文剩余部分，我们姑且认为它们是相同的事物。 跟任何新的方式方法一样，发掘一些共同的模式是有益的。在本系列的第一和第二篇文章中，我已经讲述了一些基础——比如集合资源的概念、将计算结果转换为资源本身、以及用聚合（syndication）来模仿事件。后续文章将进一步讲述这些及其他模式。不过在本文中，我想主要说说反模式（anti-patterns）——即那些力求符合REST式HTTP、但未能成功而造成问题的典型做法。 首先我们来看看我发掘了哪些反模式： 全部采用GET 全部采用POST 忽视缓存 忽视响应代码 误用cookies 忘记超媒体 忽视MIME类型 破坏自描述性 下面我们来逐个详细说明。 全部采用GET 在许多人看来，REST仅仅意味着用HTTP暴露一些应用功能。HTTP GET是最重要的基本操作（operation ）（严格地讲，用“动词（verb）”或“方法（method）”这样的术语比较好）。GET方法应当用于获取由URI标识的资源的一个表示（repres 徐涵（Han Xu） 发表于 2008/9/19 17:55:26 | 阅读全文(2022) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008年5月《解答有关REST的十点疑惑》 原创空间,  事件记录 全文于2008年5月22日发布在InfoQ中文站上：http://www.infoq.com/cn/articles/tilkov-rest-doubts 并转载于2008年8月出版的《程序员》杂志上：http://www.cnki.com.cn/Article/CJFDTotal-ITSJ200808052.htm 摘要： 在了解过REST之后，你肯定很想知道这个概念在你的实际应用当中究竟能派上多大用场。而且，假如你已经熟悉另一套完全不同的架构手法的话，那么你担心“REST或REST式HTTP（RESTful HTTP），是否真的能在实践中派上用场，还是在介绍性的、‘Hello, World’级场景以外就不灵光了”是很正常的。我将在本文解答人们——尤其是那些深谙基于SOAP/WSDL的Web服务架构手法的人——开始研究REST时容易产生的关于REST的十点疑惑。 1. REST也许适用于CRUD，但并不适用于“真实的”业务逻辑 这是那些对REST的好处持怀疑态度的人最常见的反应。毕竟，要是你只能create/read/update/delete，那你如何表达更复杂的应用语义呢？我已经在本系列介绍性的文章中探讨过这些被大家所关心的问题了，不过这方面绝对值得进一步讨论。 首先，HTTP动词（verbs）——GET、PUT、POST和DELETE——跟数据库的CRUD操作并不是一一对应的。例如，POST和PUT都可用于创建新资源，它们的区别在于：PUT请求是由客户端决定（被创建或更新的）资源的URI；而POST请求是向一个“集合（collection）”或 “工厂（factory）”资源发出的，是由服务器来指派URI的。不过无论怎样，我们回到那个问题：如何应付更复杂的业务逻辑呢？ <略> 2. 没有正式的契约与描述语言 从RPC到CORBA，从DCOM到Web服务，我们已习惯于拥有一个“列出操作、名称及输入输出参数类型”的接口描述（interface description）了。没有接口描述语言的话，REST怎么用呢？ 就这一被十分频繁问到的问题，有三点答复。 首先，假如你决定用XML（这是很普遍的做法）来配合REST式HTTP的话，那么各种现有的XML模式语言（schema langua 徐涵（Han Xu） 发表于 2008/9/19 17:45:25 | 阅读全文(3176) | 回复(0) | 编辑 | 精华 | 删除

« 1 2 3 4 5 »