将REST引入企业应用
9 views
Skip to first unread message
dlee
May 14, 2008, 11:03:22 AM5/14/08
to REST实战
其实这方面的努力已经很多了，包括IBM、Oracle、SAP等大公司以及开源社区都有尝试。
我认为REST没有必要急于进入企业应用，因为REST其实是为面向Internet的Web应用量身定制的一种架构风格。它的运行环境是
Internet，而不是Intranet。我们在讨论一种架构风格的优劣时不应该脱离它的运行环境，那样做是不诚实的，和推销银弹式方案（例如国内某
软件公司到处推销的“世界上最好的Web框架”）几乎一样愚蠢。
尽管如此，我仍然对REST进入企业应用领域报有很乐观的预期，我相信即使运行于Intranet环境中，REST对于实现企业应用的很多目标也是非常
有价值的。例如我相信REST可以很好地为SOA的目标服务。
我来介绍一些我所知道的将REST引入企业应用的尝试，希望起到抛砖引玉的作用。
在InfoQ上有一篇访谈：Websphere CTO谈REST和Project Zero
http://www.infoq.com/cn/interviews/project-zero-cuomo-cn
1. 为什么强调REST？似乎IBM是WS*和以SOA风格行事的支持者。
IBM，特别是软件集团（software group）中的我们，是SOA的幕后推动者。SOA是一种架构风格，我们认为其行之有效，具有成本效益，
以及所有的这些特点。我们已经很清楚SOA是一种架构风格，还没有事实上的SOA实现。通过我们的产品，我们一直在提倡和推动基于WS*等一组产业标准
的SOA实例。WA*提供了一套功能，是工业级强度的关键。而SOA非常适合于我们产品组合中的标准类型。但问题是：这是不是能一刀切？这是唯一的
SOA实例化方式吗？绝对不是！
REST让我兴奋的是——如果按照80/20法则——会有一系列的活动不需要严格遵照WS*的规定。REST让我兴奋的是我们认为它可以提供入门级的
SOA。
REST的好处是它就像我们日常呼吸的空气一样。它是围绕Web而产生，而Web就在我们的周围。这就转化成了各种有趣的事情：技能、基础设施，这些东
西就在那里。能够以你已经有的经历为背景，来谈论SOA模型是非常有说服力的。我们可以使你非常快速地实现SOA，毫无疑问随着你的进步，你将会需要
WS*，但是REST能给你一个起点。现在，我们如何来解读80/20规则，是80％的人在做20％的事情吗？
各种各样关键的东西都可以通过REST表示。这让我们感到兴奋，而这也是与SOA有联系的地方。REST是围绕着松耦合概念构建的一种架构风格。如果你
看到Ajax应用借助互联网上的HTTP通过JavaScript调用服务；这是构建松耦合系统的极好的例子，因而当我将基于 Ajax的架构作为
SOA的例子谈论时，感到非常兴奋。不管你是否在企业当中，你都会承认这些事实，而且通过REST你可以开始了解SOA的精妙之处。
2. 一些人问到REST会超越WS*方法吗，或者你真正需要WS-*基础架构的哪些核心部件？
这使我有点紧张，因为REST之美在于它只做它擅长的工作。它多年来一直是这么做的。让我们更有条理地探讨一下，我之前提到了用句子来比喻如何思考
REST 的主要服务方面。我不想看到REST被复杂化，因为它的美妙之处在于它的简单。明确地划分SOA的风格，像RESTful SOA、企业级
SOA，我认为是很重要的。
我们正在试图围绕企业级SOA完成的事情其本身就是很复杂的。例如试图整合支持同步和异步协议并有着不同架构的系统。这是现实中必须要处理的事情。我认
为WS*的方式以及一些主题相关的标准是非常有效率的方式；但这些都是复杂的问题。我不想看到围绕REST的简单问题被引伸到某种程度试图解决其中的一
些复杂问题，因为这样REST将不再是吸引我们的REST了。
政教分离是伟大的举措，因为我们有WS*、纯Web和REST。但一旦我们试图开始正规化REST，像“REST对应的 WSDL是什么？这并不存
在。”让我们尝试保持句子结构，因为我们有WSDL，而且它对它所做的事情是有好处的。当需要严格定义的时候，我们有这样的能力。我见过客户非常好地使
用这两种方式。他们开始通过WSDL定义服务，并通过这些切入点（entry point）以及REST暴露入口服务（entry service）。
我认为两者都要生存的空间。两者的并存让我很高兴。我不想让一个事物变成另一个。
3. 你是否支持远离WS*？
绝对不是，如果我给人这样的印象，那决不是我的本意。事实上REST是RESTful SOA的一种方式。另外，我要说REST在某种意义上并不特殊，
它是Project Zero与生俱来的权利。我觉得Project Zero擅长于REST，但当我们看IBM软件集团和Webshpere中的整个
产品组合，REST将是这些产品中不可或缺的一部分。以我们的流程服务器（process server）或者ESB为例，其中会提供REST入口，将
会暴露产品的活动和功能：管理功能、通过REST接口监控产品。重申一下，REST就像空气一样，一切都在我们身边，我们将在产品中纳入这些。我们支持
远离WS*？不。我们通过这些产品完全拥抱Web？是的。正如我之前，它们并不互相排斥。
4. IBM如何将REST纳入到它的产品策略中？
我们现在正处于一种状态：在Web中REST就像空气一样普遍存在。我们希望它能够在我们的产品中得到普及。我们所能看到的就是贯穿于我们产品线的发布
卖点。我将在谈及WebSphere产品线时，特别地介绍其中的REST能力，就像我们产品的固有部分那样。
那我们的一个经典产品来说：WebSphere MQ，我们获奖的消息产品。在最新发布的MQ上，我们有能力通过REST来暴露MQ的功能。首先，现在
你不需要通过MQ客户端来驱动MQ中的工作了。如果想在队列中发布一条信息，你所需的就是一个能通过REST发布消息的Web环境，无论是
Javascript应用、PHP还是Zero应用。现在你可以通过REST与MQ进行交互。如果你想做类似于检查队列中内容的事情；对此有专门的
REST接口提供。
REST就像空气一样：人人都有浏览器，人人都有基于Javascript的环境。现在通过REST，通过在那里明摆着的无所不在的SOA接口，你可以
开始与我们的中间件直接交互。
可以来浏览下我们的产品组合：WebSphere应用服务器，我们有了一些所谓的Web2.0功能包，它将根据REST、 Aton和Ajax
comet提供功能——从服务器动态更新返回到Ajax客户端，并允许你在JEE应用之上混合RESTful风格的接口。我可以继续列举我们的产品组
合，从WebSphere ESB到Datapower应用，都根据这些技术加入功能来支持RSETful接入口（on-ramp）：比如，我想向
ESB中放入一条消息，不管是 WebSphere基于Java的ESB还是基于应用的ESB，都有RESTful接口提供支持。
这些并不会作为附加功能提供，而是作为的完成功能的一种方式，成为环绕在WebSphere商标周围的核心技术的一部分。
5. 最后对REST和Project Zero你还有什么要说的？
正如我所说的，对于IBM和WebSphere的所有人来说这是一个真正激动人心的时刻。Project Zero真正地触及了一些令人感兴趣的东西和
新的概念，其都说明了我们如何来构建产品（使用Project Zero，它们都位于防火墙的可见端），通过使用像Groovy这样的动态脚步语言初次
尝试使Web脚本化，依据RESTful架构构建，并真正地用于系统核心的构建，围绕着通过mash-up装配应用有着令人感兴趣的技术，真正地运行在
基于动态脚本语言的执行环境上。
动态脚本、REST和Project Zero真乃天作之合，感觉棒极了。大体上，它恰好适合我们对Websphere的探究，也非常适合作为进入
SOA的入口匝道，使行业围绕着Web方向前进发展 。对这个行业和IBM来说这都是天作之合。这真是令人兴奋的时刻，点击
projectzero.org，并感谢你们的支持！
我认为REST没有必要急于进入企业应用，因为REST其实是为面向Internet的Web应用量身定制的一种架构风格。它的运行环境是
Internet，而不是Intranet。我们在讨论一种架构风格的优劣时不应该脱离它的运行环境，那样做是不诚实的，和推销银弹式方案（例如国内某
软件公司到处推销的“世界上最好的Web框架”）几乎一样愚蠢。
尽管如此，我仍然对REST进入企业应用领域报有很乐观的预期，我相信即使运行于Intranet环境中，REST对于实现企业应用的很多目标也是非常
有价值的。例如我相信REST可以很好地为SOA的目标服务。
我来介绍一些我所知道的将REST引入企业应用的尝试，希望起到抛砖引玉的作用。
在InfoQ上有一篇访谈：Websphere CTO谈REST和Project Zero
http://www.infoq.com/cn/interviews/project-zero-cuomo-cn
1. 为什么强调REST？似乎IBM是WS*和以SOA风格行事的支持者。
IBM，特别是软件集团（software group）中的我们，是SOA的幕后推动者。SOA是一种架构风格，我们认为其行之有效，具有成本效益，
以及所有的这些特点。我们已经很清楚SOA是一种架构风格，还没有事实上的SOA实现。通过我们的产品，我们一直在提倡和推动基于WS*等一组产业标准
的SOA实例。WA*提供了一套功能，是工业级强度的关键。而SOA非常适合于我们产品组合中的标准类型。但问题是：这是不是能一刀切？这是唯一的
SOA实例化方式吗？绝对不是！
REST让我兴奋的是——如果按照80/20法则——会有一系列的活动不需要严格遵照WS*的规定。REST让我兴奋的是我们认为它可以提供入门级的
SOA。
REST的好处是它就像我们日常呼吸的空气一样。它是围绕Web而产生，而Web就在我们的周围。这就转化成了各种有趣的事情：技能、基础设施，这些东
西就在那里。能够以你已经有的经历为背景，来谈论SOA模型是非常有说服力的。我们可以使你非常快速地实现SOA，毫无疑问随着你的进步，你将会需要
WS*，但是REST能给你一个起点。现在，我们如何来解读80/20规则，是80％的人在做20％的事情吗？
各种各样关键的东西都可以通过REST表示。这让我们感到兴奋，而这也是与SOA有联系的地方。REST是围绕着松耦合概念构建的一种架构风格。如果你
看到Ajax应用借助互联网上的HTTP通过JavaScript调用服务；这是构建松耦合系统的极好的例子，因而当我将基于 Ajax的架构作为
SOA的例子谈论时，感到非常兴奋。不管你是否在企业当中，你都会承认这些事实，而且通过REST你可以开始了解SOA的精妙之处。
2. 一些人问到REST会超越WS*方法吗，或者你真正需要WS-*基础架构的哪些核心部件？
这使我有点紧张，因为REST之美在于它只做它擅长的工作。它多年来一直是这么做的。让我们更有条理地探讨一下，我之前提到了用句子来比喻如何思考
REST 的主要服务方面。我不想看到REST被复杂化，因为它的美妙之处在于它的简单。明确地划分SOA的风格，像RESTful SOA、企业级
SOA，我认为是很重要的。
我们正在试图围绕企业级SOA完成的事情其本身就是很复杂的。例如试图整合支持同步和异步协议并有着不同架构的系统。这是现实中必须要处理的事情。我认
为WS*的方式以及一些主题相关的标准是非常有效率的方式；但这些都是复杂的问题。我不想看到围绕REST的简单问题被引伸到某种程度试图解决其中的一
些复杂问题，因为这样REST将不再是吸引我们的REST了。
政教分离是伟大的举措，因为我们有WS*、纯Web和REST。但一旦我们试图开始正规化REST，像“REST对应的 WSDL是什么？这并不存
在。”让我们尝试保持句子结构，因为我们有WSDL，而且它对它所做的事情是有好处的。当需要严格定义的时候，我们有这样的能力。我见过客户非常好地使
用这两种方式。他们开始通过WSDL定义服务，并通过这些切入点（entry point）以及REST暴露入口服务（entry service）。
我认为两者都要生存的空间。两者的并存让我很高兴。我不想让一个事物变成另一个。
3. 你是否支持远离WS*？
绝对不是，如果我给人这样的印象，那决不是我的本意。事实上REST是RESTful SOA的一种方式。另外，我要说REST在某种意义上并不特殊，
它是Project Zero与生俱来的权利。我觉得Project Zero擅长于REST，但当我们看IBM软件集团和Webshpere中的整个
产品组合，REST将是这些产品中不可或缺的一部分。以我们的流程服务器（process server）或者ESB为例，其中会提供REST入口，将
会暴露产品的活动和功能：管理功能、通过REST接口监控产品。重申一下，REST就像空气一样，一切都在我们身边，我们将在产品中纳入这些。我们支持
远离WS*？不。我们通过这些产品完全拥抱Web？是的。正如我之前，它们并不互相排斥。
4. IBM如何将REST纳入到它的产品策略中？
我们现在正处于一种状态：在Web中REST就像空气一样普遍存在。我们希望它能够在我们的产品中得到普及。我们所能看到的就是贯穿于我们产品线的发布
卖点。我将在谈及WebSphere产品线时，特别地介绍其中的REST能力，就像我们产品的固有部分那样。
那我们的一个经典产品来说：WebSphere MQ，我们获奖的消息产品。在最新发布的MQ上，我们有能力通过REST来暴露MQ的功能。首先，现在
你不需要通过MQ客户端来驱动MQ中的工作了。如果想在队列中发布一条信息，你所需的就是一个能通过REST发布消息的Web环境，无论是
Javascript应用、PHP还是Zero应用。现在你可以通过REST与MQ进行交互。如果你想做类似于检查队列中内容的事情；对此有专门的
REST接口提供。
REST就像空气一样：人人都有浏览器，人人都有基于Javascript的环境。现在通过REST，通过在那里明摆着的无所不在的SOA接口，你可以
开始与我们的中间件直接交互。
可以来浏览下我们的产品组合：WebSphere应用服务器，我们有了一些所谓的Web2.0功能包，它将根据REST、 Aton和Ajax
comet提供功能——从服务器动态更新返回到Ajax客户端，并允许你在JEE应用之上混合RESTful风格的接口。我可以继续列举我们的产品组
合，从WebSphere ESB到Datapower应用，都根据这些技术加入功能来支持RSETful接入口（on-ramp）：比如，我想向
ESB中放入一条消息，不管是 WebSphere基于Java的ESB还是基于应用的ESB，都有RESTful接口提供支持。
这些并不会作为附加功能提供，而是作为的完成功能的一种方式，成为环绕在WebSphere商标周围的核心技术的一部分。
5. 最后对REST和Project Zero你还有什么要说的？
正如我所说的，对于IBM和WebSphere的所有人来说这是一个真正激动人心的时刻。Project Zero真正地触及了一些令人感兴趣的东西和
新的概念，其都说明了我们如何来构建产品（使用Project Zero，它们都位于防火墙的可见端），通过使用像Groovy这样的动态脚步语言初次
尝试使Web脚本化，依据RESTful架构构建，并真正地用于系统核心的构建，围绕着通过mash-up装配应用有着令人感兴趣的技术，真正地运行在
基于动态脚本语言的执行环境上。
动态脚本、REST和Project Zero真乃天作之合，感觉棒极了。大体上，它恰好适合我们对Websphere的探究，也非常适合作为进入
SOA的入口匝道，使行业围绕着Web方向前进发展 。对这个行业和IBM来说这都是天作之合。这真是令人兴奋的时刻，点击
projectzero.org，并感谢你们的支持！
dlee
May 14, 2008, 11:17:47 AM5/14/08
to REST实战
InfoQ上最近还有两篇与REST+SOA相关的文章：
使用NetKerne实现REST风格的ESB
http://www.infoq.com/cn/articles/netkernel-casestudy
以及《RESTful Web Services》中文版译者徐涵所翻译的
SPARQL Update将完善REST式SOA方案
http://www.infoq.com/cn/news/2008/05/sparql-update-soa
Rod Johnson也宣称将在Spring 3.0中全面支持REST：
http://www.infoworld.com/article/08/03/27/spring-3-to-get-rest_1.html
On 5月14日, 下午11时03分, dlee <dlee...@gmail.com> wrote:
> 其实这方面的努力已经很多了，包括IBM、Oracle、SAP等大公司以及开源社区都有尝试。
使用NetKerne实现REST风格的ESB
http://www.infoq.com/cn/articles/netkernel-casestudy
以及《RESTful Web Services》中文版译者徐涵所翻译的
SPARQL Update将完善REST式SOA方案
http://www.infoq.com/cn/news/2008/05/sparql-update-soa
Rod Johnson也宣称将在Spring 3.0中全面支持REST：
http://www.infoworld.com/article/08/03/27/spring-3-to-get-rest_1.html
On 5月14日, 下午11时03分, dlee <dlee...@gmail.com> wrote:
> 其实这方面的努力已经很多了，包括IBM、Oracle、SAP等大公司以及开源社区都有尝试。
Reply all
Reply to author
Forward
0 new messages