应用程序客户端和独立客户端之间的区别
正如标题所示，这尤其与 Java EE 和 Glassfish 有关。
据我所知，应用程序客户端是在某些能够与 glassfish 通信的应用程序客户端中执行的。但关于注释似乎存在局限性。
有人能给我举一个例子，说明从两种不同的应用程序类型连接到 glassfish 应用程序服务器的差异吗？
有人能给应用程序客户端方法的好处是什么？在为 Java EE 开发应用程序客户端时最常用的方法是什么？
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这两种情况下，与连接到应用程序服务器相关的代码（您需要做的工作）并不是那么难......但它在不同的文档中都有介绍。
这些是有关如何从独立 Java 应用程序访问 EJB 的说明< /a>.
以下是使用应用程序客户端通过 GlassFish v3 从 Java EE 6 应用程序客户端访问 EJB 的说明：http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en& a=view
与“直接”使用 EJB 相比，从应用程序客户端访问 EJB 可以让您“自动”访问更多 Java EE 服务。您可以在独立情况下拼凑对其中一些服务的访问权限，但使该访问正常工作的负担转移到应用程序开发人员/部署人员身上。
在短期内，创建访问 EJB 的独立应用程序似乎很容易，并且许多人会投资于该策略。如果他们将客户端应用程序部署到大量计算机上，则与拼凑在一起的服务访问策略相关的负担可能会成为一种负担。
部署使用应用程序客户端容器的应用程序客户端也不是免费的。优点是您可以获得应用程序服务器供应商的支持来克服部署问题。
如果您使用 GlassFish（v2.1、v2.1.1 或 v3），您还可以利用 Java Web Start 支持，这大大简化了客户端应用程序部署。
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
应用程序客户端实际上在容器中运行，并且可以像 Servlet 或 EJB 一样完全访问服务器上定义的 Java EE 资源。这通常用于某种类型的管理客户端，而不是用户应用程序。 这里有一个解释。
除了 Java EE 应用程序客户端之外，还有 瘦客户端，它也允许访问一些 Java EE 资源，但不如应用程序客户端那么容易。它通常涉及使用带有绝对名称的 JNDI 查找，因为 JNDI 引用不可用。一个典型的例子是 JMS 消息的独立生产者/消费者。它基本上是完整应用程序客户端的轻量级选项。
如果您只是创建一个用户应用程序，那么您很可能希望使用瘦客户端模型，或者只是通过 servlet 或 Web 服务调用使用 Java EE 应用程序中的服务的普通旧应用程序。
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.