geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Re: How does the Client Container work?
Date Tue, 29 Sep 2009 10:31:38 GMT
Interesting thing though. At the end of the spec it says:

EE.12.1           JNLP (JavaTM Web Start)
The Java Network Launch Protocol defines a mechanism for deploying Java
applications on a server and launching them from a client. A future
version of this
specification may require that Java EE products be able to deploy
application clients
in a way that allows them to be launched by a JNLP client, and that application
client containers be able to launch application clients deployed using the JNLP
technology. JavaTM Web Start is the reference implementation of a JNLP client.
     More information on JNLP is available at
detail?id=056; more information on Java Web Start is available at http://

Quintin Beukes

On Tue, Sep 29, 2009 at 12:24 PM, Quintin Beukes <> wrote:
> Hey,
> If you go read the JavaEE 5.0 spec regarding Application Clients, they
> do specify the following:
> As with all Java EE components, application clients use JNDI to look
> up enterprise
> beans, get access to resource managers, reference configurable parameters set at
> deployment time, and so on. Application clients use the java: JNDI namespace to
> access these items (see Chapter EE.5, “Resources, Naming, and Injection” for
> details).
> That is the closest they get to "remote". They do mention that the
> method of deployment/installation on a client is implementation
> specific, and it doesn't matter how they do it. So I guess my
> explanation is suitable for Geronimo, and Geronimo is on spec.
> It provides the authentication, and it is possible to do
> authentication against a remote server by configuring the security
> realm as such.
> Then you setup your server and deploy your application client.
> Further, any remote EJBs would be declared and defined as such, and
> there you have your fully JavaEE on-spec application client.
> If you think about it, this is a very logical design. Try and think of
> an application client as any other EJB jar. Have you ever asked
> yourself how to deploy an EJB jar in one server but have it wrapped by
> "another server"? The name "Application Client" sort of makes one feel
> this is a given, but it's misunderstood. Other application servers do
> provide this facility, and it would definitely be a nice-to-have.
> Though it's not a much used feature, and spending resources on other
> things is probably more important. After all, it's not impossible to
> achieve remoting. You just need to do it like you would with any other
> JavaEE component.
> Finally, I think the biggest motivation for an application client in
> the spec was for the same reasons as providing web based applications.
> A web based app is a UI into your application back ends. Just like
> this an application client is a UI into your application back ends.
> Both of them run inside a container, and uses whatever methods is
> available to access those back ends. The spec does specify security in
> the container is a requirement, so this helps out a bit with having
> the client be "very standalone".
> Quintin Beukes
> On Tue, Sep 29, 2009 at 11:56 AM, Quintin Beukes <> wrote:
>> I posted a link to the book on a new thread.
>> Quintin Beukes
>> On Tue, Sep 29, 2009 at 11:46 AM, Quintin Beukes <> wrote:
>>> Then further, a book written by IBM states:
>>> With WASCE, the following considerations apply:
>>>   Unlike other Java EE application servers, WASCE does not provide a unique
>>>   Application Client container. Instead, you must install the full
>>> server package
>>>   if you want to run an application client.
>>>   This is compliant with the Java EE specification, which does not require that
>>>   you provide a unique installation process for the Application
>>> Client container
>>>   (the specification only requires that it exists). Also, because WASCE has
>>>   very small server footprint of around 150 MB, the net disk space
>>> savings for a
>>>   special Application Client container most likely outweighs the
>>> realized benefit
>>>   of disk space.
>>> It doesn't say you need to be on the same installation, but it does
>>> say it needs to be deployed on a full installation. I did once try to
>>> extra the client as a plugin, but failed to then install the plugin. I
>>> think it's because the client is never really in a "started" state.
>>> Maybe you can deploy the "server side" of the plugin? But on geronimo
>>> it's 2 separate repo items. and you can't export them as a single
>>> plugin.
>>> Further, I once tried running the appclient from a separate
>>> installation, and all this achieved was port conflicts.
>>> From my struggles, this is what my conclusion was:
>>> I don't think the application client was really meant to be a way for
>>> remote clients to access the server, but rather for a local
>>> application to gain the benefits of JavaEE. Any "remoting" has to
>>> happen on the server layer, inside EJBs and what not.
>>> So you would develop your thick application client which is linked to
>>> the EJBs in the server. This is why there are 2 components to the
>>> application client, the server and client component. The client
>>> component runs inside the thick application container, and works with
>>> the server components to create a JavaEE environment for it. It's not
>>> meant to directly communicate with remote EJBs as if being a remote
>>> client.
>>> So to summarise (i'm probably repeating myself a lot here - having
>>> difficulty in explaining this - hope you understand). You get 2 types
>>> of JavaEE clients, thin clients and thick clients. Thin clients are
>>> directly connected to the remote server via a remote InitialContext,
>>> using corba/ejbd. Thick clients run inside a JavaEE environment, and
>>> is connected to remote clients using traditional JavaEE "remoting"
>>> techniques, such as remote EJBs. This is done inside the EJB layer.
>>> The actual "application client" part is purely for wrapping the
>>> application's parts inside the EE container.
>>> Quintin Beukes
>>> On Tue, Sep 29, 2009 at 11:31 AM, Quintin Beukes <>
>>>> There is a book Apache Geronimo Development and Deployment by Aaron Mulder
>>>> It states:
>>>> As of Milestone 4, the client container must run from the same
>>>> Geronimo installation as the server,
>>>> which also means that it must be run on the same machine, using the
>>>> bin/client.jar file in the
>>>> server's Geronimo directory. The command line to start a J2EE
>>>> application client looks like this:
>>>> java -jar bin/client.jar ConfigName [arg1] [arg2] [arg3] ...
>>>> I found the same problems with this, which is why I eventually ended
>>>> up building my own client framework using Spring. It's not as dynamic,
>>>> but I get similar features (ie. dependency injection, security, etc.).
>>>> Quintin Beukes
>>>> On Tue, Sep 29, 2009 at 9:17 AM, David Jencks <>
>>>>> On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote:
>>>>>> OK, thanks, so that is consistent to the way Weblogic server does
it, you
>>>>>> start the Weblogic client container  which then starts your client
>>>>>> application.
>>>>>> The Geronimo  Wiki says:
>>>>>> You can run the Application Client with this command:
>>>>>> %GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car
>>>>>> But how do you run the client container from a remote machine where
>>>>>> is
>>>>>> no Geronimo installation?
>>>>>> client -h shows no way to argument a Geronimo location.
>>>>> So far no one has shown enough interest in app client containers to set
>>>>> up well.  I think that you can use the "extract a server" feature to
>>>>> a geronimo assembly that contains your app client plugin and everything
>>>>> needed to run it.  You could then unpack this on the remote client machine.
>>>>>  This part should be easy to try out and any problems would most likely
>>>>> minor bugs in dependencies in geronimo plugins.  This ought to work
>>>>> now.
>>>>> However, IIRC the last time I looked there was no obvious way to configure
>>>>> the app client with the server IP address (or port), so it would really
>>>>> run on the same machine as the server.  I think this would be an easy
>>>>> to change, and I think the code would be somewhere in geronimo-client.
>>>>> not sure what a good way to _tell_ the app client where the server is
>>>>> be.  Any ideas?
>>>>> thanks
>>>>> david jencks
>>>>>> Thanks,
>>>>>> Juergen
>>>>>> David Blevins wrote:
>>>>>>> Right.  You boot the app client container from the command line,
>>>>>>> app client container does all the work to setup the environment,
>>>>>>> injects the required things into your main class, then calls
your main
>>>>>>> method.
>>>>>>> For all intense purposes the app client is really like a mini-server
>>>>>>> with a little Geronimo kernel and everything.
>>>>>>> -David
>>>>>> --
>>>>>> View this message in context:
>>>>>> Sent from the Apache Geronimo - Users mailing list archive at

View raw message