A Java EE application client runs on a client machine and can provide a richer user interface than can be provided by a markup language. Application clients directly access enterprise beans running in the business tier, and may, as appropriate, communicate via HTTP with servlets running in the Web tier. An application client is typically downloaded from the server, but can be installed on a client machine.
The following sections provide information on developing Java EE clients:
Overview of the Java EE Application Client
A thin client is a computer that runs from resources stored on a central server instead of a localized hard drive. Thin clients work by connecting remotely to a server-based computing environment where most applications, sensitive data, and memory, are stored.
Although a Java EE application client (thin client) is a Java application, it differs from a stand-alone Java application client because it is a Java EE component, hence it offers the advantages of portability to other Java EE-compliant servers, and can access Java EE services.
BEA provides the following application client JAR files:
- A standard client JAR (
wlclient.jar
) that provides Java EE functionality. See How to Develop a Thin Client. - A JMS client JAR (
wljmsclient.jar)
, which when deployed with thewlclient.jar
, provides Java EE and WebLogic JMS functionality. See WebLogic JMS Thin Client. - A JMS SAF client JAR (
wlsafclient.jar)
, which when deployed with thewljmsclient.jar
andwlclient.jar
enables standalone JMS clients to reliably send messages to server-side JMS destinations, even when a destination is temporarily unreachable. Sent messages are stored locally on the client and are forwarded to the destination when it becomes available. See Reliably Sending Messages Using the JMS SAF Client.
These application client JAR files reside in the
WL_HOME/server/lib
subdirectory of the WebLogic Server installation directory.The thin client uses the RMI-IIOP protocol stack and leverages features of J2SE 1.4 It also requires the support of the JDK ORB. The basics of making RMI requests are handled by the JDK, which makes possible a significantly smaller client. Client-side development is performed using standard Java EE APIs, rather than WebLogic Server APIs.
The development process for a thin client application is the same as it is for other Java EE applications. The client can leverage standard Java EE artifacts such as InitialContext, UserTransaction, and EJBs. The WebLogic Server thin client supports these values in the protocol portion of the URL—IIOP, IIOPS, HTTP, HTTPS, T3, and T3S—each of which can be selected by using a different URL in InitialContext. Regardless of the URL, IIOP is used. URLs with T3 or T3S use IIOP and IIOPS respectively. HTTP is tunnelled IIOP, HTTPS is IIOP tunnelled over HTTPS.
Server-side components are deployed in the usual fashion. Client stubs can be generated at either deployment time or runtime.To generate stubs when deploying, run
appc
with the -iiop
and -basicClientJar
options to produce a client jar suitable for use with the thin client. Otherwise, WebLogic Server generates stubs on demand at runtime and serves them to the client. Downloading of stubs by the client requires that a suitable security manager be installed. The thin client provides a default light-weight security manager. For rigorous security requirements, a different security manager can be installed with the command line options -Djava.security.manager -Djava.security.policypolicyfile
. Applets use a different security manager which already allows the downloading of stubs. The thin client JAR replaces some classes in
wlfullclient.jar
. If both the full JAR and the thin client JAR are in the CLASSPATH, the thin client JAR should be first in the path. Note, however, that wlfullclient.jar
is not required to support the thin client. If desired, you can use this syntax to run with an explicit CLASSPATH:java -classpath '<WL_HOME>/lib/wlclient.jar;<CLIENT_CLASSES>' your.app.Main
Note: | wljmsclient.jar has a reference to wlclient.jar so it is only necessary to put one or the other Jar in the client CLASSPATH. Do not put the wljmsclient.jar in the server-side CLASSPATH. |
The thin client jar contains the necessary Java EE interface classes, such as
javax.ejb
, no other jar files are necessary on the client.How to Develop a Thin Client
To develop a thin client:
- Define your remote object’s public methods in an interface that extends
java.rmi.Remote
. - Implement the interface in a class named
interfaceNameImpl
and bind it into the JNDI tree to be made available to clients. - Compile the remote interface and implementation class with a java compiler. Developing these classes in an RMI-IIOP application is no different from doing so in normal RMI. For more information on developing RMI objects, see “Understanding WebLogic RMI”.
- Run the WebLogic RMI or EJB compiler against the implementation class to generate the necessary IIOP stub.
- Make sure that the files you have created—the remote interface, the class that implements it, and the stub—are in the CLASSPATH of WebLogic Server.
- Obtain an initial context.
- Modify the client code to perform the lookup in conjunction with the
javax.rmi.PortableRemoteObject.narrow()
method. - Connect the client to the server over IIOP by running the client with a command such as:
This remote interface may not require much code. All you need are the method signatures for methods you want to implement in remote classes. For example:
This class should implement the remote interface that you wrote, which means that you implement the method signatures that are contained in the interface. All the code generation that will take place is dependent on this class file. Typically, you configure your implementation class as a WebLogic startup class and include a main method that binds the object into the JNDI tree. Here is an excerpt from the implementation class developed from the previous Ping example:
Note: | If you plan on downloading stubs, it is not necessary to run rmic. |
To generate stubs when deploying, run
appc
with the -iiop
and -clientJar
options to produce a client JAR suitable for use with the thin client. Otherwise, WebLogic Server will generate stubs on demand at runtime and serve them to the client.A stub is the client-side proxy for a remote object that forwards each WebLogic RMI call to its matching server-side skeleton, which in turn forwards the call to the actual remote object implementation.
RMI clients access remote objects by creating an initial context and performing a lookup (see next step) on the object. The object is then cast to the appropriate type.
In obtaining an initial context, you must use
weblogic.jndi.WLInitialContextFactory
when defining your JNDI context factory. Use this class when setting the value for the 'Context.INITIAL_CONTEXT_FACTORY
' property that you supply as a parameter to new InitialContext()
.RMI over IIOP RMI clients differ from regular RMI clients in that IIOP is defined as the protocol when obtaining an initial context. Because of this, lookups and casts must be performed in conjunction with the
javax.rmi.PortableRemoteObject.narrow()
method. For example, an RMI client creates an initial context, performs a lookup on the EJBean home, obtains a reference to an EJBean, and calls methods on the EJBean. You must use the
javax.rmi.PortableRemoteObject.narrow()
method in any situation where you would normally cast an object to a specific class type. A CORBA client may return an object that does not implement your remote interface; the narrow method is provided by your ORB to convert the object so that it implements your remote interface. For example, the client code responsible for looking up the EJBean home and casting the result to the Home
object must be modified to use the javax.rmi.PortableRemoteObject.narrow()
as shown below:The
url
defines the protocol, hostname, and listen port for the WebLogic Server instance and is passed in as a command-line argument. Using Java EE Client Application Modules
Java EE specifies a standard for including client application code (a client module) in an EAR file. This allows the client side of an application to be packaged along with the other modules that make up the application.
The client module is declared in the META-INF/application.xml file of the EAR using a <java> tag. See “Enterprise Application Deployment Descriptor Elements” in Developing Applications with WebLogic Server.
Note: | The <java> tag is often confused to be a declaration of Java code that can be used by the server-side modules. This is not its purpose, it is used to declare client-side code that runs outside of the server-side container. |
A client module is basically a JAR file containing a special deployment descriptor named META-INF/application-client.xml. This client JAR file also contains a Main-Class entry in its META-INF/MANIFEST.MF file to specify the entry point for the program. For more information on the application-client.xml file, see Client Application Deployment Descriptor Elements.
Extracting a Client Application
WebLogic Server includes two utilities that facilitate the use of client modules. They are:
- weblogic.ClientDeployer—Extracts the client module from the EAR and prepares it for execution.
- weblogic.j2eeclient.Main—Executes the client code.
You use the weblogic.ClientDeployer utility to extract the client-side JAR file from a Java EE EAR file, creating a deployable JAR file. Execute the weblogic.ClientDeployer class on the Java command line using the following syntax:
The ear-file argument is a Java archive file with an .ear extension or an expanded directory that contains one or more client application JAR files.
The client arguments specify the clients you want to extract. For each client you name, the weblogic.ClientDeployer utility searches for a JAR file within the EAR file that has the specified name containing the .jar extension.
For example, consider the following command:
This command extracts myclient.jar from app.ear. As it extracts, the weblogic.ClientDeployer utility performs two other operations.
- It ensures that the JAR file includes a META-INF/application-client.xml file. If it does not, an exception is thrown.
- It reads from a file named myclient.runtime.xml and creates a
weblogic-application-client.xml
file in the extracted JAR file. This is used by the weblogic.j2eeclient.Main utility to initialize the client application's component environment (java:comp/env). For information on the format of the runtime.xml file, see weblogic-appclient.xml Descriptor Elements.
Note: | You create the <client>.runtime.xml descriptor for the client program to define bindings for entries in the module's META-INF/application-client.xml deployment descriptor. |
Executing a Client Application
Once the client-side JAR file is extracted from the EAR file, use the weblogic.j2eeclient.Main utility to bootstrap the client-side application and point it to a WebLogic Server instance using the following command:
For example:
The weblogic.j2eeclient.Main utility creates a component environment that is accessible from java:comp/env in the client code.
If a resource mentioned by the application-client.xml descriptor is one of the following types, the weblogic.j2eeclient.Main class attempts to bind it from the global JNDI tree on the server to java:comp/env using the information specified earlier in the myclient.runtime.xml file.
- ejb-ref
- javax.jms.QueueConnectionFactory
- javax.jms.TopicConnectionFactory
- javax.mail.Session
- javax.sql.DataSource
The user transaction is bound into java:comp/UserTransaction.
The <res-auth> tag in the application.xml deployment descriptor is currently ignored and should be entered as application. BEA does not currently support form-based authentication.
The rest of the client environment is bound from the
weblogic-application-client.xml
file created by the weblogic.ClientDeployer utility. The weblogic.j2eeclient.Main class emits error messages for missing or incomplete bindings.
Once the environment is initialized, the weblogic.j2eeclient.Main utility searches the JAR manifest of the client JAR for a Main-Class entry. The main method on this class is invoked to start the client program. Any arguments passed to the weblogic.j2eeclient.Main utility after the URL argument is passed on to the client application.
The client JVM must be able to locate the Java classes you create for your application and any Java classes your application depends upon, including WebLogic Server classes. You stage a client application by copying all of the required files on the client into a directory and bundling the directory in a JAR file. The top level of the client application directory can have a batch file or script to start the application. Create a classes/ subdirectory to hold Java classes and JAR files, and add them to the client Class-Path in the startup script.
You may also want to package a Java Runtime Environment (JRE) with a Java client application.
Note: | The use of the Class-Path manifest entries in client module JARs is not portable, as it has not yet been addressed by the Java EE standard. |
Protocol Compatibility
Interoperability between WebLogic Server thin clients is supported in the following scenarios.
From | WebLogic Server 9.x (JDK 1.5) | ||
---|---|---|---|
WebLogic Server 8.1 wlclient.jar (JDK 1.4) | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS |
IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | |
WebLogic Server 9.x wlclient.jar (JDK 1.5) | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS |
IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | |
WebLogic Server 10.0 wlclient.jar (JDK 1.5) | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS |
IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS | IIOP, IIOPS, HTTP, HTTPS |
© BEA Systems |
By Vangie Beal
Related Terms
When implementing a client/server architecture you need to determine if it will be the client or the server that handles the bulk of the workload. By client, we mean the application that runs on a PC or workstation and relies on a server to perform some operations. In last week's Did You Know article we discussed the differences between thick clients (also called fat clients) and thin clients in terms of hardware. The terms thick client and thin client, however, have double meanings, as thick and thin also are used to describe the applications or software. In this article we take a look at the terms thick and thin as related to client application software. A great starting point to discuss the nature of the underlying differences would be to start with an example of thick and thin based on an operating system and the applications. For example, a terminal or Java-based client would be considered a thin client whereas one running Microsoft Windows would be considered a thick client. One major inconsistency when describing thick and thin is that the hardware may be thin — but the applications or software running may be thick. While that doesn't seem to make much sense, if you think of the division between thick vs. thin starting at the operating system level, rather than at the CPU, it's logical. |
Thick vs. Thin Client Applications
A thin client machine is going to communicate with a central processing server, meaning there is little hardware and software installed on the user's machine. At times, thin may be defined as simply not needing the software or operating system installed on the user machine. This allows all end users' systems to be centrally managed and software deployed on a central server location as opposed to installed on each individual system.
Thin clients are really best-suited to environments in which the same information is going to be accessed by the clients, making it a better solution for public environments. For this reason, thin clients are often deployed in hotels and airports, where installing software to all systems wouldn't make sense. It would be a massive headache for IT to both deploy and maintain.
When using thin clients, compared to a feature-rich desktop PCs today, they often tend to look a bit primitive and outdated. Since many thin clients run on very little hardware, it is impossible to incorporate rich graphical user interfaces. To use the client, an input device (keyboard) and viewing device (display) is usually the basic requirements. Some may not even require a mouse.
In contrast, a thick client will provide users with more features, graphics and choices making the applications more customizable. Unlike thin clients, thick clients do not rely on a central processing server because the processing is done locally on the user system, and the server is accessed primarily for storage purposes. For that reason, thick clients often are not well-suited for public environments. To maintain a thick client, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server. Additionally, thick clients often require operating specific applications, again posing more work and limitations for deployment. The trade-off is a more robust and local computing environment.
Looking Towards Smart Clients
Over the past few years, has started to move towards smart clients, also called rich clients. The trend is a move from traditional client/server architecture to a Web-based model. More similar to a fat client vs. a thin client, smart clients are Internet-connected devices that allows a user's local applications to interact with server-based applications through the use of Web services.
For example, a smart client running a word processing application can interface with a remote database over the Internet in order to collect data from the database to be used in the word processing document.
Smart clients support work offline. That is, they can work with data even when they are not connected to the Internet (which distinguishes them from browser-based applications, which do not work when the device is not connected to the Internet). Smart client applications have the capability to be deployed and updated in real time over the network from a centralized server, they support multiple platforms and languages because they are built on Web services, and can run on almost any device that has Internet connectivity, including desktops, workstations, notebooks, tablet PCs, PDAs, and mobile phones. Smart clients will offer rich GUIs, and overall development and maintenance costs are higher than, for example, thin clients.
For example, a smart client running a word processing application can interface with a remote database over the Internet in order to collect data from the database to be used in the word processing document.
Smart clients support work offline. That is, they can work with data even when they are not connected to the Internet (which distinguishes them from browser-based applications, which do not work when the device is not connected to the Internet). Smart client applications have the capability to be deployed and updated in real time over the network from a centralized server, they support multiple platforms and languages because they are built on Web services, and can run on almost any device that has Internet connectivity, including desktops, workstations, notebooks, tablet PCs, PDAs, and mobile phones. Smart clients will offer rich GUIs, and overall development and maintenance costs are higher than, for example, thin clients.
On the downside, smart clients require users to install or deploy a runtime a library — routines that are bound to the program during execution. For example, if the client is Windows-, Java- or Flash-based, you need to have that runtime on the user machine. Smart clients are most often contrasted with Web browser clients (or browser-based applications).
Be sure to check our previous discussion on Thick and Thin in terms of hardware.
Did You Know...
According to a 2004 Jupiter Research report, 73 percent of corporations surveyed reported that they had migrated at least one enterprise application from a client-server model to a Web-based model.
According to a 2004 Jupiter Research report, 73 percent of corporations surveyed reported that they had migrated at least one enterprise application from a client-server model to a Web-based model.
Key Terms To Understanding Storage Servers: client The client part of a client-server architecture. Typically, a client is an application that runs on a personal computer or workstation and relies on a server to perform some operations. server A computer or device on a network that manages network resources. Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. client/server architecture A network architecture in which each computer or process on the network is either a client or a server. |
Based in Nova Scotia, Vangie Beal is has been writing about technology for more than a decade. She is a frequent contributor to EcommerceGuide and managing editor at Webopedia. You can tweet her online @AuroraGG.
![Thin Client Application Thin Client Application](/uploads/1/2/4/8/124868639/171663471.bmp)
![Client Client](/uploads/1/2/4/8/124868639/508571266.jpg)
IT Solutions BuilderTOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD
Thin-client Applications Are Developed Using
Related Links
WEBOPEDIA NEWS
Stay up to date on the latest developments in Internet terminology with a free newsletter from Webopedia. Join to subscribe now.
Texting & Chat AbbreviationsFrom A3 to ZZZ this guide lists 1,500 text message and online chat abbreviations to help you translate and understand today's texting lingo. Read More »
List of Well-Known TCP Port NumbersPort numbers 0 to 1024 are reserved for privileged services and designated as well-known ports. This list of port numbers are specified in... Read More »
Thin Client Application Death
Computer Architecture Study GuideComputer architecture provides an introduction to system design basics for most computer science students. Read More »
Network Fundamentals Study GuideNetworking fundamentals teaches the building blocks of modern network design. Learn different types of networks, concepts, architecture and... Read More »
The Five Generations of ComputersLearn about each of the five generations of computers and major technology developments that have led to the computing devices that we use... Read More »