|
|
|
Writing a server-side application
I. Introduction
Building applications within a distributed architecture means that
your client application may depend upon remote objects that are
instantiated and run within the VM An object running within the server VM has a set of use parameters that are quite different from an object running within a client VM. Access to server-side services may look transparent to the user but the underlying machinery for that access differs, depending on whether the service is operating within the server VM. There are naming and security issues as well, that vary depending on the context of the instantiated object.
This document covers details common to all server-side execution.
You should read the companion developers guides for the particular
service for more service-specific details.
The WebLogic Server, the core of WebLogic's multitier
WebLogic Servers are scalable; they can operate independently or
interdependently in clusters Unlike highly structured programming environments, WebLogic is a lightweight, very efficient set of pure-Java modules for enabling your Java applications for certain tasks. It sits beneath your application; you can use whatever WebLogic components make sense for your business application. All of your WebLogic applications, no matter what module(s) they use, inherit access to all of the WebLogic Server's facilities, and as these facilities are upgraded and enhanced, all of your WebLogic applications benefit. Server-side services and facilities offered within WebLogic include: WebLogic server-side services. WebLogic has plug-and-play components that offer several server-side services:
WebLogic Server facilities. One of the most important characteristics of WebLogic is that its server facilities are accessible to all of the applications that use the WebLogic Server.
The most popular server-side objects for distributed applications are Enterprise JavaBeans, for which WebLogic has the most advanced support in the industry, and RMI objects for remoted client use. You can read up on WebLogic EJB and RMI in our Developers Guides: WebLogic fully supports JavaSoft HTTP servlets, which you can write to provide web-browser based applications over the internet or your intranet. Thin-client, browser-based applications are highly accessible, and avoid the need for software distribution and installation -- the only client software required is a web-browser. For more information about writing servlets, read the Developers Guides, Using WebLogic HTTP Servlets The WebLogic Server also supports server-side scripting with JHTML and JavaServer Pages, allowing you to embed your servlet logic within an HTML page. WebLogic offers naming and directory services through its implementation of the JavaSoft Java Naming and Directory Interface (JNDI). Naming gives you a way to locate and use objects of which your program may not know the exact physical location, particularly in a clustered environment. JNDI provides a lookup model that supports security and other cluster-related functionality, through WebLogic's replicated cluster-wide JNDI tree. For more information about WebLogic JNDI, check the Developers Guide, Using WebLogic JNDI. Access to server-side servicesIn a T3Client application, WebLogic services are accessed by calling factory methods on the T3Client object. Creating a T3Client and calling its getT3Services() method returns a T3ServicesDef object on which you can call factory methods for access to WebLogic services. Here is a short example of how you get access to services from within a client; there are more details in the Developers Guide, Writing a T3Client application. T3Client t3 = new T3Client(URL); t3.connect(); String license = t3.services.admin().licenses(); String version = t3.services.admin().version(); When your object isn't instantiated on the T3Client, however, but on the server, there is a parallel mechanism for getting access to services that uses the static method T3Services.getT3Services(), as shown in this example. Like the T3Client.getT3Services() method, the getT3Services() method returns a T3ServicesDef object on which you can call factory methods for service access. T3ServicesDef t3 =
T3Services.getT3Services();
String license = t3.services.admin().licenses();
String version = t3.services.admin().version();
There is a second method in the T3Services class that you can use for access to WebLogic services from within an applet. Like the method above, it returns a T3ServicesDef object: T3ServicesDef t3 =
T3Services.getServerServices();
Note that you never call the connect() method on the object returned by a call to T3Services.getT3Services(). Since of course you are operating within the server VM, there is no need to connect.
Startup classes are automatically loaded and executed when the WebLogic Server starts up. With version 3.1.2, startup classes are loaded last, after all other initialization is complete. You write a startup class by implementing weblogic.common.T3StartupDef. The startup classes you write perform functions that need to run once at startup time, to prepare the WebLogic Server environment for some subsequent work. For example, you can use a startup class to perform a JDBC query and save a DataSet into a workspace for subsequent T3Client access. Startup classes can do such things as register interest in an event, retrieve a DataSet, or execute a WebLogic T3Servlet. Writing startup classes
You write a startup class by implementing the interface weblogic.common.T3StartupDef and
writing a startup()
method. (Note that any class that implements T3StartupDef must have a
public default constructor.) A startup class that implements this
interface and has been registered in the WebLogic Server's weblogic.properties file is
automatically launched when the WebLogic Server starts up, and its
startup method is called. Startup classes are invoked
immediately before the WebLogic Server begins listening on its
TCP
Here is an example of how to write a startup class. This particular
startup class makes a connection to a database, retrieves a dbKona The startup method takes two arguments, a String "name" and a Hashtable. The "name" argument passed to this method is the virtualName by which you registered the startup, and the argument Hashtable passed to this method is made up of the name-value pairs that you provide in the registration for startupArgs. The registration for this class is shown in the next section on registering startup classes. To implement a startup class: First, write the startup() method, which takes two arguments:
Call the Hashtable.get() method to retrieve the arguments passed to the startup method. In this example, the arguments are the parameters necessary to make the connection to the database. After retrieving the arguments from the Hashtable, we complete the JDBC connection to the database and execute the query. The results are fetched into a dbKona QueryDataSet. public String startup(String name, Hashtable args)
throws Exception
{
String query = (String)args.get("query");
String user = (String)args.get("user");
String password = (String)args.get("password");
String server = (String)args.get("server");
Class.forName("weblogic.jdbc.oci.Driver");
java.sql.Connection conn =
java.sql.DriverManager.getConnection(server, user, password);
weblogic.db.jdbc.QueryDataSet qds =
new weblogic.db.jdbc.QueryDataSet(conn, query);
qds.fetchRecords();
(. . . continued below)
We use the first argument for this method -- the virtual "name" for the startup class that was registered in the weblogic.properties file -- as well as the query and the QueryDataSet itself, to construct a ParamSet that can be stored in a workspace on the WebLogic Server. Then we close the QueryDataSet and the connection. (. . . continued from above)
ParamSet ps = new ParamSet();
ps.setParam("name", name);
ps.setParam("query", query);
ps.setParam("dataset", qds);
services.workspace().store(name, ps,
WorkspaceServicesDef.SCOPE_SYSTEM);
qds.close();
conn.close();
return name + " started";
}
The string that is returned when this method is called (in this case "doquery started") is written to the WebLogic Server's log file. The other methods that you write in this class depend on what you want to accomplish. In the case of the example, we implement the T3Servlet interface that allows a T3Client to fetch the QueryDataSet from its storage on the WebLogic Server. Writing a T3Servlet is described in detail in Using WebLogic T3Servlets. The complete code for this startup class is found in the examples included in the distribution, in examples/t3client/StartupQuery.java. Registering startup classesA user-written startup class must be registered in the weblogic.properties file, in a manner similar to registering a servlet. It follows the pattern: weblogic.system.startupClass.virtualName=classnameThe arguments for this class are registered as: weblogic.system.startupArgs.virtualName=args For example, the startup class used as an example above and provided in the tutorial/t3client as part of the distribution is registered as: weblogic.system.startupClass.doquery=tutorial.t3client.StartupQuery weblogic.system.startupArgs.doquery=SQL="select * from emp"You can register more than one startup class in the WebLogic Server's weblogic.properties file. Here is an example of how to register three startup classes. They will be started in arbitrary, undetermined order: weblogic.system.startupClass.a=class1 weblogic.system.startupClass.b=class2 weblogic.system.startupClass.c=class3You can also register the classes in a way that insures the order in which classes are started up, by registering multiple classes in a comma-delimited list on the same line. In this case, you are guaranteed that the classes will be started in order from left to right. Here is how to register three classes so that class1 is started first, then class2, followed by class3: weblogic.system.startupClass.a=class1,class2,class3Note that there should be no spaces in the line.
Shutdown classes work the same way as start up classes. Shutdown operations are automatically loaded and executed when the WebLogic Server is shutdown with the weblogic.T3Admin shutdown command. You write a shutdown class by implementing the interface weblogic.common.T3ShutdownDef. Shutdown functions might include such things as writing a message to the log file or cleaning up resources. After you implement the interface, you must register the shutdown class itself in the weblogic.properties file, by setting the property weblogic.system.shutdownClass.virtual_name=classname. Initialization arguments for the class are registered as weblogic.system.shudownArgs.virtual_name=args. Registering a shutdown class is similar to registering any servlet. For an example shutdown class, see the ShutdownTest.java example in the tutorial/t3client directory included in the distribution.
Server-to-server authentication with SSL
You can use SSL authentication There are several differences in how you set up this connection:
Here is a code example to establish a highly secure connection to a WebLogic Server "server2.weblogic.com" listening for SSL login requests on port 443: Environment env = new Environment();
env.setProviderURL("t3s://server2.weblogic.com:443");
The next line enables the server's own certificate to be used for SSL client authentication to the destination server. env.setSSLClientCertificateFromServer(); Setting the SSL server name and the root CA fingerprints protects against a man-in-the-middle attack by specifying that the server certificate must be for a specific server (in this case, "server2.weblogic.com") and that the certificate must be issued by a certificate authority with a specific fingerprint. Use the setSSLServerName() and setSSLRootCAFingerprints() methods to do so, as shown here: env.setSSLServerName("server2.weblogic.com");
env.setSSLRootCAFingerprints("ac45e2dlce492252acc27ee5c345ef26");
Finally, create a client and connect, then set the initial context factory and get a context to continue the session's work. T3Client t3 = env.createProviderClient();
t3.connect();
env.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
Context ctx = new InitialContext(env.getProperties());
For more information on SSL and authentication, see the Developers Guide, Using WebLogic SSL. Configuring a server to require a high-security connectionThere are some configuration details to setting up WebLogic for a high-security connection. You configure WebLogic by setting properties in the appropriate weblogic.properties file. First, you should use WebLogic with a firewall that allows access only through the port at which WebLogic is listening for SSL login requests. To configure this, set the properties weblogic.ssl.enable to true (required to use SSL) and weblogic.system.SSLListenPort to the number of the SSL listen port. You must also configure a certificate authority for SSL clients by setting the configuration property weblogic.security.clientRootCA. The property names a file that resides in the myserver/ (or mycluster/) directory that must contain an X.509 certificate. Setting this property causes WebLogic's SSL to request client authentication from an issuer named in that certificate. The fingerprint of that certificate is stored so that it can be checked again later. Finally, set the configuration property weblogic.security.enforceClientCert to true. This causes WebLogic to reject SSL connections that fail client authentication, either because the requested client certificate was not furnished, or because the client certificate was not issued by the client root certificate authority.
Change history
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|
