[翻译作品]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谈了他的三个“三”: 三种技能:业务、技术与管理,这些是至关重要的。 三种能力:预见力、创新力与领导力。 三种性格特征:激情、亲和、坚韧。



[翻译作品]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)。



  • [翻译作品]2008月5月《RESTful Web Services 中文版》

    - 全球唯一REST专著 - Rails框架发明人David Heinemeier Hansson作序推荐 本书官方网站:http://restfulwebservices.cn 本书China-pub链接:http://www.china-pub.com/39902



    [翻译作品]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



    [翻译作品]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



    [翻译作品]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)的话(可能是用像


    [翻译作品]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):一个模块里的任务的唯一共同之处,就是它们均在此模块之中。



    [翻译作品]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时,人们的态度就会发生改变。



    [翻译作品]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所写的)、政治问题(未能促动一个部门与其他部门分摊重用的成本)以及“一个为了重用目的而发布的服务,也许并未包含某些消费者所需的特性与功能”的情况。 <以下略>



    [翻译作品]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)。 <以下略>



    « 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
    访问次数:5741139
    建立时间:2004年10月30日
    站点首页 | 联系我们 | 博客注册 | 博客登陆

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