Programming Stand-alone Clients
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
A J2EE 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 J2EE clients:
Although a J2EE application client (thin client) is a Java application, it differs from a stand-alone Java application client because it is a J2EE component, hence it offers the advantages of portability to other J2EE-compliant servers, and can access J2EE services.
BEA provides two application client JAR files:
wlclient.jar
) that provides J2EE functionality. See How to Develop a Thin Client.wljmsclient.jar)
, which when deployed with the wlclient.jar
, provides J2EE and WebLogic JMS functionality. See WebLogic JMS Thin Client.Both 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 J2EE APIs, rather than WebLogic Server APIs.
The development process for a thin client application is the same as it is for other J2EE applications. The client can leverage standard J2EE 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.policy==policyfile
. Applets use a different security manager which already allows the downloading of stubs.
The thin client JAR replaces some classes in weblogic.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 weblogic.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 J2EE interface classes, such as javax.ejb
, no other jar files are necessary on the client.
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:
public interface Pinger extends java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
public void pingRemote() throws java.rmi.RemoteException;
public void pingCallback(Pinger toPing) throws java.rmi.RemoteException;
}
interfaceNameImpl
and bind it into the JNDI tree to be made available to clients. 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:
public static void main(String args[]) throws Exception {
if (args.length > 0)
remoteDomain = args[0];
Pinger obj = new PingImpl();
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind(NAME,obj);
System.out.println("PingImpl created and bound to "+ NAME);
}
Note: If you plan on downloading stubs, it is not necessary to run rmic.
$ java weblogic.rmic -iiop nameOfImplementationClass
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()
.
javax.rmi.PortableRemoteObject.narrow()
method.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:
Performing a lookup:
/**
* RMI/IIOP clients should use this narrow function
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* Lookup the EJBs home in the JNDI tree
*/
private TraderHome lookupHome()
throws NamingException
{
// Lookup the beans home using JNDI
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome. Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}
/**
* Using a Properties object will work on JDK130
* and higher clients
*/
private Context getInitialContext() throws NamingException {
try {
// Get an InitialContext
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory
");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
The url
defines the protocol, hostname, and listen port for the WebLogic Server instance and is passed in as a command-line argument.
public static void main(String[] args) throws Exception {
log("\nBeginning statelessSession.Client...\n");
String url = "iiop://localhost:7001";
$ java -Djava.security.manager -Djava.security.policy=java.policy examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001
J2EE 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.
WebLogic Server includes two utilities that facilitate the use of client modules. They are:
You use the weblogic.ClientDeployer utility to extract the client-side JAR file from a J2EE EAR file, creating a deployable JAR file. Execute the weblogic.ClientDeployer class on the Java command line using the following syntax:
java weblogic.ClientDeployer ear-file client1 [client2 client3 ...]
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:
java weblogic.ClientDeployer app.ear myclient
This command extracts myclient.jar from app.ear. As it extracts, the weblogic.ClientDeployer utility performs two other operations.
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.
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:
java weblogic.j2eeclient.Main clientjar URL [application args]
java weblogic.j2eeclient.Main myclient.jar t3://localhost:7001
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.
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 J2EE standard.
Interoperability between WebLogic Server 9.X and WebLogic Server 8.1 thin clients is supported in the following scenarios.
Table 4-1 Thin Client Inter-operability
![]() ![]() |
![]() |
![]() |