Writing a server-side application
I. IntroductionBuilding 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.
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 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. Using server-side services on the serverWhen 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 = t3.services.admin().licenses(); String version = t3.services.admin().version();This shortcut avoids making a JNDI lookup for the T3Services stub. Server-to-server authentication with SSLYou 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:
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.
|