top

The Geronimo application clients can be connected to the Geronimo server in differnt styles.Following styles are indentified as usual clients styles.

• A web browser or other web client, used to interact with a web application running in Geronimo
• A web services client, used to interact with web services in a web application or EJB JAR running in
Geronimo
• A CORBA client, used to interact with EJBs running in Geronimo
• A typical Java applet or application, used to interact with EJBs running in Geronimo
• A J2EE application client, used to interact with EJBs and other resources running in Geronimo.

The following topics will be covered the the Geronimo Deployment Plans for J2EE application client.In this section it will cover the behavior of the J2SE application clients which are basically applets,normal application clients who dosen't need the advantage of the Geronimo server itself implementation features to handle the clients.

The Client Geronimo Deployment Plan
=====================================
The Geronimo application clients can be connected to the Geronimo server in differnt styles.Following styles are indentified as usual clients styles.

•A web browser or other web client, used to interact with a web application running in Geronimo
• A web services client, used to interact with web services in a web application or EJB JAR running in Geronimo
• A CORBA client, used to interact with EJBs running in Geronimo
• A typical Java applet or application, used to interact with EJBs running in Geronimo
• A J2EE application client, used to interact with EJBs and other resources running in Geronimo

It's worth to discuss some behaviors of varity of clients in Geronimo in detail.A standard applet, application, or Java Web Start application (also known as a J2SE Application Client)doesn't take advantage of any particular J2EE features to connect to the server. That means the process
is somewhat more manual and cumbersome, and the client is restricted to interacting with EJBs on the server. However, the client can be run in the same way as any other Java applet or application.

A J2EE application client, in contrast, is packaged as a J2EE component (in a client JAR), and is run using a J2EE application client container. Running in the client container gives the J2EE application client some advantages are follows

It can map resources into a private java:comp/env/ JNDI space (like EJBs or web ap-
plications can)

It can connect to a wider variety of resources on the server. However, it can't be run
as a standalone Java applet or application.

It must be run within the Geronimo client container.

14.2. J2EE Application Clients
================================

A J2EE application client has several advantages over a J2SE client, as a result of running in a client container:

• It has access to a component-local java:comp/env/ JNDI space like other j2EE components.
That means that EJBs and other resources can be declared and placed in that JNDI space, and then resolved to actual server resources using a deployment descriptor.

• While normally only EJBs can be accessed remotely, the client container can handle remote access to J2EE connectors, meaning database connection pools and JMS resources are available to the application, as well as any third-party connectors.

• The container can handle the server login process, providing secure access to the server without requiring specific application security code.
Generally speaking, these advantages mean that a J2EE Application Client is more portable than a J2SE
client, since server-specific security and resource access code can be eliminated in favor of configura-
tion in the deployment plan. However, this does mean that every application client requires a standard
J2EE deployment descriptor (META-INF/application-client.xml), and most likely a Geron-
imo deployment plan.

Steps for creating J2EE client jar
===================================
• Geronimo requires that every client JAR file has a standard META-INF/application-client.xml deployment descriptor. This may be for J2EE 1.2, J2EE 1.3,
or J2EE 1.4, and should follow the appropriate XML format (see below).

• If the client JAR file is included in an application EAR, then Geronimo will respect Class-Path
entries in the META-INF/MANIFEST.MF file of the client JAR. Any JARs referenced there should
also be packaged within the EAR, and paths to JAR files will be resolved relative to the position of
the client JAR file in the EAR. If the client JAR file is not included in an EAR, then manifest class
path entries will be ignored. In either case, external libraries can also be placed in the Geronimo server repository and referenced with dependency elements in the Geronimo deployment plan

• The application client should have a class with a method public static void
main(String args[]) just like a traditional client. The client JAR should have a Manifest file
with a Main-Class entry pointing to the class with the main method (in other words, it should be
a standard executable JAR). A typical Manifest file might look like this:
Manifest-Version: 1.1
Main-Class: com.geronimo.MainClient

The Geronimo application client deployment plan
===============================================

The geronimo-application-client.xml Geronimo deployment plan for an application client
JAR is an XML document. It is defined by the geronimo-application-client.xsd schema,
which can be found in the schema/ subdirectory of the main Geronimo installation directory. The Geronimo deployment plan for a client JAR

• Included in the client JAR, in which case it should be named META-
INF/geronimo-application-client.xml
• Included in an EAR (but outside of the client JAR) and referenced by an alt-dd element of the
EAR deployment plan (This has been widly discussed in the EAR geronimo-application.xml in "configuring application modules")

