2007-05-23
从分布式系统的角度看REST
关键字: REST
上周末在杭州网侠大会做了关于REST的演讲。会后经过一些交流，特别是今天在msn上面和dlee的交流，感觉自己对于REST的理解更深入了一层。
我们说REST架构风格，从REST具备的内在特征来说，它包括了这些特征：
1、基于HTTP的资源
2、以HTTP协议去操作
3、数据和表象分离
但是如果我们换一个角度，即分布式应用系统的角度来看，我们会有一些更有意思的结论：
分布式应用系统的架构，经历了好几代的变迁，我们来简单回顾一下：
1、基于CORBA协议的C++中间件时代
CORBA时代我还在上学，基本上没有怎么接触过Corba编程。曾经有一次我提供EJB培训的客户，正在进行传统Corba架构向EJB2架构迁移，通过和他们的交流，对Corba多了一些了解。当时就感叹，和EJB2相比，Corba实在太难用了。Corba时代在1998年EJB1.0发布以后，就逐渐淡出历史舞台了。
2、基于RMI/IIOP协议的EJB时代
这个时代开始于1998年，到现在基本上已经划上了句号。其实在EJB出现以前，在1996年Microsoft发布WindowsNT4.0以后，Microsoft当时也提出了自己的分布式架构，即MTS，但是MTS的光辉被随后出现的伟大的EJB技术彻底击败，此后，就拉开了Java的应用服务器时代，BEA也是在这个时代的转折点成长起来的。
不管是Corba，还是EJB，都有一些共同点：
1) 通过专有的网络协议通讯
2) 不能跨平台调用
3) 通过分布式对象调用来实现分布式架构，换句话来说就是，分布式架构是绑定在面向对象的机制上的
分布式对象架构的缺陷在EJB2时代被充分暴露了出来，乃至于Martin Folwer在《企业应用架构模式》当中强调，分布式调用的第一原则就是不要分布式。更多关于EJB2分布式对象架构的缺陷在Rod Johnson的《J2EE without EJB》当中被剖析的更加清楚。
3、基于SOAP协议的Web Services时代
这个时代始于2001年Microsoft公司推出dotnet平台，整个行业开始鼓吹Web Services。中间经历了一次低潮之后，在IBM,BEA成功的联手炒作SOA之后，再次王者归来。
web services有一些明显不同于Corba和EJB分布式对象架构的特征：
1) 通过标准SOAP协议通讯，一般走HTTP通道
2) 能够跨平台调用
3) 通讯格式是xml文本，而不是二进制数据格式
4) 通过RPC机制来实现分布式调用，而不是通过面向对象机制实现分布式调用
web services的优点和缺点都非常突出，这个不是本文的要点，不做具体分析。这里唯一要强调的是SOAP协议并不依赖于HTTP。事实上SOAP协议可以走很多底层协议，例如SMTP协议，Jabber协议等等。
REST也是一种分布式系统的架构风格，那么REST和上面这些分布式架构有哪些明显的区别呢？
1) REST走的是HTTP协议，并且充分利用或者说极端依赖HTTP协议
Corba和EJB是采用专有的二进制协议，SOAP可以但不依赖HTTP，并且仅仅使用HTTP POST。
2) REST是基于HTTP抽象资源的分布式调用，换句话来说，就是分布式调用是绑定在资源的操作上面的。
通过上面的总结，我们可以做一个直观的对比表格：
REST最大的特点是什么呢？REST是为通过HTTP协议来进行分布式调用量身定造的架构
传统上，我们开发一个非分布式的软件系统，使用OO进行建模和架构，无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用，也许我们需要探索更好的面向对象的分布式调用架构。
REST是专门为分布式调用设计的架构，在REST里面，分布式是通过对资源的操作来实现的，不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念，资源被映射到相应的一套URL规则上面了。所以资源只和URL相关，而与具体实现无关，因此REST具有更好的解藕性。在RoR的实现当中，你可以把一些资源直接映射到model对象上面去，也可以不映射到model上面，而完全是由业务逻辑组合的抽象资源。
我们说REST架构风格，从REST具备的内在特征来说，它包括了这些特征：
1、基于HTTP的资源
2、以HTTP协议去操作
3、数据和表象分离
但是如果我们换一个角度，即分布式应用系统的角度来看，我们会有一些更有意思的结论：
分布式应用系统的架构，经历了好几代的变迁，我们来简单回顾一下：
1、基于CORBA协议的C++中间件时代
CORBA时代我还在上学，基本上没有怎么接触过Corba编程。曾经有一次我提供EJB培训的客户，正在进行传统Corba架构向EJB2架构迁移，通过和他们的交流，对Corba多了一些了解。当时就感叹，和EJB2相比，Corba实在太难用了。Corba时代在1998年EJB1.0发布以后，就逐渐淡出历史舞台了。
2、基于RMI/IIOP协议的EJB时代
这个时代开始于1998年，到现在基本上已经划上了句号。其实在EJB出现以前，在1996年Microsoft发布WindowsNT4.0以后，Microsoft当时也提出了自己的分布式架构，即MTS，但是MTS的光辉被随后出现的伟大的EJB技术彻底击败，此后，就拉开了Java的应用服务器时代，BEA也是在这个时代的转折点成长起来的。
不管是Corba，还是EJB，都有一些共同点：
1) 通过专有的网络协议通讯
2) 不能跨平台调用
3) 通过分布式对象调用来实现分布式架构，换句话来说就是，分布式架构是绑定在面向对象的机制上的
分布式对象架构的缺陷在EJB2时代被充分暴露了出来，乃至于Martin Folwer在《企业应用架构模式》当中强调，分布式调用的第一原则就是不要分布式。更多关于EJB2分布式对象架构的缺陷在Rod Johnson的《J2EE without EJB》当中被剖析的更加清楚。
3、基于SOAP协议的Web Services时代
这个时代始于2001年Microsoft公司推出dotnet平台，整个行业开始鼓吹Web Services。中间经历了一次低潮之后，在IBM,BEA成功的联手炒作SOA之后，再次王者归来。
web services有一些明显不同于Corba和EJB分布式对象架构的特征：
1) 通过标准SOAP协议通讯，一般走HTTP通道
2) 能够跨平台调用
3) 通讯格式是xml文本，而不是二进制数据格式
4) 通过RPC机制来实现分布式调用，而不是通过面向对象机制实现分布式调用
web services的优点和缺点都非常突出，这个不是本文的要点，不做具体分析。这里唯一要强调的是SOAP协议并不依赖于HTTP。事实上SOAP协议可以走很多底层协议，例如SMTP协议，Jabber协议等等。
REST也是一种分布式系统的架构风格，那么REST和上面这些分布式架构有哪些明显的区别呢？
1) REST走的是HTTP协议，并且充分利用或者说极端依赖HTTP协议
Corba和EJB是采用专有的二进制协议，SOAP可以但不依赖HTTP，并且仅仅使用HTTP POST。
2) REST是基于HTTP抽象资源的分布式调用，换句话来说，就是分布式调用是绑定在资源的操作上面的。
通过上面的总结，我们可以做一个直观的对比表格：
分布式架构 协议 调用方式 ------------------------------------------------------- Corba架构 专有二进制协议 对象的CRUD操作 EJB架构 专有二进制协议 对象的CRUD操作 Web Services SOAP协议 RPC方式 REST HTTP协议 对资源的CRUD操作 --------------------------------------------------------
REST最大的特点是什么呢？REST是为通过HTTP协议来进行分布式调用量身定造的架构
传统上，我们开发一个非分布式的软件系统，使用OO进行建模和架构，无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用，也许我们需要探索更好的面向对象的分布式调用架构。
REST是专门为分布式调用设计的架构，在REST里面，分布式是通过对资源的操作来实现的，不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念，资源被映射到相应的一套URL规则上面了。所以资源只和URL相关，而与具体实现无关，因此REST具有更好的解藕性。在RoR的实现当中，你可以把一些资源直接映射到model对象上面去，也可以不映射到model上面，而完全是由业务逻辑组合的抽象资源。
评论
ozzzzzz
2007-06-20
Lordaeron 写道
ozzzzzz 写道
前面Lordaeron很能代表水平的两个发言那里去了？
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
要比水平, 你有興趣當然是會接受的.
你的水平是多少呢?
本人对比谁高谁低完全没有兴趣。只是本人觉得你前两个发言实在是精彩异常，被删除了实在是可惜。而这些讨论，本人实在不敢复述。而如果只是我看见了，我实在是为广大javaeye众感到万分可惜。
Lordaeron
2007-06-20
ozzzzzz 写道
前面Lordaeron很能代表水平的两个发言那里去了？
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
要比水平, 你有興趣當然是會接受的.
你的水平是多少呢?
ozzzzzz
2007-06-20
前面Lordaeron很能代表水平的两个发言那里去了？
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
就是那个什么HTTP是载体的。多高的水平啊，删除了怎么反应这个人的能力呢？只有前后联系起来一起看，才能知道他究竟是有多强的水平。
强！
Lordaeron
2007-06-19
http://en.wikipedia.org/wiki/Representational_State_Transfer
REST versus RPC 這一段, 如果有人對DNS 的行為有認識的
話, 應該會知它在打什麼主意
REST versus RPC 這一段, 如果有人對DNS 的行為有認識的
話, 應該會知它在打什麼主意
winterwolf
2007-06-18
能说明问题就可以 不要太复杂
winterwolf
2007-06-18
楼上做分布开发经验丰富 能否拿出一个具体的例子比如某种分布应用
dlee用rest去设计一下如何实现
Lordaeron用corda或其他技术设计一下
然后我们再继续讨论
dlee用rest去设计一下如何实现
Lordaeron用corda或其他技术设计一下
然后我们再继续讨论
Lordaeron
2007-06-18
xly_971223 写道
Lordaeron是不是来吵架的？
就是论事别撤没用的
就是论事别撤没用的
哦. 就事論事?
誰在就事論事, 誰在講笑話?
你有本事來判定?
xly_971223
2007-06-18
Lordaeron是不是来吵架的？
就是论事别撤没用的
就是论事别撤没用的
江南白衣
2007-06-18
Lordaeron 写道
在你的案子裏就可以拿來當大多數, 你是以偏蓋全還是自大?
你到底搞清楚RPC 的定義了嗎?
http://www.pcmag.com/encyclopedia_term/0,2542,t=RPC&i=50652,00.asp
(Remote Procedure Call) A programming interface that allows one program to use the services of another program in a remote machine. The calling program sends a message and data to the remote program, which is executed, and results are passed back to the calling program.
PC Magazine 不能力的話
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,00.html
名詞的基礎要搞清楚再出來和別人討論, 這是基本的禮貌.
一個連名詞都搞不清楚的人, 連討論的價值都沒有.
特別是REST. 作者連基礎都錯, 別跟我講它的引申會對.
你到底搞清楚RPC 的定義了嗎?
http://www.pcmag.com/encyclopedia_term/0,2542,t=RPC&i=50652,00.asp
(Remote Procedure Call) A programming interface that allows one program to use the services of another program in a remote machine. The calling program sends a message and data to the remote program, which is executed, and results are passed back to the calling program.
PC Magazine 不能力的話
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,00.html
名詞的基礎要搞清楚再出來和別人討論, 這是基本的禮貌.
一個連名詞都搞不清楚的人, 連討論的價值都沒有.
特別是REST. 作者連基礎都錯, 別跟我講它的引申會對.
看来你没有仔细看我举的两个例子，两个例子里REST是截然不同的地位。
dlee花那么多精力又是翻译又是发文，只是希望大家多了解一点REST的知识，这份推广的热心值得大家支持，现在中国的技术推广者还是太少了！！
但推广一个新技术的时候，不加定语修饰的将所有旧技术钉死也是危险的:)
BTW.http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,00.html 里的RPC定义，和大家理解的没什么不同，没什么相悖的地方啊，client/server，synchronous ，stub，都是熟悉的字眼。
Lordaeron
2007-06-17
江南白衣 写道
我之前参与的电信认证计费项目，critical的代码用C++，业务管理的代码用Java，还有一些shell脚本写的任务，算是比较典型的分布式调用情景：
主力的同步调用方案是BEA Tuxedo，异步用IBM MQ，Java内部则是EJB和JMS(一个Weblogic搞定)，对外的接口主要是WebService和FTP，另有少量的Socket接口,而旧版系统用Corba连。
在这个生态圈里，REST如果要替换，只能是替换少量外围没有跑WS-*标准的WebService和某些简易Socket接口，大部分的用例里都没有它插手的份儿。而且，整个系统基本上是面向消息而不是面向RPC的，Function在这里主要充当的是Channel的角色。所以，这里dlee说的RPC风格逐渐过时没有错，但和REST将成为主流又没有直接联系。
而最近参与的一个系统，要做一个公共数据服务平台，REST就发市了，我打算利用某个ESB引擎发布WebService/REST双接口，适用不同AP的技术水平和效率要求。设计的过程中dlee给了我很多建议和指导。
所以，我觉得大家火冒三丈的争论没有任何意义，大家先把讨论的场景、前提搞好了再讨论才互有长进，否则口舌之争，吵赢了对方，自己身上又不会长块肉。
主力的同步调用方案是BEA Tuxedo，异步用IBM MQ，Java内部则是EJB和JMS(一个Weblogic搞定)，对外的接口主要是WebService和FTP，另有少量的Socket接口,而旧版系统用Corba连。
在这个生态圈里，REST如果要替换，只能是替换少量外围没有跑WS-*标准的WebService和某些简易Socket接口，大部分的用例里都没有它插手的份儿。而且，整个系统基本上是面向消息而不是面向RPC的，Function在这里主要充当的是Channel的角色。所以，这里dlee说的RPC风格逐渐过时没有错，但和REST将成为主流又没有直接联系。
而最近参与的一个系统，要做一个公共数据服务平台，REST就发市了，我打算利用某个ESB引擎发布WebService/REST双接口，适用不同AP的技术水平和效率要求。设计的过程中dlee给了我很多建议和指导。
所以，我觉得大家火冒三丈的争论没有任何意义，大家先把讨论的场景、前提搞好了再讨论才互有长进，否则口舌之争，吵赢了对方，自己身上又不会长块肉。
在你的案子裏就可以拿來當大多數, 你是以偏蓋全還是自大?
你到底搞清楚RPC 的定義了嗎?
http://www.pcmag.com/encyclopedia_term/0,2542,t=RPC&i=50652,00.asp
(Remote Procedure Call) A programming interface that allows one program to use the services of another program in a remote machine. The calling program sends a message and data to the remote program, which is executed, and results are passed back to the calling program.
PC Magazine 不能力的話
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,00.html
名詞的基礎要搞清楚再出來和別人討論, 這是基本的禮貌.
一個連名詞都搞不清楚的人, 連討論的價值都沒有.
特別是REST. 作者連基礎都錯, 別跟我講它的引申會對.
江南白衣
2007-06-17
我之前参与的电信认证计费项目，critical的代码用C++，业务管理的代码用Java，还有一些shell脚本写的任务，算是比较典型的分布式调用情景：
主力的同步调用方案是BEA Tuxedo，异步用IBM MQ，Java内部则是EJB和JMS(一个Weblogic搞定)，对外的接口主要是WebService和FTP，另有少量的Socket接口,而旧版系统用Corba连。
在这个生态圈里，REST如果要替换，只能是替换少量外围没有跑WS-*标准的WebService和某些简易Socket接口，大部分的用例里都没有它插手的份儿。而且，整个系统基本上是面向消息而不是面向RPC的，Function在这里主要充当的是Channel的角色。所以，这里dlee说的RPC风格逐渐过时没有错，但和REST将成为主流又没有直接联系。
而最近参与的一个系统，要做一个公共数据服务平台，REST就发市了，我打算利用某个ESB引擎发布WebService/REST双接口，适用不同AP的技术水平和效率要求。设计的过程中dlee给了我很多建议和指导。
所以，我觉得大家火冒三丈的争论没有任何意义，大家先把讨论的场景、前提搞好了再讨论才互有长进，否则口舌之争，吵赢了对方，自己身上又不会长块肉。
主力的同步调用方案是BEA Tuxedo，异步用IBM MQ，Java内部则是EJB和JMS(一个Weblogic搞定)，对外的接口主要是WebService和FTP，另有少量的Socket接口,而旧版系统用Corba连。
在这个生态圈里，REST如果要替换，只能是替换少量外围没有跑WS-*标准的WebService和某些简易Socket接口，大部分的用例里都没有它插手的份儿。而且，整个系统基本上是面向消息而不是面向RPC的，Function在这里主要充当的是Channel的角色。所以，这里dlee说的RPC风格逐渐过时没有错，但和REST将成为主流又没有直接联系。
而最近参与的一个系统，要做一个公共数据服务平台，REST就发市了，我打算利用某个ESB引擎发布WebService/REST双接口，适用不同AP的技术水平和效率要求。设计的过程中dlee给了我很多建议和指导。
所以，我觉得大家火冒三丈的争论没有任何意义，大家先把讨论的场景、前提搞好了再讨论才互有长进，否则口舌之争，吵赢了对方，自己身上又不会长块肉。
blueoxygen
2007-06-17
dlee 写道
关于REST，最近InfoQ China翻译了两篇文章，大家有兴趣的可以仔细看一看。
http://www.infoq.com/cn/articles/restlet-louvel-interview
http://www.infoq.com/cn/news/2007/06/rest-description-language
Fielding论文的中文版如果做review的各位专家没有什么大的修改意见，这周之内就会发布。希望在一两个月以后，我不需要在这里反复做关于REST的扫盲工作了，我们可以深入讨论一些更加有趣的话题。
http://www.infoq.com/cn/articles/restlet-louvel-interview
http://www.infoq.com/cn/news/2007/06/rest-description-language
Fielding论文的中文版如果做review的各位专家没有什么大的修改意见，这周之内就会发布。希望在一两个月以后，我不需要在这里反复做关于REST的扫盲工作了，我们可以深入讨论一些更加有趣的话题。
赶紧放出来吧。
然后想听听类似这种讨论
引用
Bobby Woolf（因企业集成模式而闻名）同样认为REST需要声明性接口并怀疑当REST最终获得这些能力时，结果是否还会与WSDL有什么显著不同。
dlee
2007-06-17
关于REST，最近InfoQ China翻译了两篇文章，大家有兴趣的可以仔细看一看。
http://www.infoq.com/cn/articles/restlet-louvel-interview
http://www.infoq.com/cn/news/2007/06/rest-description-language
Fielding论文的中文版如果做review的各位专家没有什么大的修改意见，这周之内就会发布。希望在一两个月以后，我不需要在这里反复做关于REST的扫盲工作了，我们可以深入讨论一些更加有趣的话题。
http://www.infoq.com/cn/articles/restlet-louvel-interview
http://www.infoq.com/cn/news/2007/06/rest-description-language
Fielding论文的中文版如果做review的各位专家没有什么大的修改意见，这周之内就会发布。希望在一两个月以后，我不需要在这里反复做关于REST的扫盲工作了，我们可以深入讨论一些更加有趣的话题。
guoliang0571
2007-06-17
仁者见仁,智者见智, 青菜萝卜个人所爱, 我就爱简单实用,有时候还写写DELPHI:)
Lordaeron和dlee 讨论的很精彩.
个人都比较赞同两位啊. 正所以医生看病,对症下药.
我们做软件的也是一样啊,角度不同,看问题也不同啊.(就象偶,很喜欢EJB3,感觉用了它,精神爽,扩展性好.呵呵 )
现在我回老家,老妈还喝泡盐水解热啊. 女朋友可不一样拉,又是清热汤,又是什么茶的....各有各的长处嘛
谢谢两位拉:)
快乐周末 :-)
Lordaeron和dlee 讨论的很精彩.
个人都比较赞同两位啊. 正所以医生看病,对症下药.
我们做软件的也是一样啊,角度不同,看问题也不同啊.(就象偶,很喜欢EJB3,感觉用了它,精神爽,扩展性好.呵呵 )
现在我回老家,老妈还喝泡盐水解热啊. 女朋友可不一样拉,又是清热汤,又是什么茶的....各有各的长处嘛
谢谢两位拉:)
快乐周末 :-)
winterwolf
2007-06-17
"很奇怪啊，你难道不知道浏览器和HTTP服务器本身其实都是REST应用的例子吗？没有REST的话，浏览器和HTTP服务器是不可能具有良好的性能和可伸缩性的。
IE、Firefox、Apache都是REST应用的例子，实际上Fielding为这些应用以正确的方式使用HTTP提供了大量的建议，甚至直接参与到项目的开发工作中。假如没有REST，浏览器与服务器以一种类似SOAP的协议来通信，今天你和我都不可能愉快地在JavaEye上面讨论问题了。"
这么说当然可以
我的意思是指侵略j2ee cobal webservice市场的实例
如果rest系统确实有优势应该已经可以在市场上扫荡j2ee cobal webservice了 可是现在这个情况还没有发生
IE、Firefox、Apache都是REST应用的例子，实际上Fielding为这些应用以正确的方式使用HTTP提供了大量的建议，甚至直接参与到项目的开发工作中。假如没有REST，浏览器与服务器以一种类似SOAP的协议来通信，今天你和我都不可能愉快地在JavaEye上面讨论问题了。"
这么说当然可以
我的意思是指侵略j2ee cobal webservice市场的实例
如果rest系统确实有优势应该已经可以在市场上扫荡j2ee cobal webservice了 可是现在这个情况还没有发生
dlee
2007-06-17
winterwolf 写道
有实例能证明rest在分布领域的先进性吗 ？
毕竟rest理论已经出来很久了 应该有实际的应用了
毕竟rest理论已经出来很久了 应该有实际的应用了
很奇怪啊，你难道不知道浏览器和HTTP服务器本身其实都是REST应用的例子吗？没有REST的话，浏览器和HTTP服务器是不可能具有良好的性能和可伸缩性的。
IE、Firefox、Apache都是REST应用的例子，实际上Fielding为这些应用以正确的方式使用HTTP提供了大量的建议，甚至直接参与到项目的开发工作中。假如没有REST，浏览器与服务器以一种类似SOAP的协议来通信，今天你和我都不可能愉快地在JavaEye上面讨论问题了。
Fielding 写道
修订后的协议标准是根据新的架构风格的指导来编写的。最后，如同修订后的协议标准中定义的那样，更新后的Web架构通过参与到基础设施（infrastructure）和中间件软件（middleware software）的开发过程中来进行部署，它们组成了大多数的Web应用。这包括了我直接参与Apache HTTP服务器项目和libwww-perl客户端库的软件开发而得到的直接经验，以及通过为W3C的libwww和jigsaw项目、Netscape Navigator、Lynx、MSIE这三种浏览器、还有一大堆其他实现的开发者提供建议而得到的间接经验，这些建议是IETF演讲的一部分。
论文的第6章讲的很清楚，你又不是没有看，你的理解能力实在是够差的。
winterwolf
2007-06-17
有实例能证明rest在分布领域的先进性吗 ？
毕竟rest理论已经出来很久了 应该有实际的应用了
毕竟rest理论已经出来很久了 应该有实际的应用了
Lordaeron
2007-06-17
[quote="dlee"]to Lordaeron：
得了吧，别在这里卖弄了，越卖弄越显示出来你的无知。至少你对于REST和HTTP的理解是错误的，承认自己缺乏了解并不是很丢人的事情。
一位迷信的人, 的確無法跟它講些什麼, 要講http 你比我熟, 還真是笑話.
REST 這個無聊的concept, 一位連定義都錯的人, 發展出來的東西, 依然是錯的.
如果連這樣的concept 都沒有的人, 講出來的話, 依然是個笑話.
[quote="dlee"]
顺便说一下，不谈其他的架构，即使对于EJB这个特定的领域，我确信我肯定比你了解的更多。[/quote]
是嗎? 一位確信的人, 還能將不同level 的東西搞混, 這信心還真的不知從何而來.
得了吧，别在这里卖弄了，越卖弄越显示出来你的无知。至少你对于REST和HTTP的理解是错误的，承认自己缺乏了解并不是很丢人的事情。
一位迷信的人, 的確無法跟它講些什麼, 要講http 你比我熟, 還真是笑話.
REST 這個無聊的concept, 一位連定義都錯的人, 發展出來的東西, 依然是錯的.
如果連這樣的concept 都沒有的人, 講出來的話, 依然是個笑話.
[quote="dlee"]
顺便说一下，不谈其他的架构，即使对于EJB这个特定的领域，我确信我肯定比你了解的更多。[/quote]
是嗎? 一位確信的人, 還能將不同level 的東西搞混, 這信心還真的不知從何而來.
Lordaeron
2007-06-17
江南白衣 写道
咳咳，好像dlee说过时的是"分布式对象系统"，不是"分布式系统"啊。
像源于C的tuxedo，就不是面向对象的呀，我们用的时候，只是用tuxedo来传字符串名值对而已。
像源于C的tuxedo，就不是面向对象的呀，我们用的时候，只是用tuxedo来传字符串名值对而已。
原文:
<我的看法是：分布式对象的年代已经过去了，将会成为一个供人凭吊的古老架构风格。>
看來你的中文也是需要重修了!!
請問你講的是哪一個level 的呢?
如果是講到protocol level? 所有都是傳送字串, 請打開你的ehtereal 慢慢看.
如果是講concept, 哪它的確不是.
dlee
2007-06-17
to Lordaeron：
得了吧，别在这里卖弄了，越卖弄越显示出来你的无知。至少你对于REST和HTTP的理解是错误的，承认自己缺乏了解并不是很丢人的事情。
顺便说一下，不谈其他的架构，即使对于EJB这个特定的领域，我确信我肯定比你了解的更多。
得了吧，别在这里卖弄了，越卖弄越显示出来你的无知。至少你对于REST和HTTP的理解是错误的，承认自己缺乏了解并不是很丢人的事情。
顺便说一下，不谈其他的架构，即使对于EJB这个特定的领域，我确信我肯定比你了解的更多。
robbin
- 浏览: 1678922 次
- 性别:
- 来自: 上海
- 详细资料
搜索本博客
我的相册
共 33 张
链接
最新评论
-
mod_rails尝鲜
我觉得还是mod_fcgid（不是mod_fastcgi）实际点
-- by zgd -
mod_rails尝鲜
hostingrails也已经提供mod_rails了
-- by leondu -
mod_rails尝鲜
dreamhost已经提供mod_rails了
-- by zgd -
关于JavaEye网站未来发展 ...
期待第三阶段目标的实现，但第三目标好像类似于google的云计算，建议赶紧开发， ...
-- by selectme_2008 -
总结一下大家对JavaEye网 ...
javaeye是我比较喜欢的一个网站，但盈利模式还是比较单一，让人怀疑网站是否能 ...
-- by selectme_2008
评论排行榜