geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
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 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