使用NetKerne实现REST风格的ESB
Jeremy Deane对使用NetKernel来编写REST风格的ESB应用做了一番深入的研究。他详细地剖析了选择商业ESB应用的决策过程,以及最终如何使用NetKernel来实现该应用。
作者 Arnon Rotem-Gal-Oz译者 胡键 发布于 2007年6月12日 下午7时49分
追踪上周在此讨论的关于REST vs. WS-*的争论,值得注意的是,以REST化服务契约为主题的争论在最近几天日嚣尘上。浮现出的问题是REST是否需要契约(即按照WSDL的方式),更更根本的问题是有了契约的REST还依旧是REST吗。Aristotle Pagaltzis的问题:“REST需要服务描述语言吗?” 揭开了争论的序幕:
“日前,有人在rest-discuss发问是否有描述REST服务的标准方法。该问题一再露面(作为回应,通常会画一个指向WADL努力的箭头),似乎意味着关于REST的一个流行的误解。我认为使用类WSDL语言描述REST化服务根本就是自相矛盾的说法……”
对此,Paul Mueller 回应道:
“此处,我们讨论的是契约。契约必须以某种方式正规化。英语并非最好的使用语言,尤其是因为我们有如此多的更精确语言可供选择。
我的这个想法这实际上是对我关于数据序列化想法的扩展,服务只是需要被元描述的下一级事物。”
Mark Baker紧跟而上,他同意Aristotle的观点:REST拥有(以及需要)的唯一契约就是以4个动词为基础的HTTP协议,这4个动词是——POST、GET、DELETE、PUT(事实上HTTP 1.1还定义了另一个动词 - HEAD,但是它使用并不广泛)。Mike Herrick 认为契约确实能增加价值:
“我认为,REST客户端开发者至少期望能有模式,用来定义在请求/响应有效负荷中想出现的东西。恕我直言,WADL做了非常不错的工作,而且没有画蛇添足。如我所说,与WSDL相比较,它是个不错的东西。当HTTP是唯一选择的时候,事情是如此的简单(即,相比于愚蠢的协议不可知论调)。如果你不打算使用WADL,那你就不得不将服务以枯燥无聊的方式文档化。至少,WADL看起来是一种真正简化文档事物的方法。”
Bobby Woolf(因企业集成模式而闻名)同样认为REST需要声明性接口并怀疑当REST最终获得这些能力时,结果是否还会与WSDL有什么显著不同。John Heintz建议在其间做些手脚,使用他称之为路标的东西,而非描述语言。他的想法是:路标在运行时可以被解析,这将使它们适于改变。问题的症结似乎是:服务消费者对于接口的信心,它由它们所消费的服务定义。这个视角始于Stefan Tilkov的评论,他认为存根(stub)和骨架类(skelton)有问题。Don Box回复说你必需对你得到的消息结构有信心。对此,Stefan的回应:
“我同意这一点——我的代码就依赖文档中一些元素和属性。但问题是,即使我的应用只访问它所需要的XML中20%的元素和属性,列集(散列)/序列化(反序列化)((un)marshaling/(de)serialization)代码同样要求在XML和模式之间进行完美地匹配。目前代码产生时就是如此。换句话说:尽管我的应用代码能容忍至少一些变动,但是产生的底层代码则不行。”
Mike Glendinning的评论强调了Stefan的观点,他认为当用户只使用返回消息的20%时,为其本身定义新契约更有效。或者如Joe Gregorio写下的(在一个相当长的Q&A风格帖子中,它通篇都是关于我们是否需要WADL):
“Q:人们打算想要描述接口,那有什么坏处?A:是的,人们想要描述接口,并且那些描述是脆弱的。如果今天我下载一个WADL并编译我的客户端,那么明天就会因你改变服务而崩溃。相反,如果你使用超文本(在链接后跟超文本和客户端状态,或基于超文本和客户端状态构造请求),那么当你改变服务器或URI结构时,接口将不会被破坏。”
最后,考虑到上文Stefan博客中的2条评论,问题可能比“REST是否需要正式的契约”更根本,即“我们需要接口吗?”。首先看看Steve Jones的评论:
“契约是个好东西,这已经是被证明的了,我仍然奇怪为什么REST人们不喜欢它们。它几乎是理论和实践的东西,在理论上并没有规定,在实践上却是如此。”
与Eric Johnson所说相比较:
“……就我看来,被REST所吸引(不论以什么形式)的人们,是反抗基于接口的编程而甚于WS-*本身——至少我的理由是如此……”查看英文原文:Debate: Does REST Need a Description Language?。
Jeremy Deane对使用NetKernel来编写REST风格的ESB应用做了一番深入的研究。他详细地剖析了选择商业ESB应用的决策过程,以及最终如何使用NetKernel来实现该应用。
当多个敏捷开发团队在同一个代码库上进行工作时,如何在保证混乱最小化的同时,还能在每个迭代结束时拥有一个干净的、可发布的软件版本?Henrik Kniberg在本文中罗列出了在“Scrum and XP from the Trenches”迷你书中所使用的策略要点。本文并非为版本控制专家编写,而是为我们这些希望进行简单、有效的协作的人所准备的。
依赖注入出现已经有一段时间了,很多团队都在重构自己的应用以利用DI。但这是一件麻烦的事情。在这篇文章中,Paul Hammant说明了如何将现存应用从单件嵌套设计转为完全成熟的DI设计。
前不久,InfoQ中文站上发表了一篇文章:Scrum在中国——企业实施情况调查实录,引起了激烈争论。在本文中,作者通过对调查实录中案例的分析诊断,探讨了敏捷开发方法的概念及应用。
BEA发布了在WebLogic 10.3中支持的SCA技术预览版,它是以开源的Fabric3运行时为基础构建的。InfoQ对Jim Marino和Meeraj Kunnumpurath进行了专访,前者是BEA Systems的技术主管,后者是VocaLink的首席技术人员。我们就他们对SOA和SCA的看法,VocaLink实施SOA的方法和这个技术的关键优势进行了讨论。
在Ruby世界中流行着一个误解:Ruby没有调试器。这是明显的错误——Ruby不但有调试器,还有供调试器用的GUI和API。InfoQ仔细调查了Ruby世界中调试器的现状——发现Ruby的调试功能支持已经很好了。
Patrick Smacchia是Visual C#的MVP,拥有超过15年的软件开发经验。他是《Practical .NET 2 and C# 2》一书的作者。他在多个领域从事过软件开发,包括在Société Générale开发股票交易系统,在Alcatel开发卫星基站。目前他是NDepend工具的首席程序员。
管理顾问Johanna Rothman帮助她的客户管理风险:包括项目中人员的风险,人员管理方式的风险,或是项目自身的风险。在这次采访中,她谈论了包含在她的新书《Manage It! Your Guide to Modern Pragmatic Project Management》中,对于处于不同敏捷度时期的所有团队都有效的降低风险的策略。
没有回复
回复