geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: How does the Client Container work?
Date Tue, 29 Sep 2009 16:02:54 GMT
As you have discovered, app client containers are not very thoroughly  
specified.  And as various pieces of documentation indicate, ours  
currently works only on the same machine as the server and there may  
be problems extracting just the bits you need to run an app client.   
However I still think that the problems of extracting a minimal client  
assembly and configuring it to talk to a remote server are pretty easy  
to solve.

I'm not very familiar with jnlp but wonder just how suitable it would  
be for this in geronimo.  Geronimo tends to have a lot of small jar  
files and various configuration files arranged in a particular  
directory structure (that it maintains) and that are related through  
geronimo classloaders.  My understanding of jnlp is that it is more  
oriented towards downloading plain jar files that are maintained by  
the jnlp infrastructure.  I would think that the most convenient way  
to get a geronimo app client would be to generate a client assembly,  
package it, download it, and unpack it in a suitable location on the  
client machine.  I don't know if something like this is practical with  
jnlp.  I guess it might be possible to do something like putting the  
entire server in a jar and write more classloaders to access  
everything from inside the jar.  I think ClassWorlds tries to do this  
but all my attempts in this line haven't worked very well.

thanks
david jencks

On Sep 29, 2009, at 3:31 AM, Quintin Beukes wrote:

> 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 http://jcp.org/en/jsr/
> detail?id=056; more information on Java Web Start is available at  
> http://
> java.sun.com/products/javawebstart.
>
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 12:24 PM, Quintin Beukes <quintin@skywalk.co.za 
> > 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 <quintin@skywalk.co.za 
>> > 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 <quintin@skywalk.co.za 
>>> > 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 a
>>>>   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 <quintin@skywalk.co.za

>>>> > wrote:
>>>>> 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 <david_jencks@yahoo.com

>>>>> > wrote:
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>> http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680
>>>>>>> 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 there
>>>>>>> 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 this
>>>>>> up well.  I think that you can use the "extract a server"  
>>>>>> feature to create
>>>>>> 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 be
>>>>>> minor bugs in dependencies in geronimo plugins.  This ought to  
>>>>>> work right
>>>>>> 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 only
>>>>>> run on the same machine as the server.  I think this would be  
>>>>>> an easy thing
>>>>>> to change, and I think the code would be somewhere in geronimo- 
>>>>>> client.  I'm
>>>>>> not sure what a good way to _tell_ the app client where the  
>>>>>> server is might
>>>>>> be.  Any ideas?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Juergen
>>>>>>>
>>>>>>>
>>>>>>> David Blevins wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Right.  You boot the app client container from the command
 
>>>>>>>> line, the
>>>>>>>> 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:
>>>>>>> http://www.nabble.com/How-does-the-Client-Container-work--tp25632603s134p25657764.html
>>>>>>> Sent from the Apache Geronimo - Users mailing list archive at
 
>>>>>>> Nabble.com.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


Mime
View raw message