h**k
发帖数: 662 | 1 what is best to use to create Java Desktop GUI? thanks |
z****e
发帖数: 54598 | |
T*********g
发帖数: 496 | 3 swt/jface.
【在 h**k 的大作中提到】
: what is best to use to create Java Desktop GUI? thanks
|
t***e
发帖数: 3601 | |
h**k
发帖数: 662 | 5 如果.net写前端，java写server是不是不错 |
k***r
发帖数: 4260 | 6 怎么talk呢，webservice很慢的
【在 h**k 的大作中提到】
: 如果.net写前端，java写server是不是不错
|
g*****g
发帖数: 34805 | 7 webservice is not necesarily slow. And if it's really slow
for you, consider restful service.
【在 k***r 的大作中提到】
: 怎么talk呢，webservice很慢的
|
k***r
发帖数: 4260 | 8 At work we provide both RMI and web service. Web service
takes overall 10x-20x time as RMI. I'm not sure if all is
because of webservice but I suspect it's one of the major
contributors.
【在 g*****g 的大作中提到】
: webservice is not necesarily slow. And if it's really slow
: for you, consider restful service.
|
g*****g
发帖数: 34805 | 9 My experience with web service is generally pleasant,
definitely not 10x slower than RMI.
【在 k***r 的大作中提到】
: At work we provide both RMI and web service. Web service
: takes overall 10x-20x time as RMI. I'm not sure if all is
: because of webservice but I suspect it's one of the major
: contributors.
|
F****n
发帖数: 3271 | 10 If you have a lot of objects to send then WebService will definitely be much
slower
【在 k***r 的大作中提到】
: At work we provide both RMI and web service. Web service
: takes overall 10x-20x time as RMI. I'm not sure if all is
: because of webservice but I suspect it's one of the major
: contributors.
|
|
|
k***r
发帖数: 4260 | 11 Indeed. Or, if you have a series of calls to make, the latency
becomes much more obvious.
much
【在 F****n 的大作中提到】
: If you have a lot of objects to send then WebService will definitely be much
: slower
|
g*****g
发帖数: 34805 | 12 You should try to use a Facade pattern to consolidate the
parameters if you can.
【在 k***r 的大作中提到】
: Indeed. Or, if you have a series of calls to make, the latency
: becomes much more obvious.
:
: much
|
m******t
发帖数: 2416 | 13
If by "web service" you guys mean soap, most client toolkits
these days support "keep alive" connections to mitigate the
latency problem.
Of course being chatty is never a good practice in any rpc
programming.
The poor performance of soap compared to rmi could mostly
be attributed to the xml marshalling cost. One project I worked
on, we had huge loan objects to ship over the wire and Axis
just couldn't handle it. We ended up doing binary serialization
ourselves and wrapping the bytes in a soa
【在 k***r 的大作中提到】
: Indeed. Or, if you have a series of calls to make, the latency
: becomes much more obvious.
:
: much
|
k***r
发帖数: 4260 | 14 What kind of problems did you have with Axis?
Wrapping binaries in XML doesn't sound very efficient
either to me ...
【在 m******t 的大作中提到】
:
: If by "web service" you guys mean soap, most client toolkits
: these days support "keep alive" connections to mitigate the
: latency problem.
: Of course being chatty is never a good practice in any rpc
: programming.
: The poor performance of soap compared to rmi could mostly
: be attributed to the xml marshalling cost. One project I worked
: on, we had huge loan objects to ship over the wire and Axis
: just couldn't handle it. We ended up doing binary serialization
|
g*****g
发帖数: 34805 | 15 When performance is a concern, you can always try binary
protocol like hession.
【在 k***r 的大作中提到】
: What kind of problems did you have with Axis?
: Wrapping binaries in XML doesn't sound very efficient
: either to me ...
|
m******t
发帖数: 2416 | 16
One word: size. We had these huge objects, and the developers
chose to give the classes and properties _real_ long names. So
Each object ends up in megs after being marshalled into xml.
【在 k***r 的大作中提到】
: What kind of problems did you have with Axis?
: Wrapping binaries in XML doesn't sound very efficient
: either to me ...
|
k***r
发帖数: 4260 | 17 Thanks. It looks interesting and looks like a good fit
for some binary data heavy scenarios. Do you have any
experience with it?
【在 g*****g 的大作中提到】
: When performance is a concern, you can always try binary
: protocol like hession.
|
k***r
发帖数: 4260 | 18 Tried compression before sending data on wire?
【在 m******t 的大作中提到】
:
: One word: size. We had these huge objects, and the developers
: chose to give the classes and properties _real_ long names. So
: Each object ends up in megs after being marshalled into xml.
|
g*****g
发帖数: 34805 | 19 Yes, we use it for our production. The good thing is that
spring has built-in support for it, and it actually has
C++ support too (which we never tried).
【在 k***r 的大作中提到】
: Thanks. It looks interesting and looks like a good fit
: for some binary data heavy scenarios. Do you have any
: experience with it?
|
m******t
发帖数: 2416 | 20
We could have done that perhaps by plugging code into axis and
customizing the marshalling logic, but the developer in charge of it
chose the easy way out. 8-)
【在 k***r 的大作中提到】
: Tried compression before sending data on wire?
|
|
|
k***r
发帖数: 4260 | 21 That's good to know. So you use a mixture of protocols?
Or all hession?
【在 g*****g 的大作中提到】
: Yes, we use it for our production. The good thing is that
: spring has built-in support for it, and it actually has
: C++ support too (which we never tried).
|
g*****g
发帖数: 34805 | 22 Of course you use a mixture of protocols.
binary protocols may not work with a firewall.
Usually you design it in the way that they are
interchangable. If you are using spring, it may
just be some different configuration on the server
side.
【在 k***r 的大作中提到】
: That's good to know. So you use a mixture of protocols?
: Or all hession?
|
k***r
发帖数: 4260 | 23 I mean, in the same application?
【在 g*****g 的大作中提到】
: Of course you use a mixture of protocols.
: binary protocols may not work with a firewall.
: Usually you design it in the way that they are
: interchangable. If you are using spring, it may
: just be some different configuration on the server
: side.
|
g*****g
发帖数: 34805 | 24 It always depends. WS is the more ubiquitous solution
that can easily tunnel through firewall. RMI, Hessian etc.
may be restricted on your deployment firewall settings,
which may or may not be possible.
We have a server that talks hessian with admin console through
vpn, and WS with clients. I think you can always start with
RPC style WS, like spring + CXF for minimum efforts. And
seek necessary alternatives when the requirement is more clear.
There's no one fit all solution.
【在 k***r 的大作中提到】
: I mean, in the same application?
|
m******t
发帖数: 2416 | 25
I'm not sure I would consider firewall a major issue.
RMI also supports http tunneling. Hessian (normally)
runs over http to begin with.
【在 g*****g 的大作中提到】
: It always depends. WS is the more ubiquitous solution
: that can easily tunnel through firewall. RMI, Hessian etc.
: may be restricted on your deployment firewall settings,
: which may or may not be possible.
: We have a server that talks hessian with admin console through
: vpn, and WS with clients. I think you can always start with
: RPC style WS, like spring + CXF for minimum efforts. And
: seek necessary alternatives when the requirement is more clear.
: There's no one fit all solution.
|
