World Wide Web Watch | Han XU's Weblog

[翻译作品]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 | 阅读全文(3596) | 回复(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 | 阅读全文(3536) | 回复(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 | 阅读全文(5296) | 回复(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 | 阅读全文(2694) | 回复(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 | 阅读全文(2373) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2006年9月《REST和SOAP的复杂性》 原创空间,  事件记录 全文2006年9月发布于Eric Newcomer博客中文版上：http://blog.csdn.net/ericnewcomer/archive/2006/09/15/1223762.aspx 摘要 Pete对上一篇blog文章的评论已引发出更多的评论。好，让我来尝试回答Pete在他的评论中所提出的问题吧。希望这篇文章能引起更多愉快而有益的讨论。。。­ 在我看来，Pete的主要问题是：哪些Web服务用例（use cases）体现了与REST用例的区别？它们各自应当在什么情况下采用?以及增添的Web服务复杂性在什么情况下是合理的？ 也许这样的回答太过于简单化了，但我认为这是最好的概括：如果你要用浏览器来显示XML数据，那么就采用REST；如果你要把XML数据传给一个程序来处理，那么就采用SOAP。 关于Amazon.com的Web服务的使用情况是：去年，80%的开发者采用了XML over HTTP版，而20%的开发者采用了SOAP版。这是合理的，因为大多数Amazon.com用户所关心的是“用浏览器访问虚拟店铺时的数据显示”。不过，Amazon.com同时支持这两种风格的“Web服务”，因为也有开发者关注于“把数据传给程序作处理”。（为了明确起见，我将采用Amazon的术语——REST和SOAP Web服务）。 看待REST的一种方式是：它基本上意味着把Web服务请求放在URL里。 下面这个URL是我在Google.com中搜索“Skateboots”时得到的： http://www.google.com/search?hl=en&ie=UTF-8&q=%22Skateboots%22&btnG=Google+Search 基本上，Google是把我输入Web表单的关键字作为参数放在URL里（URL里还有其他一些关于字符集和即将执行的操作（比如“搜索”）的信息），并根据此URL来执行 徐涵（Han Xu） 发表于 2008/9/19 16:59:41 | 阅读全文(3363) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2007年11月《顶级专家 Frank van Harmelen 揭秘语义网》 原创空间,  事件记录 全文刊载于2007年11月出版的《程序员》杂志上。 在线阅读：http://www.cqvip.com/qk/80936A/200711/25701386.html 摘要：问：常有人说，语义网（Semantic Web）[1]所要解决的问题，就是30年前人工智能（Artificial Intelligence）里的知识表示（knowledge representation）及归纳逻辑（inductive logics）所要解决的问题。KL-ONE、Cyc以及Minsky的框架（frames）和Sowa的概念图（Conceptual Graphs）等，都属于过去这些工作留下的产物。但是它们都已经失败了。那么语义网以及语义网在本体（ontology）[2]和推理（reasoning）方面的关注，跟这些失败的努力有什么不同呢？ 答：其实，大家对语义网存在一种误解，即认为语义网是“重复人工智能的工作”。虽然语义网和人工智能（AI）所用的工具有一些相同（比如本体、推理、逻辑等），但它们的目标是完全不同的。实际上，语义网的目标是更为适度的：语义网并不是要构建一个通用的、综合性的、基于Internet的智能系统，而是要实现Web上数据集（datasets）间的互操作（无论数据是结构化、非结构化还是半结构化的）——这一目标更具实践性，更为适度。去年七月，Tim Berners-Lee专门就人工智能与语义网之间的混淆做过一个报告：http://www.w3.org/2006/Talks/0718-aaai-tbl/Overview.html。该报告的摘要如下： <略> 问：Web 2.0是一个新事物——无论是学术界还是工业界，人人都喜爱它。而另一方面，语义网却由于众多诺言未能兑现而失去关注。关于这两个Web的共存，您有何看法？您认为Web 2.0将对语义网的发展起到什么样的作用？ 答：注意问题中的“语义网由于众多诺言未能兑现而失去关注”，这是一个错误的前提。 我们来看一些准确的信息： SemTech大会（Semantic Technology Conference）是一个面向工业界的会议，目前为止已经召开过3届，前几届都是在加利福利亚圣何塞（San Jose）召开的。第一年有300人参加，去年有500人参加，而今年的参会人数已经超过了700人。相应地，在欧洲，首届欧洲语义技术大会（European Semantic Technologies Conference）也于去年五月在维也纳召开了。参会人数超过了200人，其中75%都是来自公司的。所以，要么你说错了，要么那几百名公司人士和几十家公司都“脑袋坏掉了”。你自己判断吧。 与此相反的是，语义技术正处于产业突破（industrial breakthrough）的过程之中。下面一段话引自最近（200 徐涵（Han Xu） 发表于 2008/9/19 16:52:14 | 阅读全文(2150) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2007年5月《SOA十大原则》 原创空间,  事件记录 全文刊载于2007年5月出版的《程序员》杂志上。 在线阅读：http://www.cnki.com.cn/Article/CJFDTotal-ITSJ200705045.htm 摘要： 在许多次与客户的接触中，我需要给出一系列基本的SOA原则。 以下各部分介绍了一个面向服务的架构（Service-Oriented Architecture）所应体现的基本原则。这些并非绝对真理，但是在进行SOA相关论述时可以作为一个参考。 你会发现，前四条原则是基于了Don Box提出的四点宗旨[1]，尽管随着时间的推移，其中可能已经掺入了我个人的理解。 1. 显式边界（Explicit Boundaries） 在调用一个服务时，应该向它提供完成其功能所需的全部信息。访问一个服务的唯一途径是通过其公开接口；调用一个服务不需满足任何隐含的前提。“服务与消息传递是紧密联系的，因为消息是进入和离开服务的唯一手段”[2]。一次服务调用不应依赖于共享的上下文；相反，服务调用应该是一种无状态的（stateless）模型。服务所暴露（expose）的接口是由契约（contract）来定义的，契约描述了服务在功能性（functional）及非功能性（non-functional）方面的能力与特征。对服务的调用（invocation）是一个产生业务效果的动作（action），这一动作可能会耗费相当多的资源，并引入跟本地方法调用（local method invocation）或远过程调用（remote procedure call）的错误不相同的一类错误。服务调用跟远过程调用是不一样的。 <略> 2. 共享的是契约和模式，而不是类（Shared Contract and Schema, not Class） 有了服务描述（也就是契约），服务的消费者和提供者便有了使用或提供服务所需的全部信息。根据松耦合原则，一个服务提供者不能指望其消费者有能力来重用提供者在自身环境中提供的任何代码；毕竟，他们所使用的开发或运行环境可能会有不同。本原则严格限制了可在SOA中交换的数据类型。理想的情况是，数据以XML文档的形式被交换，XML文档可以针对一个或多个模式（schema）来进行验证（validation）——这是每个编程环境都支持的。 <略> 3. 策略驱动的（Policy-driven） 要与服务交互，有两个正交的需求集合是必须要满足的：  1. 服务提供者必须在功能、语法和语义方面符合服务消费者的需求，  2. 服务提供者与服务消费者在技术方面的能力及要求必须相匹配。 <略> 4. 自治的（Autonomous） 与“显式边界”原则相关，服务是自治的，因为（至少从SOA的观点来看）接口是服务与外界联系的唯一途径。 < 徐涵（Han Xu） 发表于 2008/9/19 16:41:17 | 阅读全文(2364) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2006年8月《Understanding SOA with Web Services 中文版》 原创空间,  事件记录 国内第一本SOA专著，荣获2006年度CSDN读书频道SOA先锋奖，入选China-pub 2006年度好书榜 China-pub链接：http://www.china-pub.com/30780 内容介绍  深入理解SOA与Web服务，对SOA进行全面介绍的实践指南：简化基础设施，发挥最大的机动性 这是一本关于使用面向服务的架构（SOA， Service-Oriented Architecture）与Web服务技术来简化IT基础设施和增加业务机动性的权威指南。 享有声望的专家Eric Newcomer和Greg Lomow为大家献上了关于SOA计划与实现全方位的实践战略和经证明的最佳实务。作为大受欢迎的Understanding Web Services一书的延续，Newcomer和Lomow在本书中讲述了如何充分利用目前最新的Web服务标准来实现元数据（metadata）管理、安全、可靠消息传递、事务(transaction)及编制(orchestration)。同时，他们给涵盖面广泛的企业级集成与开发难题指出了明确的方法和解决方案。 本书内容包括： ·为何SOA能够成为最具优势的企业集成方法? ·Web服务何以为SOA提供理想的基础? ·所有SOAs所共有的概念：SOA治理、服务契约、Web服务平台、面向服务的开发等诸多内容。 ·实现服务层（service-level）的通信、发现机制、安全、数据处理、事务管理及系统管理。 ·采用SOA实现应用互操作、多渠道客户访问及业务流程管理。 · 关于WS-Security、WS-ReliableMessaging、WS-AtomicTransactions、WS-Composite Application Framework、WS-Addressing、WS-Policy及WS-BPEL等规范的实用教程。 无论您是架构师、开发者或者IT经理，本书都可以帮助您正确理解SOA，并同时实现您的SOA业务目标与技术目标。 “总算有一本第三代的Web服务书籍了。在这本书里，Newcomer和Lomow根据他们多年从事Web服务标准制订和实际应用开发的亲身经验讲述了许多采用SOAs的实践方案。他们的话值得一听。” —Doug Kaye，《Loosely Coupled: The Missing Pieces of Web Services》的作者 IT Conversations节目（www.itconversations.com）的主持人和制作人 徐涵（Han Xu） 发表于 2008/9/19 16:27:23 | 阅读全文(5318) | 回复(0) | 编辑 | 精华 | 删除

[翻译作品]2006年8月 HTML.NET中文版网站 原创空间,  事件记录 HTML.NET中文版网站：http://zh.html.net/default.asp 徐涵（Han Xu） 发表于 2008/9/19 16:20:03 | 阅读全文(2216) | 回复(0) | 编辑 | 精华 | 删除

« 1 2 3 4 5 »