• Saved as a separate file and provided to the deploy tool when the client JAR module is deployed
(though this doesn't work when the client JAR is in an EAR).

• Created from scratch using a JSR-88 configuration tool, in which case the tool manages saving and loading the deployment plan and passing it to the server when the client JAR is deployed. For more
information on JSR-88 tools see Section 10.6, "JSR-88 Configuration & Deployment Tools".
The deployment plan should always use the Geronimo client namespace, and it typically requires ele-
ments from the Geronimo Naming, Geronimo Security, and Geronimo System namespaces. Addition-
ally, it has a required attribute to identify its configuration name, and an optional attribute to select a par-
ent configuration. A typical client deployment plan looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<application-client
xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-client"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming"
xmlns:security="http://geronimo.apache.org/xml/ns/security"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment"

...
</application-client>

In contrast to other Geronimo deployment plans, the application client has a Config ID and Parent ID for
both the server-side client configuration and the client-side client configuration. The configId and paren-
tId elements apply to the server's environment, so when that configuration is running, its dependencies
may force other resources to be available in the server environment. The clientConfigId and clientParen-
tId apply to the client container environment, so the clientConfigId will be used to start the client and the
clientParentId is not typically very useful.

In any case, a full description of the attributes here is:
xmlns The main namespace for the deployment plan, which should always be ht-
tp://geronimo.apache.org/xml/ns/j2ee/application-clien
t
xmlns:naming A secondary namespace, used to identify the common elements for resolving
EJB references, resource references, and web services references. If any of those
need to be resolved in the deployment plan, this attribute must be present, and
should be set to http://geronimo.apache.org/xml/ns/naming

xmlns:security A secondary namespace, used to identify the common elements for security con-
figuration. If there are any security settings in the deployment plan, this attribute must be present,and should be set to http://geronimo.apache.org/xml/ns/security
xmlns:sys A secondary namespace, used to identify the common elements for common lib-
raries and module-scoped services. If there are any of those present in the de-
ployment plan, this attribute must be present, and should be set to ht-
tp://geronimo.apache.org/xml/ns/deployment

moduleId A unique name identifying this module on the server side. If deployed as a stan-
dalone client JAR, this name is used to identify the module to the deployment
tool. It can be used to start or stop the server-side module (any dependencies are
only forced to be running while this module is running), as well as to undeploy
or redeploy the client JAR as a whole.
groupId Identifies the parent configuration for the server-side module (the value specified
here should match the configId for the parent module). If deployed as a stan-
dalone client JAR, this can be used to make the client JAR depend on another
module such as a database pool or JMS configuration (or it should otherwise be
set to the usual parent for J2EE modules, geronimo/j2ee-server/1.0/car). If de-
ployed as part of an EAR this is usually not necessary, as EAR configuration will
be the parent of this module, and it will inherit dependencies from the EAR. In
any case, this only controls dependencies that must be running on the server side;
it does not actually change the ClassPath of the application client itself.
clientConfigId A unique name identifying the client-side application module. This name is used
to identify the module to the client container (to run the application client). This
name should not be used with the normal deploy tool, only the client container.
clientParentId Identifies the parent configuration for the client-side applciation module (the
value specified here should match the configId for that module). This should
normally be omitted or set to the usual parent for clients,
geronimo/client/1.0/car.

The Typical content of the Geronimo Client Deployment plan
===========================================================

The Geronimo deployment plan for application clients is usually contained with the following typical components with relative to complexity of the application.Further, for the simplest application clients following settings may not be required or the defaults may be sufficient,but in most cases the Geronimo application client deployment plan will need a substantial amount of information.

• Class path customization for the application client.

• Security settings indicating what the default user should be, if no login information was provided in
the standard application-client.xml file (using the callback-handler element).
• Details to resolve EJB references, resource references, and web services references declared by the client in the application-client.xml deployment descriptor. This isn't always necessary for
EJB references (which may be resolved using an in the ejb-link
application-client.xml) but generally is for the other types of references.

Strcutural Overview of the Deployment Plan.
===========================================================

Class Path settings
===========================================================

Resolving references
============================================================
1.Resolving EJB Referances
2.Resolving Web Service References
3.Resolving Resource References
4.Security Settings
5.Embedded Resource Adapter Deployments
6.Adding Module-Scoped Services
7.J2SE Application Clients
8.Client Authentication