WAS v8.5 > WebSphere applications > Client applications > Types of client applicationsJava thin client
The Java thin client is a JavaPlatform, Standard Edition (Java SE) mode of using the runtime environment of either an Application Client installation or a WebSphere Application Server installation. The Java thin client runtime environment provides the support needed by full-function Java SE client applications for object resolution, security, Reliability Availability and Serviceability (RAS), and other services. However, the Java thin client does not support a Client Container that provides easy access to these services.
The Java thin client is sometimes referred to as the "Java thin application client".
The Java thin client is designed to support those users who want a full-function Java SE client application programming environment, to use the supplied IBM JRE, without the overhead of the Java EE platform on the client machine.
The Java thin client does not perform initialization of any of the services the client application might require. For example, the client application is responsible for the initialization of the naming service, either through CosNaming or JNDI APIs.
The Java thin client does not support the use of use of logical names ("nicknames") for enterprise beans and local resources. When a client application resolves a reference for an enterprise bean (using either JNDI or CosNaming), the application must know the location of the name server and the fully-qualified name used when the reference was bound into the name space. When a client application resolves a reference for a local resource, the client application cannot resolve to the resource through a JNDI lookup. Instead the client application must explicitly create the connection to the resource using the appropriate API; for example, JDBC or JMS. If the location of an enterprise bean or resource changes, the thin client application must also change the value placed on the lookup() statement.
The Java thin client runtime environment provides support for Java SE client applications to access remote enterprise beans, and provides the implementation for various enterprise bean services. Client applications can also use the Java thin client runtime environment to access CORBA objects and CORBA based services.
The Java thin client uses the RMI-IIOP protocol, which enables the client application to access both enterprise bean references and CORBA object references. Using this protocol also allows the client application to use any supported CORBA services. Using the RMI-IIOP protocol along with the accessibility of CORBA services can help you develop a client application that needs to access both enterprise bean references and CORBA object references.
If you choose to use both enterprise beans and CORBA programming models in the same client application, you need to understand the differences between those programming models to manage both environments. For example, the CORBA programming model requires the CORBA CosNaming name service for object resolution in a name space. The enterprise beans programming model requires the JNDI name service. The client application must initialize and properly manage these two naming services.
Another difference applies to the enterprise bean model, for which the JNDI implementation initializes the ORB; the client application is unaware that an ORB is present. The CORBA model, however, requires the client application to explicitly initialize the ORB through the ORB.init() static method.
The CORBA model does not allow for workload management (WLM) functionality and cluster failover. Use the enterprise bean model (with JNDI) to access objects in a clustered environment.
The Java thin application client provides a batch command used to set the CLASSPATH and JAVA_HOME environment variables to enable the Java thin application client run time.
When running in an environment that includes Java thin application clients, clients might suddenly encounter a situation where the port information about the cluster members of the target cluster has become stale. This situation most commonly occurs when all of the cluster members have dynamic ports and are restarted during a time period when no requests are being sent. The client process in this state will eventually attempt to route to the node agent to receive the new port data for the cluster members, and then use that new port data to route back to the members of the cluster.
If any issues occur that prevent the client from communicating with the node agent, or that prevent the new port data being propagated between the cluster members and the node agent, request failures might occur on the client. In some cases, these failures are temporary. In other cases you need to restart one or more processes to resolve a failure.
To circumvent the client routing problems that might arise in these cases, we can configure static ports on the cluster members. With static ports, the port data does not change as a client process gets information about the cluster members. Even if the cluster members are restarted, or there are communication or data propagation issues between processes, the port data the client holds is still valid. This circumvention does not necessarily solve the underlying communication or data propagation issues, but removes the symptoms of unexpected or uneven client routing decisions.
Related
Develop a Java thin client application
Use the Administration Thin Client