c*********e
发帖数: 16335 | 1 soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
legacy code. |
d****i
发帖数: 4809 | 2 现在的用的web service都是REST的，连我们在embedded system上的都是用REST的，这
个是大势所趋。
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
g*****g
发帖数: 34805 | 3 It's actually easier than you think. Libraries like CXF have taken care of
the dirty work. You don't really have to write the wsdl. And the client stub
can be generated automatically.
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
g*********9
发帖数: 1285 | 4 作支持async的REST, 哪个framework最方便？spring or jersey?
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
z****e
发帖数: 54598 | 5 如果你已经用了spring，那就spring web service
jersey的话，只是一个组件，它不负责后续处理
所以bean的管理你可能还需要找一个东西来管理
【在 g*********9 的大作中提到】
: 作支持async的REST, 哪个framework最方便？spring or jersey?
|
g*********9
发帖数: 1285 | 6 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
么办样
【在 z****e 的大作中提到】
: 如果你已经用了spring，那就spring web service
: jersey的话，只是一个组件，它不负责后续处理
: 所以bean的管理你可能还需要找一个东西来管理
|
w**z
发帖数: 8232 | 7 为啥要async, response太慢？
http://stackoverflow.com/questions/7583624/are-asynchronous-res
【在 g*********9 的大作中提到】
: 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
: 么办样
|
d****i
发帖数: 4809 | 8 Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
https://jersey.java.net/documentation/latest/async.html
“ This model (Synchronous mode) is typically sufficient for processing of
requests for which the processing resource method execution takes a
relatively short time. However, in cases where a resource method execution
is known to take a long time to compute the result, server-side asynchronous
processing model should be used. ”
【在 g*********9 的大作中提到】
: 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
: 么办样
|
c*********e
发帖数: 16335 | 9 但是公司里还有legacy code呀。这就是说，既要会用soap，也要会用rest.
【在 d****i 的大作中提到】
: 现在的用的web service都是REST的，连我们在embedded system上的都是用REST的，这
: 个是大势所趋。
|
w**z
发帖数: 8232 | 10 Thanks domini. I didn't know Jersey supports that as we are still on Jersey
1.17.
it's quite different for Server side Asyn process vs Client side Asyn. Not
sure what groundhog09 needs.
asynchronous
【在 d****i 的大作中提到】
: Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
: https://jersey.java.net/documentation/latest/async.html
: “ This model (Synchronous mode) is typically sufficient for processing of
: requests for which the processing resource method execution takes a
: relatively short time. However, in cases where a resource method execution
: is known to take a long time to compute the result, server-side asynchronous
: processing model should be used. ”
|
|
|
d****i
发帖数: 4809 | 11 same boat here. I'm using Jersey 1.17 too :)
Jersey
【在 w**z 的大作中提到】
: Thanks domini. I didn't know Jersey supports that as we are still on Jersey
: 1.17.
: it's quite different for Server side Asyn process vs Client side Asyn. Not
: sure what groundhog09 needs.
:
: asynchronous
|
g*****g
发帖数: 34805 | 12 I am not sure if there are any good use case of server side async. For
server to server communication, you can achieve the same goal by doing the
processing in a separate thread, and calling back on the caller's web
service (or use MQ). A connection doesn't need to be kept open during the
processing, I am sure that will be more efficient.
For client-server communication, the connection can easily time out, and the
result will be lost. It's much better to save the result and allow the
client to poll periodically or do long poll. Then fetch the result when
state is changed.
Jersey
【在 w**z 的大作中提到】
: Thanks domini. I didn't know Jersey supports that as we are still on Jersey
: 1.17.
: it's quite different for Server side Asyn process vs Client side Asyn. Not
: sure what groundhog09 needs.
:
: asynchronous
|
w**z
发帖数: 8232 | 13 totally agree. for server side async the difficulty is that you need to
generate resource Id and return it to the caller and sometimes it might not
be easy. and you need to support the lookup based on that Id. it can get
complicated.
the
【在 g*****g 的大作中提到】
: I am not sure if there are any good use case of server side async. For
: server to server communication, you can achieve the same goal by doing the
: processing in a separate thread, and calling back on the caller's web
: service (or use MQ). A connection doesn't need to be kept open during the
: processing, I am sure that will be more efficient.
: For client-server communication, the connection can easily time out, and the
: result will be lost. It's much better to save the result and allow the
: client to poll periodically or do long poll. Then fetch the result when
: state is changed.
:
|
p*****2
发帖数: 21240 | 14
not
这是因为Java的缺陷造成的？
【在 w**z 的大作中提到】
: totally agree. for server side async the difficulty is that you need to
: generate resource Id and return it to the caller and sometimes it might not
: be easy. and you need to support the lookup based on that Id. it can get
: complicated.
:
: the
|
g*****g
发帖数: 34805 | 15 Java可以用Node的那一套。vert.x。区别主要是语法简洁以及类库上。一些常见类库使
用了threadlocal或synchronize，一旦调用就不能完全的异步。
【在 p*****2 的大作中提到】
:
: not
: 这是因为Java的缺陷造成的？
|
p*****2
发帖数: 21240 | 16
就跟ruby用eventmachine差不多。要用异步的类库才可以。就看异步类库好不好用了。
【在 g*****g 的大作中提到】
: Java可以用Node的那一套。vert.x。区别主要是语法简洁以及类库上。一些常见类库使
: 用了threadlocal或synchronize，一旦调用就不能完全的异步。
|
w**z
发帖数: 8232 | 17 没用过node， 简单说说async在node上 是咋work的？
【在 p*****2 的大作中提到】
:
: 就跟ruby用eventmachine差不多。要用异步的类库才可以。就看异步类库好不好用了。
|
m********s
发帖数: 55301 | 18 太难学了。
不过看在钱的份上，就认了吧。
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
p*****2
发帖数: 21240 | 19
这个goodbug可能说的更清楚。node里面任何api都是non-blocking的。因此你可以同时
处理大量的request。而且只需要一个thread，所以没有context switch， thread
stack，节省CPU和memory a lot。简单来说就是可以把CPU用到极致。
【在 w**z 的大作中提到】
: 没用过node， 简单说说async在node上 是咋work的？
|
w**z
发帖数: 8232 | 20 from this post:
http://stackoverflow.com/questions/3629784/how-is-node-js-inher
seems nodes is using Asynchronous I/O so that no thread is idle to fully
utilize the resource. It's similar as what Jersey 2.4 can do as server side
async. But from caller, it doesn't see any difference. It is still a
blocking call.
【在 p*****2 的大作中提到】
:
: 这个goodbug可能说的更清楚。node里面任何api都是non-blocking的。因此你可以同时
: 处理大量的request。而且只需要一个thread，所以没有context switch， thread
: stack，节省CPU和memory a lot。简单来说就是可以把CPU用到极致。
|
|
|
p*****2
发帖数: 21240 | 21
side
你要这么说的话，就要谈到Socket.IO了。client也是纯异步的。
【在 w**z 的大作中提到】
: from this post:
: http://stackoverflow.com/questions/3629784/how-is-node-js-inher
: seems nodes is using Asynchronous I/O so that no thread is idle to fully
: utilize the resource. It's similar as what Jersey 2.4 can do as server side
: async. But from caller, it doesn't see any difference. It is still a
: blocking call.
|
g*****g
发帖数: 34805 | 22 This is a very good article that explains the difference.
http://bijoor.me/2013/06/09/java-ee-threads-vs-node-js-which-is
side
【在 w**z 的大作中提到】
: from this post:
: http://stackoverflow.com/questions/3629784/how-is-node-js-inher
: seems nodes is using Asynchronous I/O so that no thread is idle to fully
: utilize the resource. It's similar as what Jersey 2.4 can do as server side
: async. But from caller, it doesn't see any difference. It is still a
: blocking call.
|
g*****g
发帖数: 34805 | 23 I also agree with this guy's evaluation, though it's 1.5 years ago and many
things may have changed. It's probably take a couple of more years before it
's mature enough to see serious enterprise adoption.
http://www.ziggytech.net/technology/web-development/experiences |
c*********e
发帖数: 16335 | 24 soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
legacy code. |
d****i
发帖数: 4809 | 25 现在的用的web service都是REST的，连我们在embedded system上的都是用REST的，这
个是大势所趋。
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
g*****g
发帖数: 34805 | 26 It's actually easier than you think. Libraries like CXF have taken care of
the dirty work. You don't really have to write the wsdl. And the client stub
can be generated automatically.
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
g*********9
发帖数: 1285 | 27 作支持async的REST, 哪个framework最方便？spring or jersey?
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
z****e
发帖数: 54598 | 28 如果你已经用了spring，那就spring web service
jersey的话，只是一个组件，它不负责后续处理
所以bean的管理你可能还需要找一个东西来管理
【在 g*********9 的大作中提到】
: 作支持async的REST, 哪个framework最方便？spring or jersey?
|
g*********9
发帖数: 1285 | 29 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
么办样
【在 z****e 的大作中提到】
: 如果你已经用了spring，那就spring web service
: jersey的话，只是一个组件，它不负责后续处理
: 所以bean的管理你可能还需要找一个东西来管理
|
w**z
发帖数: 8232 | 30 为啥要async, response太慢？
http://stackoverflow.com/questions/7583624/are-asynchronous-res
【在 g*********9 的大作中提到】
: 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
: 么办样
|
|
|
d****i
发帖数: 4809 | 31 Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
https://jersey.java.net/documentation/latest/async.html
“ This model (Synchronous mode) is typically sufficient for processing of
requests for which the processing resource method execution takes a
relatively short time. However, in cases where a resource method execution
is known to take a long time to compute the result, server-side asynchronous
processing model should be used. ”
【在 g*********9 的大作中提到】
: 二者在实现aync的时候,功能上差别大不大? 不太清楚spring对async rest的支持德怎
: 么办样
|
c*********e
发帖数: 16335 | 32 但是公司里还有legacy code呀。这就是说，既要会用soap，也要会用rest.
【在 d****i 的大作中提到】
: 现在的用的web service都是REST的，连我们在embedded system上的都是用REST的，这
: 个是大势所趋。
|
w**z
发帖数: 8232 | 33 Thanks domini. I didn't know Jersey supports that as we are still on Jersey
1.17.
it's quite different for Server side Asyn process vs Client side Asyn. Not
sure what groundhog09 needs.
asynchronous
【在 d****i 的大作中提到】
: Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
: https://jersey.java.net/documentation/latest/async.html
: “ This model (Synchronous mode) is typically sufficient for processing of
: requests for which the processing resource method execution takes a
: relatively short time. However, in cases where a resource method execution
: is known to take a long time to compute the result, server-side asynchronous
: processing model should be used. ”
|
d****i
发帖数: 4809 | 34 same boat here. I'm using Jersey 1.17 too :)
Jersey
【在 w**z 的大作中提到】
: Thanks domini. I didn't know Jersey supports that as we are still on Jersey
: 1.17.
: it's quite different for Server side Asyn process vs Client side Asyn. Not
: sure what groundhog09 needs.
:
: asynchronous
|
g*****g
发帖数: 34805 | 35 I am not sure if there are any good use case of server side async. For
server to server communication, you can achieve the same goal by doing the
processing in a separate thread, and calling back on the caller's web
service (or use MQ). A connection doesn't need to be kept open during the
processing, I am sure that will be more efficient.
For client-server communication, the connection can easily time out, and the
result will be lost. It's much better to save the result and allow the
client to poll periodically or do long poll. Then fetch the result when
state is changed.
Jersey
【在 w**z 的大作中提到】
: Thanks domini. I didn't know Jersey supports that as we are still on Jersey
: 1.17.
: it's quite different for Server side Asyn process vs Client side Asyn. Not
: sure what groundhog09 needs.
:
: asynchronous
|
w**z
发帖数: 8232 | 36 totally agree. for server side async the difficulty is that you need to
generate resource Id and return it to the caller and sometimes it might not
be easy. and you need to support the lookup based on that Id. it can get
complicated.
the
【在 g*****g 的大作中提到】
: I am not sure if there are any good use case of server side async. For
: server to server communication, you can achieve the same goal by doing the
: processing in a separate thread, and calling back on the caller's web
: service (or use MQ). A connection doesn't need to be kept open during the
: processing, I am sure that will be more efficient.
: For client-server communication, the connection can easily time out, and the
: result will be lost. It's much better to save the result and allow the
: client to poll periodically or do long poll. Then fetch the result when
: state is changed.
:
|
p*****2
发帖数: 21240 | 37
not
这是因为Java的缺陷造成的？
【在 w**z 的大作中提到】
: totally agree. for server side async the difficulty is that you need to
: generate resource Id and return it to the caller and sometimes it might not
: be easy. and you need to support the lookup based on that Id. it can get
: complicated.
:
: the
|
g*****g
发帖数: 34805 | 38 Java可以用Node的那一套。vert.x。区别主要是语法简洁以及类库上。一些常见类库使
用了threadlocal或synchronize，一旦调用就不能完全的异步。
【在 p*****2 的大作中提到】
:
: not
: 这是因为Java的缺陷造成的？
|
p*****2
发帖数: 21240 | 39
就跟ruby用eventmachine差不多。要用异步的类库才可以。就看异步类库好不好用了。
【在 g*****g 的大作中提到】
: Java可以用Node的那一套。vert.x。区别主要是语法简洁以及类库上。一些常见类库使
: 用了threadlocal或synchronize，一旦调用就不能完全的异步。
|
w**z
发帖数: 8232 | 40 没用过node， 简单说说async在node上 是咋work的？
【在 p*****2 的大作中提到】
:
: 就跟ruby用eventmachine差不多。要用异步的类库才可以。就看异步类库好不好用了。
|
|
|
m********s
发帖数: 55301 | 41 太难学了。
不过看在钱的份上，就认了吧。
【在 c*********e 的大作中提到】
: soap里面有wsdl之类的，貌似比rest难学。现在有必要学soap吗，貌似很多公司还在用
: legacy code.
|
p*****2
发帖数: 21240 | 42
这个goodbug可能说的更清楚。node里面任何api都是non-blocking的。因此你可以同时
处理大量的request。而且只需要一个thread，所以没有context switch， thread
stack，节省CPU和memory a lot。简单来说就是可以把CPU用到极致。
【在 w**z 的大作中提到】
: 没用过node， 简单说说async在node上 是咋work的？
|
w**z
发帖数: 8232 | 43 from this post:
http://stackoverflow.com/questions/3629784/how-is-node-js-inher
seems nodes is using Asynchronous I/O so that no thread is idle to fully
utilize the resource. It's similar as what Jersey 2.4 can do as server side
async. But from caller, it doesn't see any difference. It is still a
blocking call.
【在 p*****2 的大作中提到】
:
: 这个goodbug可能说的更清楚。node里面任何api都是non-blocking的。因此你可以同时
: 处理大量的request。而且只需要一个thread，所以没有context switch， thread
: stack，节省CPU和memory a lot。简单来说就是可以把CPU用到极致。
|
p*****2
发帖数: 21240 | 44
side
你要这么说的话，就要谈到Socket.IO了。client也是纯异步的。
【在 w**z 的大作中提到】
: from this post:
: http://stackoverflow.com/questions/3629784/how-is-node-js-inher
: seems nodes is using Asynchronous I/O so that no thread is idle to fully
: utilize the resource. It's similar as what Jersey 2.4 can do as server side
: async. But from caller, it doesn't see any difference. It is still a
: blocking call.
|
g*****g
发帖数: 34805 | 45 This is a very good article that explains the difference.
http://bijoor.me/2013/06/09/java-ee-threads-vs-node-js-which-is
side
【在 w**z 的大作中提到】
: from this post:
: http://stackoverflow.com/questions/3629784/how-is-node-js-inher
: seems nodes is using Asynchronous I/O so that no thread is idle to fully
: utilize the resource. It's similar as what Jersey 2.4 can do as server side
: async. But from caller, it doesn't see any difference. It is still a
: blocking call.
|
g*****g
发帖数: 34805 | 46 I also agree with this guy's evaluation, though it's 1.5 years ago and many
things may have changed. It's probably take a couple of more years before it
's mature enough to see serious enterprise adoption.
http://www.ziggytech.net/technology/web-development/experiences |
c*****y
发帖数: 562 | 47 现在所谓“standard based” SOA和Enterprise Integration还是SOAP/WSDL/BPEL那一
套。不新潮不代表legacy。SOAP和REST都会长期存在。
都没啥难的，SOAP/RESTful都算计算机工作中最简单的了吧。
其实SOAP和REST不是并列词汇。REST是architecture style，与之并列的是RPC。SOAP
是spec。把它们俩列在一块就像问“你觉的iOS好呢还是Nexus 5好” :) |
l*******g
发帖数: 82 | 48 你吧SOAP也好，Rest也好，想象成调用SDK的API，从一个固定语言，变成了任意语言。
这些东西，找到了specification，看两遍，写俩程序就OK了。
不过，现在大趋势是RestFUL。XML会慢慢变成大数据feed和consume用，而这种需要快
捷的通信JSON还是更好一些，负担小！ |
