Application clients

Application clients are the client applications that are also Java EE components. They differ from Java clients that have access to the server environment and run inside a client container. The client container runs in a separate JVM instance and can be started from the command line. Application clients can be used for administration of the application that is deployed on the server, and can provide a rich client experience. Access to the server environment means that the application client has access to server-provided services such as the JNDI component context, security, and so on. It also provides access to administered objects and connection factories deployed on the remote server instance. Thus, it can access database pools and JMS resources configured on the server. In this section, we will first look at the elements that make up the Apache Geronimo-specific application client deployment plan. We will then look at an application client and how to run it.

Deployment plan

The schema of the application client deployment descriptor is shown in the following figure:

The deployment plan needs to be packaged along with the Java EE-specific deployment descriptor in the META-INF directory of the application client JAR file. It can also be included in the Apache Geronimo-specific application deployment plan if the application client is packaged along with the application in the application's EAR file. You can also specify the plan separately during the deployment of the application client, in which case there are no restrictions on the filename. The elements in the deployment plan are given below:

• server-environment: This defines the server-side module environment settings for the application client. It consists of the following sub-elements:

  

• moduleId: The ID of the server-side module.

  • dependencies: Server-side dependencies that the application client has.

  • hidden-classes: Classes that should be hidden from the parent class loaders so that they are picked up from the current module's class loader.

  • non-overridable-classes: Classes that cannot be overridden by the user and will always follow the parent-first delegation method.

  • inverse-classloading. If this element is present, the classes will be loaded with a child-first class loading policy, whereas, when it is not present, the classes will be loaded with a parent-first policy.

  • suppress-default-environment: This is an element that is not recommended to be used as it may give unpredictable results.

• client-environment: This is the environment that the client container should provide for the application client to execute in. The elements inside this element are similar to the ones inside the server-environment element. The only difference is that they represent client-side artifacts.

  

• gbean-ref: This element is used to map Gbean references to actual Gbeans that are deployed on the server. The diagrammatic representation of this element is given in Appendix A, Deployment Plans.

• ejb-ref: The element ejb-ref is used to map EJB references to EJBs deployed in the server using the remote home and remote interface. The application that contains the EJB being referenced should be included in the dependency list of the application client's server environment. Also note that as the EJBs referenced are in a different JVM, all of the client interfaces should also be included in current application.

• service-ref: This element is used to map service references to web services that are deployed on the server.

• resource-ref: This element is used to map resource references to resources that are available on the server. The resources can be JDBC DataSources, JMS connection factories, or any other type that can be configured on the server. These resources are configured on the server side by using resource adapters.

• resource-env-ref: This element is used to map resource-env-ref elements to administered objects that are deployed on the server.

• message-destination: This element is used to configure references to a JMS queue or topic, which are actually message destinations.

  All of the references actually contain information that the client container needs to map the names to actual resources and Java EE components in the server so that it can make these resources or components available in the JNDI context for the application client.

  
  

• default-subject: This is the subject that would be used for authentication by the client when no subject is provided.

• realm-name: This is the name of the security realm that is configured in the server that the application client will use for validating the supplied JAAS login credentials.

• callback-handler: This is the fully-qualified name of the JAAS callback handler class. This class should implement the javax.security.auth.callback.CallbackHandler interface, and have a no arg constructor. It will be instantiated and used to collect authentication information from the user.

• resource: This element is used to define any module-scoped resources. The resource can be either external or internal to the application client. The connector element contains the plan for configuring the resource adapter. The pictorial representation is shown in the following figure:

  

• service: This is an empty generic element that can be extended by other modules. This is imported from the geronimo-module-1.2.xsd schema.