这样的系统用webservice技术开发是最合适的吗？

各位jdon的兄弟们，希望你们出来帮我看看我现在遇到的系统用什么技术来架构最合适。

首先，我简要描述一下这个系统的主要功能。此系统的目标是建立一个公共的查询系统，为其他系统提供查询数据库的接口。客户的想法就是建立一个查询服务平台，其他系统或者外部单位的系统发送查询参数给查询服务平台这个系统，服务平台就返回结果给他。这样就把对数据库的查询的操作全部交给了查询服务平台了，其他系统就不需要和数据库交互。这个系统大概就是这个功能。

原来他们也有这个查询服务接口的程序，但是是用java的套接字实现的查询返回，原来的程序是写的一个方法（一个参数），方法里判断根据参数的来执行相应的查询，这样里面就产生了很多的if 语句 还产生了很多的参数的格式。原来的代码查询的效率也不高。所以他们想升级这个系统。但是还要保持和原来的兼容，因为很多其他系统在用。

现在我的想法是用webservice来实现这个这个系统，用spring做整体框架，ibatis来做ORM,不知道这样来实现行不行，还要考虑的是大并发的请求查询下，系统的效率问题。
请各位，给点建议，非常感谢
[该贴被fenghualin于2009-03-30 20:56修改过]

要不要穿透防火墙？要的话就webservice了，很好用，效率当然不咋好。另有rmi方式可考虑，能不能让开端口就另说了。socket效率应该最优吧，代价太大，不推荐。

我觉得WebService的方法不错。不过不建议你用Spring，直接用EJB3比较好。EJB3的会话Bean可以很容易被发布为WebService，如果对方对性能要求更高，那么EJB3远程访问也可以提供。
对WebService的速度问题其实不用太担心。一个性能不差的ESB服务器日访问量起码能撑到百万级。这个数据是我从Bea的ESB开发工程师写的书上得来的，他说他搭建过日访问量100W的ESB服务器。这本书是我去年在Bea活动中得的，加上中文翻译时间，写作时间不会晚于2007年，也就是说至少06、07年，WebService就可以承受百万级的访问。

谢谢,你的回复,我昨天也想了下,考虑到系统的性能,需要集群来分布式,新增功能用ejb直接发布不用重启服务,我觉得还是用ejb比较好了.现在考虑的ORM用什么来好是JPA还是IBATIS?
ibatis在查询效率上有优势,但是缓存方面没什么优势,不过这种提供查询接口的系统是不是适合缓存,缓存的命中率会不会高??

这里面根本就不用考虑缓存的问题，你的调用端是希望从你得到准确的数据还是希望得到可能准确的数据那？？如果他想提升客户体验，他可以对结果进行缓存，而不是你的服务需要缓存，而且如果对于数据量比较大的返回，希望慎重考虑webservice。

按需求看，只需要个纯粹的C/S架构。简单的，可以多个客户机直连一个数据库服务器。复杂点，中间加个应用服务器。希望穿透防火墙，就用B/S。
WebService是松耦合分布式架构，在这里好像英雄无用武之地吧？
我把楼主的需求搞得复杂点：一个查询平台，但自身没有信息（或者只有部分信息）。客户机甲来查气象，它就调取气象局的信息；客户乙来询问列车时刻，它就咨询火车站。。。这种才需用WebService。

如果数据流大，我们平台就提供分页查询的方法给他们。

beepbug，你怎么认为这个不适合webservice呢，这个就是提供给所有的外部系统的查询的接口。要求跨语言平台。

》》》》》原来他们也有这个查询服务接口的程序，但是是用java的套接字实现的查询返回
既然原来的方式使用套接字，现在重写一个web service有什么明显的意义么。如果考虑兼容性则必须重新使用套接字实现，否则必须实现一个协议网关了，这样的方式很麻烦的。

以前的套接字程序很乱，直接jdbc 代码也不规范。

现在随着业务的扩大，已经不能满足查询的性能要求了。

现在想做一个能满足大并发的，我想用EJB来做发布为service。

>>> beepbug，你怎么认为这个不适合webservice呢，这个就是提供给所有的外部系统的查询的接口。要求跨语言平台。

那你怎么认为这个需要webservice呢？再说，webservice也不是为了解决“跨语言平台”问题。如果你认为你的需求真需要“跨语言平台”，那你该找.NET才对。它才是“跨语言平台”。

我不知道楼主这次的项目是什么目的的，是一个全新的项目还是一个旧项目的改造，如果是前者你可以重新考虑系统的架构，所使用的语言，以及搭建的平台，如果是改造，我觉得你应该重新考虑你的方案。如果现在已经有了大量的客户端，你对于客户端的更新将是一个很大的工作，而且还存在使用、培训等一系列的工作，从软件的角度上来说，最好的方法应该是平滑升级，只有万不得已才会使用更新平台的方式。
你现在觉得乱只是因为你看到里面大部分的if语句，其实这个问题从设计模式上很容易解决。使用反射，或者对象池的方法完全可以解决这个问题。而且也有利于你的负载均衡，而客户端的代码不需要任何的改动。

>>>那你怎么认为这个需要webservice呢？再说，webservice也不是为了解决“跨语言平台”问题。如果你认为你的需求真需要“跨语言平台”，那你该找.NET才对。它才是“跨语言平台”。

本系统客户指定用J2EE,我现在了解的就只有用套接字和webservice可以提供其他web程序调用.没这方面的经验所以来请教大家.

>>>>>>我不知道楼主这次的项目是什么目的的，是一个全新的项目还是一个旧项目的改造，如果是前者你可以重新考虑系统的架构，所使用的语言，以及搭建的平台，如果是改造，我觉得你应该重新考虑你的方案。如果现在已经有了大量的客户端，你对于客户端的更新将是一个很大的工作，而且还存在使用、培训等一系列的工作，从软件的角度上来说，最好的方法应该是平滑升级，只有万不得已才会使用更新平台的方式。
你现在觉得乱只是因为你看到里面大部分的if语句，其实这个问题从设计模式上很容易解决。使用反射，或者对象池的方法完全可以解决这个问题。而且也有利于你的负载均衡，而客户端的代码不需要任何的改动。

这个项目应该是一个全新的升级,客户觉得以前那个套接字程序太简单,不能控制访问的来源,连接的数量,和性能的监控.他们需要重新来架构,使得可以管理连接请求.提高系统的性能.如果改造以前的代码也就是相当于重写了.请问这里考虑用ejb3来实现怎么样,应为系统会有经常加业务功能,这样必须加代码,如果ejb就可以在加新业务代码的时候不引起老代码的bug,发布也可以不用重启服务

首先我不知道要求你这样做的公司是一个什么样子的公司，他的技术负责人是否真的明白什么是J2EE以及明白在部署实施上会存在什么问题。不过如果你后台业务经常变更，那么你的客户端是否需要变更？？变更采用自动升级还是手动升级的方式？？是否系统中允许多版本存在？？

socket简单么？？呵呵，不觉得，而且也很容易控制来源、数量和性能的监控，这些很多通讯中间件都有这样的功能。不过如果客户指定要使用j2ee那就不要考虑了。不过如果是你们公司自己考虑的，那么我建议你可以考虑使用通讯中间件来解决这个问题。

其实现在不是主要考虑怎么通信的问题,而是系统性能和扩展性的问题.怎么处理大并发的问题

下页