JAVA GUI客户端和SERVER通讯的问题

Question

想从GUI客户端上传送一些数据到SERVER的数据库上，不想在客户端直接连接数据库，想把数据库访问的代码放在SERVER端，有以下疑问：1 采用什么通讯方式？SOCKET, WEBSERVICE 还是其他
2 如果是SOCKET编程，是否需要写一个完整的SERVER端的SOCKET监听程序，有无现成的FRAMEWORK可以套用，因为从头写一个完整的SERVER端程序，并且要让它比较正确持久的在服务器上跑着，是需要久经考验的。总之想听听有无相关经验的高人做过这方面的事情，采取什么技术架构比较合理。主要是确保服务端程序的健壮性和可靠性，并且尽量避免从头写这么一个东西

Answer 1

我比较倾向socket编server端，现在有好多java ftp小程序都是基于这类的，楼主可以去找一个看看里面的原理，ftp一般是操作文件的，稍微修改一下ftp的响应动作，让它操作数据库就可以了

Answer 2

问题就在于，做过WEB开发的同志应该知道，在SERVER端编写一个SOCKET的程序，相当于自己实现整个后台的MVC：用于解析派分SOCKET请求，乃至到一些简单的业务逻辑和数据层读写，实质上工作量不小，风险性挺高，如何规避这个工作量和风险？是否有成熟的框架可以借用。

Answer 3

MVC是什么意思,LZ懂吗?你说的话,就有问题!
Java的socket很简单的,根本没你想的那么复杂!
不就是传输点东西,然后操作数据库嘛!
你可以如果传输的东西比较简单,自己写个简单的传输协议,比如用'\0'标识结束,用","分割内容,
对传输建立一些机制,就是传输不成功如何处理,根本没想象的那么复杂

Answer 4

因为你指盯着SOCKET本身那当然不复杂，DEMO级别的代码又岂能和工业级别的代码相提并论，这里面的差别就如你所想的很简单，但是实际操作起来要考虑方方面面的问题。你没有实践到我提到的问题，自然觉得简单了。这个模型中显然是MVC的。V就是你的客户端，M就是从服务端获得的数据层操作结果，C就是用于分派请求的控制，很典型。因为你是服务端，你要处理好千百个客户端发来的各种SOCKET请求，对于何种请求做何种事情，光是搭出这么一个机制就相当于实现了一个简单的STRUTS，SPRING那样的MVC FRAMEWORK，你可以实现的简单点，但你有把握它足够强壮吗？还要写活在服务端的一个程序，用来持续监听客户端请求，这相当于实现了一个类似TOMCAT的容器，你也可以实现的很简单，但你有把握它足够强壮吗？如果做一个产品，我更倾向于有成熟的FRAMEWORK。而不是从头开发。

Answer 5

web service作为一个分布式开发的标准这个是很好用的,不过要考虑你的Client和Server的运算能力,至少在现在XMl解析还是一个压力满大的工作,你要先衡量一下你的请求数和服务器处理能力,如果web service可以满足你的要求,用web service也是个好的选择.如果web service你认为xml解析的性能开销不值得,那推荐你用socket编程,java的nio是个好东西,你如果自己对网络编程有经验可以直接用nio实现,否则我推荐你用cindy这个框架,可以减少你不少的开发工作.但是我不同意上面兄弟的观点,framework是个好东西,但是不见得性能最高,它是为了符合大多数人的要求而建立的,为了支持多数的项目需求而设计的,如果你自己实现只为自己业务实现,还是自行编码效率高一些.

Answer 6

建议用Socket,在JAVA里面,用socket编程,简直太容易了

Answer 7

我可以提供个基础的框架
使用ＳＷＩＮＧ界面
ｓｏｃｋｅｔ的通信
是一个产品的基础框架，处理数据量自己修改ｎｅｔ包下面的类
下面是例子，代码在主页里面
http://community.csdn.net/Expert/topic/5016/5016983.xml?temp=2.839297E-02

Answer 8

tomcat + axis 走 soap，扩充性好。

Answer 9

呵呵，楼上的有没有资料可以看看。性能开销又如何，有人说过WEBSERVICE的XML解析开销巨大

Answer 10

可以考虑用rmi通信，底层也是socket

Answer 11

我支持用Socket交互XML数据：Socket服务器可以不用自己写了，大部分WEB服务器如：tomcat就可以作这种工作（当然自己有兴趣又有时间和能力可以写写，可以通过看tomcat源码入门）；之所以用XML交互数据是对扩充性的考虑，另：XML的解析在带数据库的应用软件中我的经验是肯定不是主要瓶颈，网络与数据库等的I/O才是瓶颈。