World Wide Web Watch | Han XU's Weblog

[翻译作品]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 | 阅读全文(2153) | 回复(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 | 阅读全文(1916) | 回复(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 | 阅读全文(2023) | 回复(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) | 编辑 | 精华 | 删除

[翻译作品]2008年5月《SPARQL Update将完善REST式SOA方案》 原创空间,  事件记录 全文于2008年5月14日发布于InfoQ中文站上：http://www.infoq.com/cn/news/2008/05/sparql-update-soa 摘要 链接开放数据（Linking Open Data）合作计划已经完成了一个全球性的REST式SOA方案，人们可以通过它访问来自大约50个分布式提供者（如DBpedia、Geonames、MusicBrainz、WordNet、DBLP bibliography和2000 U.S. Census等）的超过20亿个相互链接着的断言（RDF三元组（RDF triples））。所有这些数据都是以RDF（Resource Description Framework，资源描述框架）格式发布的。各数据集均具有具名图（named graph）的结构，你可以基于普通的HTTP GET、通过Cool URI来访问它（参见之前的文章）。 关于如何参与贡献的具体说明可以参见《How to Publish Linked Data on the Web》这篇文章。因为数据集是在不同来源之间普遍互联着的，所有这一切造就了一个大（即便算不上巨大）的机器可读的（machine readable）Web。 如果提供者还实现了SPARQL端点（endpoint）的话（可能是用像 徐涵（Han Xu） 发表于 2008/9/19 17:23:26 | 阅读全文(3404) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2008年4月《内聚对SOA是否重要？》 原创空间,  事件记录 全文于2008年4月发布在InfoQ中文站上：http://www.infoq.com/cn/news/2008/04/soa-cohesion 摘要 早在2005年，当时Steve Vinoski还就职于IONA公司，他就发表过一篇关于内聚（Cohesion）和耦合（Coupling）的文章。在文中，他提到了这些年来已识别的3种“恰当的”内聚类型： 功能内聚（Functional Cohesion）：一个模块只做一件事。它们表现出了低耦合与高度重用。 顺序内聚（Sequential Cohesion）：一个模块包含多个需按一定次序执行的任务。 通讯内聚（Communication Cohesion）：一个模块包含多个基于相同输入的操作，但这些操作在执行次序方面没有任何要求。 然后，他又提到了四种“糟糕的”内聚： 过程内聚（Procedural Cohesion）：与顺序内聚相似，只不过各个任务所处理的数据各有不同。正如Steve所说：“这种内聚常常是‘为降低耦合度，人为把活动分组’的结果”。 时间内聚（Temporal Cohesion）：一个模块里的任务仅在时间上相关。“如果有任务要换在别的时间执行，那么这种模块会带来维护上的难题。” 逻辑内聚（Logical Cohesion）：一个模块里的活动由于“看似具有共同的实现”而被聚集起来。 偶然内聚（Coincidental Cohesion）：一个模块里的任务的唯一共同之处，就是它们均在此模块之中。 徐涵（Han Xu） 发表于 2008/9/19 17:20:22 | 阅读全文(3373) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2007年2月《Web服务已不再Cool》 原创空间,  事件记录 全文于2007年2月17日发布于Eric Newcomer博客中文版上：http://blog.csdn.net/ericnewcomer/archive/2007/02/17/1511436.aspx 摘要 嗯，这是迟早的事。没有一项技术可以永远享有全新技术的称号。在将近七年之后，我想，也终于轮到Web服务了。 Web服务的采纳率继续稳定增长，近期的一次调查（不幸地是，它似乎混淆了Web服务与SOA）显示，SOA的采纳正在增加，并且确实带来了生产率的提高。 这一迹象似乎与近来关于SOAP的批评公然抵触。 那么，这一切意味着什么呢？这意味着，不可避免的批判就要开始，这种批判会在一项Cool技术进入主流时发生。就好比，人们喜爱独立乐队，但当它卖出了一百万张CD时，人们的态度就会发生改变。 徐涵（Han Xu） 发表于 2008/9/19 17:10:53 | 阅读全文(5127) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2006年11月《重用，仍旧很困难吗?》 原创空间,  事件记录 全文于2006年11月13日发布在Eric Newcomer博客中文版上：http://blog.csdn.net/ericnewcomer/archive/2006/11/13/1382558.aspx 摘要 SOA的许多优点来源于服务重用。软件重用这一概念已经被宣传多年，并被建议为多种技术所采纳。服务是设计和实现可重用软件的一个很好的抽象层次，而且XML和Web服务较它们之前的技术更易于使用。可是，重用仍旧很困难吗？ 下面我谈谈我所认为的David Chappell最近那篇关于重用的文章的主要内容。 他说，几乎在最近两年里与他交谈过SOA的每一个人都说“利用服务实现重用，几乎跟利用对象实现重用一样困难”。 因为对象未能真正兑现实现重用的承诺，而服务要实现重用也未必十分容易，所以David通过交谈得出的结论仿佛是说业界将会再次失败。 他引述了在创建可重复服务时常见的问题，包括开发者面临的文化挑战（就像我的同事Steve所写的）、政治问题（未能促动一个部门与其他部门分摊重用的成本）以及“一个为了重用目的而发布的服务，也许并未包含某些消费者所需的特性与功能”的情况。 <以下略> 徐涵（Han Xu） 发表于 2008/9/19 17:08:23 | 阅读全文(2524) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2006年10月《复杂性话题之总结》 原创空间,  事件记录 全文2006年10月14日发布于Eric Newcomer博客中文版上：http://blog.csdn.net/ericnewcomer/archive/2006/10/14/1334306.aspx 摘要 我想在开始其它话题之前，先对复杂性话题（包括对SOAP和REST的比较）的讨论做一个总结。 我仍然觉得拿一个XML示例作尝试会比较有趣，我希望不久可以去做。 感谢所有发表评论参与讨论的朋友们。我期望进行讨论，我如愿以偿了 ;-) 。 好，那么我学到了什么呢？ -- 我仍需对REST作许多了解（再次就前文中的不当表述致歉） -- REST对程序之间的通信确实比较有用，所以认为REST属于“Web服务”是合理的（Amazon.com亦持此态度）。 -- 对简单应用来说，REST比SOAP更具优势，而且对于许多应用来说，REST的成本更低。 -- 在工具支持、接口定义语言（WSDL）和企业级服务质量（可靠性、安全性、事务性）方面，SOAP胜过REST。 -- 对于既有简单需求、又有复杂需求的应用而言，将REST与SOAP解决方案相结合似乎是很有道理且切合实际的。 -- 对软件公司过分炒作Web服务的不满情绪仍大量存在，WS-*规范的迅速激增并无帮助（没错，现在又增加了一个WS-Management）。 <以下略> 徐涵（Han Xu） 发表于 2008/9/19 17:05:43 | 阅读全文(2213) | 回复(0) | 编辑 | 精华 | 删除

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