
	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

Writing a server-side application

I. Introduction: What is the WebLogic Server?; Writing RMI and EJB classes; Writing servlets; Using Naming
II. Writing server-side classes: Using server-side services on the server
III. Server-to-server authentication with SSL: Configuring a server to require a high-security connection
IV. Change history
Other related documents: Installing WebLogic (non-Windows); Installing WebLogic (Windows); Developers Guides; API Reference Manual; Writing a WebLogic client application; Running and maintaining the WebLogic Server; Setting up and starting the WebLogic Server; Using the WebLogic classes for server-side Java; Glossary

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 of the server. Any application that uses servlets , RMI , or Enterprise JavaBeans will have one or more server-side components.

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.

What is the WebLogic Server?

The WebLogic Server, the core of WebLogic's multitier architecture, is a pure-Java application server that supports a host of services and facilities, all implementations of the standard Java Enterprise APIs, for distributed, networked applications. When you write an application that operates within WebLogic, you use one or more of its services -- like EJB or RMI -- to drive your application. Whether you write a client application or a server plug-in, your code becomes part of WebLogic and inherits the power and efficiency of the WebLogic Server, with its built-in thread management, efficient communications, reliability, and scalability.

WebLogic Servers are scalable; they can operate independently or interdependently in clusters , to create a cooperative computing environment that exists within the network, a concept called client-network computing. Unlike legacy database-based systems, the center of the next-generation enterprise, and where its client applications operate, is the network, not the database; the database is only one of many network resources that a client may access. WebLogic, as a Java application server, operates within the network, serving your business applications and providing the common communications and operational infrastructure that every client-network application needs.

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 Enterprise JavaBeans, WebLogic's implementation of the EJB 1.1 specification, provides a component model for building distributed, transaction-aware applications.
WebLogic Events, pure-Java event handling and notification services, for event-enabling your applications. Any application on the network can send event messages, which are matched up with registrations of interest in particular events, evaluated, and acted upon. Events are lightweight; WebLogic can handle thousands of events per second.
HTTP Servlets, JHTML, and JSP support composition of dynamic pages. The built-in WebLogic HTTP server can serve HTML pages, applets, servlets, and automatic on-the-fly page compilation for JHTML and JSP. The WebLogic web server is completely integrated with all of WebLogic's other services, so your servlet may use Enterprise JavaBeans, JDBC, SSL, and any other WebLogic service.
WebLogic JDBC, a pure-Java implementation of JavaSoft's Java Database Connectivity specification, for database-enabling your applications. WebLogic's pure-Java JDBC implementation allows applet access to databases, since WebLogic JDBC requires no client-side libraries and does not use methods.
WebLogic RMI, WebLogic's pure-Java, efficient and lightweight implementation of JavaSoft's Remote Method Invocation (RMI), for writing distributed applications.

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.

HTTP port-80 access. The WebLogic Server can act as an HTTP server listening on port 80 for serving HTTP servlets. Setting up the WebLogic Server to listen on port 80 means that WebLogic clients can also communicate with the WebLogic Server across a firewall in standard fashion. This gives all WebLogic client applications -- using WebLogic Events, WebLogic JDBC, and/or WebLogic Beans, etc -- port 80 access to WebLogic. The WebLogic Server is designed to serve as a fully-featured webserver for arbitrary file types. In addition, it can proxy to another server.
Allocation of scarce resources. Factory methods and other internal allocation mechanisms allow very fine control over how resources are shared among resource consumers.
Shared objects. Any application that operates within WebLogic has access to objects of other WebLogic applications through named Workspaces. Objects stored in Workspaces can be shared among clients, groups of clients, and the system.
Startup and shutdown classes. You can write classes that are automatically loaded and executed when the WebLogic Server starts up or when it shuts down. With WebLogic RMI, you can register an impl to be created and bound at startup.
Log information. Applications operating within WebLogic have access to a server-wide log file. JDBC applications can elect to write JDBC-related messages to a server-wide JDBC log. Log messages include date/time and severity (I=info, W=warning, E=error) information, as well as the name of the facility that logged the message, and the log entry itself.
Instrumentation and management, through the WebLogic Console, the WebLogic Admin servlets, and other server-wide instrumentation. The Admin servlets allow you to display information about WebLogic Server activity in a browser, including details about Clients, Connections, Events, Threads, as well as other static information about version and licenses. There are other server-wide tools that can be used for debugging and performance analysis.

Writing RMI and EJB classes

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:

BEA WebLogic Server Enterprise Java Beans

Using WebLogic RMI

Writing servlets

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.

Using Naming

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.

Using server-side services on the server

weblogic.common.T3Services

When your object is instantiated on the server, it my access the server-side services that using the static method T3Services.getT3Services(), as shown in this example. The getT3Services() method returns a T3ServicesDef object, which provides factory methods for access to services.

T3ServicesDef t3 =
     T3Services.getT3Services();
  String license = services.admin().licenses();
  String version = services.admin().version();

This shortcut avoids making a JNDI lookup for the T3Services stub.

Server-to-server authentication with SSL

You can use SSL authentication in server-to-server communication, where one server is acting as a client of another. This allows you to depend on high-security connections even in the absence of the more familiar client/server relationship. Appropriate configuration for server-to-server authentication with SSL is detailed in the following section.

There are several differences in how you set up this connection:

You must connect to the destination server on the SSL port.
You must specify the T3S protocol (the WebLogic-specific protocol running over SSL).

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.

  
  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 connection

There 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

Release 4.0: First released clustering.