Here's an extract from a
post by Bill Shannon, Java EE Spec Lead, on
Java EE App Clients. I am evaluating the use of Java EE technology on the desktop to reduce the costs of delivering defect free multithreaded apps. The idea is to try to mostly let the Java EE container manage the threads and no server would be used. It's a complete Java EE on the desktop, standalone (no server). The Java EE container(s), server-side and client-side, would be running on the desktop. In the current Java EE design, the Java EE server-side container still runs on a separate host, but not in my experimental design. One could always have the application start the Java EE server-side container if it needs to when it starts (when the app starts that is).
The main difficulties may be in deployment, e.g., very large jars, the automation of the installation the Java EE container (on the desktop), etc., but these may still be simpler than producing defect free multithreaded apps without Java EE.
It looks like *
app clients* are applications running in a Java EE client-side container. The other alternative, of course, is to use a
browser for the user interface objects via
http to the Java EE code (on the desktop), instead of the Java SE GUI offered by an
app client.
Finally, here's the post that I promised:
Re: Java EE appclients vs standalone clientsPosted: Nov 27, 2006 1:40 PM Apparently there's some confusion over application clients. To quote from the Java EE platform spec:....Application clients are Java programming language....programs that are typically GUI programs that execute....on a desktop computer. Application clients offer a....user experience similar to that of native applications,....and have access to all of the facilities of the Java EE....middle tier.Application clients are not expected to execute on the server, although some people have found that useful in some situations.Application clients are simply standalone Java applications that execute in an environment that conveniently provides access to the Java EE facilities. It's the application client container that provides Java EE support to the application client program.Some people want to run "regular" Java SE applications, but have access to Java EE facilities without need for the application client container. Yes, you can do this. There's no magic here. But there is a lot of work. You can duplicate most or all of the work that the application client container is doing for you, and thus run your "standalone" Java EE client application without using the application client container....What we've done in GlassFish, and what we're considering adding to the specification, is add support for Java Web Start for deploying application clients. This allows the client desktop machine to download the application client program on demand.Some people want to use their own deployment approaches, automated or manual, for deploying their desktop applications. What they'd like is to have a simple, small jar file or other bundle that is their application client, and run that application just like they would run any other Java SE application. This is the case that drives people to "standalone applications" instead of application clients.What we should do is create a simpler "application client runtime", as similar as possible to the simple "java" command, that could be used to run these applications.The final deficiency, and one of the harder problems to solve, is that the application client container depends on the application server fairly heavily, e.g., for configuring access to resources. If the server is unavailable (due to network problems or whatever), the application client has no reasonable way to function in any sort of degraded mode until the server is available again. Improving this definitely requires work in the GlassFish implementation, and may also require changes to the Java EE specification.Bill ShannonJava EE Spec Lead Labels: concurrency, desktop, java, java ee, multi-threading, multithreading
