JAVA Swing客户端，远程数据库数据访问； 伊巴蒂斯
我有一个 Java 客户端需要访问远程数据库。 目标是向用户隐藏数据库凭据，而不是在代码中硬编码任何凭据。 因此，数据库访问可能必须在服务器端。
我仅限于使用 Ibatis 作为数据抽象框架。 除此之外，我在网络服务器上运行 JBoss，允许我使用数据源。
您将如何设计远程数据库访问和数据序列化/反序列化。 您是否更喜欢某种数据流的 Web 服务而不是套接字？ 您如何实现两者中的任何一个？
I've got a Java client that needs to access a remote database. It is the goal to hide database credentials from the user and not hardcode any credentials within the code. Therefore, the database access will probably have to be on the server side.
I'm restricted to use Ibatis as a data abstraction framework. Apart from that I have JBoss running on the webserver, allowing me to use data sources.
How would you design the remote database access and data serialization/deserialization. would you prefer web services of some kind of data stream over a socket? How would you realize either of both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
构建一个服务层并通过 RMI 公开它 - 可能作为 EJB3 无状态会话 bean，就像您拥有 JBoss 一样，也可能作为纯 RMI。 除非您有特定需求，否则我不会打扰网络服务。 RMI 将为您处理序列化的情况。
您的服务层需要公开一种方法，使用在 Swing 应用程序启动时输入的凭据来对用户进行身份验证。 所有数据调用都经过服务层。 Swing 应用程序中不存在 SQL。
除了隐藏数据库凭据之外，这种安排还有其他好处。 您不仅最终得到分层架构，而且通过在服务器上拥有单个数据源，您可以通过在所有客户端之间共享准备好的语句来提高效率。
Build a Service Layer and expose it over RMI - possibly as EJB3 stateless session beans as you have JBoss, possibly as pure RMI. I wouldn't bother with web services unless you have a specific need. RMI will take case of serialisation for you.
Your service layer needs to expose a method to authenticate users using their credentials entered on startup of the Swing app. All calls for data go through the service layer. No SQL exists in the Swing app.
There are other benfits of this arrangment other than just hiding the database credentials. Not only do you end up with a layered architecture, but you gain efficiencies from sharing prepared statements amongst all your clients by having a single data source on the server.
那么您希望用户能够在不知道凭据的情况下访问数据库吗？ 您唯一的选择是服务器端数据库访问。 不幸的是，在 Java 中无法隐藏用户名和密码——如果将其放入属性文件中并对其进行加密，坚定的攻击者仍然可以附加调试器并查看代码中保存的值。
另外，除非您通过安全连接连接到数据库，否则有人可以运行数据包嗅探器（例如 tcpdump）并在那里获取凭据。
您说您正在运行 JBoss 服务器，最好的办法可能是设置远程 EJB，以便您的客户端应用程序不会直接访问数据库 - 它必须通过您的 EJB 方法。 （它不一定是 EJB，顺便说一句，如果您愿意，您可以执行诸如 Web 服务之类的操作）。
关键是，您的服务器直接与数据库对话，而您的客户端的唯一访问是通过您在服务器上定义的一组有限的接口。
So you want users to be able to access the database without knowing the credentials? Your only option is server-side database access. Unfortunately there is no way of hiding the username and password in Java -- if you put it into a properties file and encrypt it, a determined attacker could still attach a debugger and see what values are being held in your code.
Also, unless you're connecting to the DB over a secure connection someone could run a packet sniffer such as tcpdump and get the credentials there.
You say that you're running a JBoss server, what might be best is to set up remote EJBs so that your client application doesn't access the database directly - it has to go via your EJB methods. (It doesn't have to be EJB, by the way, you could do something such as web services if you prefer).
The point is, your server talks to the databas directly, and your client's only access is via a limited set of interfaces you define on the server.
正如已经说过的，您必须连接到处理数据库连接的服务器。 30 分钟的努力是无法有效阻止某人破坏您的安全的。
如果客户端在 Intranet 内进行本地连接，那么在应用程序服务器上使用 EJB 可能是最佳选择...尽管您可能需要无状态会话 Bean，但我不一定会折扣消息驱动 Bean。
对于来自外部的较长距离的流量，我会使用 HTTPS 上的 Web 服务。
无论如何，大多数应用程序服务器都具有通过 WSDL 将其 EJB 公开为 Web 服务的机制； 并且有大约一百个实用程序可以从 WSDL 生成客户端、调用 Web 服务（axis 的 wsdl2java 工作得足够好）
As has been already said, you have to connect to a server which handles the database connection. There is no way to effectively prevent someone from breaking your security, with 30 minutes of effort.
If the clients are connecting somewhat locally, within an intranet, using EJB's on your appserver is probably the best choice... though you probably want stateless session beans, i wouldnt necessarily discount message driven beans.
For longer distances where the traffic is coming from the outside, I would use webservices over HTTPS
In any event, most appservers have mechanisms to expose their EJB's as webservices, with the WSDL; and there are about a hundred utilities to generate clients, to call the webservice, from a WSDL (axis's wsdl2java works well enough)