我们必须要承认，大多数服务，特别RESTFUL服务经常会带来性能上的问题。有时REST应用程序带来的好处比缺点要多。但它又值得研究一下。这就是为什么要求那些负责监督使用服务的架构师必须要经过特殊的良好培训并且要富有经验的原因之一。我们在一个重要的IBM Rational程序中使用REST背后可以略见一二，这个程序描绘了一个封装了Jazz应用程序生命周期软件的重新架构。

　　REST有很多用途，特别是对那些需要共享数据且无需高吞吐量需求的新型项目。有很多使REST应用程序加速的方法---也许云计算一直以来都是其中一种方法。但你又不能“两眼摸黑”的进入REST世界。

　　就像早期web服务时期，有状态的二进制通信技术已经偏离的太远了一样，Rest在各领域也可能会偏离的太远。在现实世界中，事情总会变化。

　　IBM Rational有一个意义重大的、正在实施的内部REST项目。它叫Jazz，是一个用于交换应用程序生命周期管理（ALM）中数据和工件的协作型平台。IBM并不是真的把Jazz当做一个REST应用系统来做的。他们重新架构了原始Jazz平台，一年前宣布了一个相关的开放式服务生命周期协作（OSLC）项目。它不是一个二者选其一的方案，有很多种方法都可以通过Jazz来连接。考虑到OSLC仍然处于萌芽状态，而ASCII是为了未来开发者的。为了让其松散耦合并能被广泛的支持，它可能不会实际做很多。

　　一年前，当IBM告诉我们他们正在Jazz中使用REST的时候，REST看起来还是个新事物。那时，我问他们和他们的竞争者—REST是否真的能在这种环境下工作。他们都说“是的”—有些人说：“可能是”

　　我采访了一个著名的XML专家，问道：“这个真的能那么快吗？”

　　“当然，”他说道：“只需购买一个XML加速器”我认为那有些可笑--我想专家那时可能眨了一下眼。

　　“不是所有人都有钱买那些东西。”我说道。

　　“有时你要先投入才能赚钱，”他回答道。然后，当然，他又眨了一下眼。但是怎么看RESTFUL好像都有些问题。

　　上周在一个与IBM Rational用户见面会上，IBM Rational的总经理，Danny Sabbah说：“有了Jazz和OSLC，IBM正在寻求一个新的协作应用程序生命周期管理理念。”

　　可能IBM很快就会以一种类似于OSLC的开放源代码形式介绍Jazz。目前，公司只是简单介绍了一下OSLC各方面以便人们能理解它是做什么的。

　　Sabbah说：“当你要努力做一个开放源代码标准化的时候，你需要有社区的支持。要鼓励松散藕合。”

　　结果，OSLC不是作为一种基于JAVA的架构而出现的，而是作为一种RESTFUL APIs出现的。“它鼓励以多角度参与，”Sabbah说到，“你需要的就是一个能查询、获得、解析和流动的XML流。”

　　有缺陷— 也有优点。“其核心是效率低的，”Sabbah承认。“从另一个角度讲，它为那些想参与的人起了最小公分母的作用。”

　　他说IBM将会为那些想交流的人增建协作型的OSCL。一个OSCL的变化管理的文档刚刚达到1.0版本。

　　“如果你做什么都使用XML和Mashups，这样的性能是不会被接受的。我们有一个经过优化的增强的版本以使其在J2EE上运行，我们也有RESTFUL APIs，使它保持开放。”

　　这就是SOA的精髓，Sabbah说：“你有服务定义，你也有服务可交付成果，而且后面的内容也可以改变。”