从卓越工程角度看微软中国开发团队的成长
开发团队的成长离不开优秀的人才,简捷有效的流程和高效率工具这三个卓越工程系统中的重要因素。本文作者从这三个因素分析了微软中国开发团队是如何“从优秀到卓越”的。
作者 Mark Little译者 郭晓刚 发布于 2007年7月5日 上午1时30分
David Chappell在他的博客里作出了一个在过去近一年时间里为人们所悄悄接受的结论:
如果你有留意,并且如果你不是一个无可救药的死硬派,我要告诉你REST和WS-*之间的战争已经结束了。这场战争如朝鲜战争一样以停战协定终结,而不是像第二次世界大战那样由一方取得压倒性的胜利。现在看来已经很清楚,两种技术都有其价值,都将会继续被使用下去。
不管这场争论是关于REST对WS-*,还是关于REST对SOA,这种面对现实的态度(或者说骑墙的态度)已经存在一段时间了。正如David所指出:
[……]看看微软在下一版的Windows Communication Foundation(WCF)中即将推出的对创建RESTful应用程序的支持。Java的官方组织也上了这条船,他们的JAX-RS也即将面世。
微软们已经说了REST和WS-*很多年好话,所以这些也不是什么令人惊奇的举动。只有很少人仍然相信Web服务是万灵药。也同样只有很少人仍然相信REST是万灵药。那我们不禁要问:“什么时候该用REST,什么时候又该用WS-*?”David的意见是:
对于关注CRUD场景的面向数据的应用来说,RESTful的方式是很自然的事。有很多很多程序都适用这种模型,特别是互联网上的公共应用程序。对于面向服务/面向方法的应用,比如需要事务、严密的安全性等等这些更高级的操作的应用来说,采用基于WS-*的方案显得更有道理。
不过Mark Baker不同意:
我完全同意他说REST很适合面向数据的应用,但我不同意他说REST只适合符合CRUD模型的应用。这是因为CRUD没有HTTP POST的等价物。一旦你把POST考虑在内,你就可以做到所有的事情,比如,网上订货。
Mark很乐意请教别人对这个问题的见解,他说:
可能David,或者其他人,可以给我举个例子,给我举出一个不(太)适合这个模型(不必是完整的REST,只要举出统一接口的部分就好)的面向数据的应用的例子。
那么,当David在他的文章最后写下:
很高兴看到狂热在消退,而理性赢得了胜利。战争真的结束了。
他说得对吗?还是这只是暂时的平静,将军们正在策划新的战略?
查看英文原文:The REST versus WS-* war is over!
开发团队的成长离不开优秀的人才,简捷有效的流程和高效率工具这三个卓越工程系统中的重要因素。本文作者从这三个因素分析了微软中国开发团队是如何“从优秀到卓越”的。
本文是Productive Java with Ruby系列文章的第一篇,我将从单元测试这个话题开始,让Java的开发人员能够在实际工作中利用Ruby提高工作效率。
InfoQ中文站有幸与阿里软件的首席架构师赵进在一起探讨了SaaS的相关话题,包括SOA和ASP与SaaS的异同、云计算、SaaS的前景、它的关键技术、技术瓶颈等等。
在这篇文章中,Adrien Louis和Marc Dutoo在一个典型的ESB场景中讨论了编配和路由的区别和优缺点。他们讨论了几种连接服务的方法,从使用如自定义路由这样的低级别方法,到使用如工作流和编配这样面向业务的高级别方式,并总结说不存在“一边倒”的解决方案。
本文是根据7月26日InfoQ中文站在杭州举行的QClub活动(第三期)后半程小组讨论总结而成。主要内容包括如何在SOA系统中实现服务编排,如何保证分布式系统中的一致性和可用性,以及如何在实施SOA的过程中控制接口的粒度等。
人们很容易想当然的以为虚拟化技术仅仅应用于服务器。而在现实中,虚拟化这一苏醒的概念正被运用于各个层面,其中包括网络,存储以及应用基础架构。在这篇导论中,InfoQ将深入每个方面,详尽向您描述虚拟化技术的运用以及其优点与不足。
在这篇案例研究中,InfoQ对Adobe AIR和Amazon的简单存储服务(Simple Storage Service ,S3)在NASDAQ市场回放程序(NASDAQ Market Replay)中的应用进行了详细的分析。
没有回复
回复