Configurar Componentes Web en un Servidor WebLogic
Introducción
Además de su habilidad para hospedar dinámicamente aplicaciones distribuidas basadas en Java, WebLogic Server también es un Servidor Web totalmente funcional que puede manejar sites Web de alto volumen, servir ficheros estáticos como ficheros HTML, y ficheros de imágenes igual que servlets y JavaServer Pages (JSP). WebLogic Server soporta el estándar HTTP 1.1.
Parámetros HTTP
Podemos configurar los siguientes parámetros de operación HTTP usando la Consola de Administración para cada ejemplar de WebLogic Server (o por cada host virtual):
- Aplicación Web por Defecto
La aplicación Web por defecto intenta responder a las peticiones que no sean respondibles por cualquier otra Aplicación Web desplegada. A los recursos de la Aplicación Web se accede con una URI que no incluye el path de contexto (el path de contexto de una aplicación Web normalmente es el nombre de la aplicación Web).
- Post Timeout Seconds
El tiempo (en segundos) que WebLogic Server espera entre bloques de datos enviados usando el método HTTP POST. Usado para envitar ataques de denegación-de-servicio que intentan sobrecargar el seridor usando el método POST.
- Max Post Time
Límite de la cantidad total de tiempo que el WebLogic Server gasta en recibir datos POST.
- Max Post Size
Límita el número de bytes de datos recibidos en un POST desde una sola petición. Si se sobrepasa este límite, se lanzará una excepción MaxPostSizeExceeded.
- Enable Keep Alive
Activa o desactiva las conexiones HTTP persistentes. Si el navegador usa HTTP 1.1, siempre se usa keep alive.
- Connection timeout
El número de segundos que espera WebLogic Server antes de cerrar una conexión HTTP inactiva.
- HTTPS Duration
El número de segundos que espera WebLogic Server antes de cerrar una conexión HTTPs (Secure Socket Layer o SSL) inactiva.
- HTTP Access Logging
Podemos activar o desactiva la generación de log de accesos HTTP. También podemos configurar los parámetros de cómo y cuándo se rota el fichero de logs de acceso. Para más información puedes ver Configurar los Logs de Acceso HTTP.
Configurar el Puerto de Escucha
Podemos especificar el puerto en el que escucha cada Servidor WebLogic las peticiones HTTP. Aunque podemos especificar cualquier número de puerto válido, si especificamos el puerto 80, podremos omitir el número de puerto en nuestras peticiones HTTP usadas para acceder a los recursos de nuestra aplicación Web. Por ejemplo, si definimos el puerto 80 como el puerto de escucha, podemos usar la forma http://hostname/myfile.html en lugar de http://hostname:portnumber/myfile.html.
Definimos un puerto de escucha diferente para las peticiones normales y seguras (usando SSL). Podemos definir el puerto de escucha regular sobre el nodo Servers en la Consola de Administración, bajo el pestaña Configuration/General, y podemos definir los puertos SSL bajo la pestaña Configuration/SSL.
Aplicaciones Web
HTTP y los servicios Web se despliegan de acuerdo a la especificación Servlet 2.2 de Sun Microsystems, que describe el uso de aplicaciones Web como una forma estandarizada de agrupar componentes de una aplicación basada en Web. Estos componentes incluyen páginas JSP, servlets HTTP, y recursos estáticos como páginas HTML o ficheros de imágenes. Cada servidor puede hospedar cualquier número de aplicaciones Web, Normalmente usamos el nombre de la Aplicación Web como parte del URI que usamos para solicitar los recursos de la aplicación Web.
Para más información, puedes ver Desplegar y Configurar Aplicaciones Web.
Las Aplicaciones Web y el Clustering
Las Aplicaciones Web se pueden desplegar en un cluster de Servidores WebLogic. Cuando un usuario solicita un recurso de una aplicación Web, la solicitud es enrutada a uno de los servidores del cluster que hospeda la aplicación. Si una aplicación usa un objeto de sesión, la sesión debe ser replicada en todos los nodos del cluster. Se proprocionan varios métodos para replicar sesiones.
Designar una Aplicación Web por Defecto
Cada servidor y host virtual de nuestro dominio tiene un tipo especial de aplicación Web, llamado "Aplicación Web por Defecto". Esta aplicación Web responde a cualquier solicitud HTTP que no pueda resolver cualquier otra aplicación Web. En contraste a todas las aplicaciones Web, la aplicación Web por defecto no usa el nombre de la aplicación Web como parte del URI. Cualquier aplicación Web destinada a un servidor o host virtual pueden ser declaradas como aplicación Web por defecto. (Destinar una aplicación Web se discute más adelante en esta página. Para más información sobre host virtual, puedes ver Configurar Host Virtuales.
Si no declaramos una aplicación Web por defecto, el Servidor WebLogic crea una por cada servidor o host virtual cuando lo arrancamos. La aplicación Web por defecto se llama DefaultWebApp_servername, donde servername es el nombre del servidor que hemos arrancado, o en el caso de un servidor virtual, DefaultWebApp_virtualHostName.
Si declaramos una aplicación Web que falla al desplegarse correctamente, se lanzará un error y el usuario recibirá un mensaje de error HTTP 400.
Por ejemplo, si nuestra aplicación Web se llama shopping, usaríamos la siguiente URI para acceder a un JSP llamado cart.jsp de la aplicación Web:
http://host:port/shopping/cart.jsp
Sin embargo, si declararamos shopping como la aplicación Web por defecto, accederíamos a cart.jsp con la siguiente URI:
http://host:port/cart.jsp
(donde host es el nombre de host de la máquina que está ejecutando WebLogic Server y port es el número de puerto donde el servidor WebLogic está escuchando peticiones).
Para designar una aplicación Web por defecto para un servidor o host virtual, usamos la Consola de Administración:
- En el panel izquierdo, en el nodo Web Application.
- Seleccionamos nuestra aplicación Web.
- En el panel derecho, puslamos la pestaña Targets.
- Seleccionamos la pestaña Servers y movemos el servidor (o host virtual) a la colunmna Chosen. (También podemos dirigir todos los servidores de un cluster seleccionando la etiqueta Clusters y mover el cluster a la columna Chosen.)
- Pulsamos Apply.
- Pulsamos el nodo Servers (o host virtual) en el panel izquierdo.
- Seleccionamos el servidor o host virtual apropiado.
- En el panel derecho, pulsamos la pestaña General.
- Seleccionamos la pestaña HTTP.
- Seleccionamos una aplicación Web de la lista desplegable etiquetada Default Web Application.
- Pulsamos Apply.
- Si estamos declarando una aplicación Web por defecto para uno o más servidores controlados, repetimos estos pasos por cada servidor controlado.
Configurar el Hosting Virtual
El Hosting virtual nos permite definir nombres de host a los que responden servidores o clusters. Cuando usamos hosting virtual usamos DNS para especificar uno o más nombres de host a los que mapean a direcciones IP de un servidor WebLogic o un cluster y especificamos que aplicaciones Web son servidas por el host virtual. Cuando se usa en un cluster, el balance de carga nos permite un uso más eficiente de nuestro hardware, incluso si uno de los nombres de hosts DNS procesa más solicitudes que otros.
Por ejemplo, podemos espeficar que una aplicación Web llamada books responde a las peticiones para el nombre del host virtual www.books.com., y que éstas solicitudes son dirigidas a los servidores WebLogic A,B y C, mientras que una aplicación Web llamada cars responde al nombre de host virtual www.autos.com y estas solicitudes son dirigidas a los servidores WebLogic D y E. Podemos configurar una gran variedad de combinaciones de host virtuales, Servidores WebLogic, clusters y aplicaciones Web, dependiendo de los requerimientos de nuestra aplicación y servidor Web.
Por cada host virtual que definimos también podemos definir separadamente parámetros HTTP y logs de acceso HTTP. Los parámetros HTTP y logs de acceso a un host virutual sobreescriben los del servidor. Podriamos especificar cualquier número de host virtuales. Podemos activar el hosting virtual dirigiendo el host virtual a un servidor o un cluster de servidores. Un host virtual dirigido a un cluster será aplicado a todos los servidores del cluster.
Hosting Virtual y la Aplicación Web por Defecto
También podemos designar una aplicación Web por Defecto para cada host virtual. La aplicación Web por defecto para un host virtual responde a todas las peticiones que no pueden resolver las otras aplicaciones desplegadas en el mismo servidor o cluster del servidor virtual. Al contrario que otras aplicaciones Web, una aplicación Web por defecto no usa el nombre de la aplicación Web (también llamado path de contexto) como parte del URI usado para acceder a los recursos de la aplicación web por defecto.
Por ejemplo, si definimos un host virtual llamado www.mystore.com y lo dirigimos a un servidor en el que tenemos desplegada una aplicación Web llamada shopping. Accederiamos a un JSP llamado cart.jsp desde la aplicación Web shopping con la siguinete URI:
http://www.mystore.com/shopping/cart.jsp
Sin embargo, si declaramos shopping como la aplicación Web por defecto del host virtual www.mystore.com, accederíamos a cart.jsp con la siguiente URI:
http://www.mystore.com/cart.jsp
Para más información, puedes ver Cómo Resuelve un Servidor WebLogic las peticiones HTTP.
Configurar un Host Virtual
Para definir un host virtual, usamos la consola de administración:
- Crear un nuevo host virtual.
- Pulsamos sobre Services en el panel izquierdo. El nodo se expande y muestra una lista de servicios.
- Pulsamos sobre el nodo virtual hosts. Si hay definido algún host virtual, el nodo se expandirá y mostrará una lista de host virutales.
- Pulsamos sobre Create a New Virtual Host en el panel derecho.
- Introducimos un nombre para representar este host virutal.
- Introducimos los nombres de los host virtuales, uno por líenea. Sólo las peticiones correspondientes a uno de estos nombres de host virtuales serán manejadas por el Servidor o Cluster WebLogic dirigido por este host virtual.
- (opcional) Asignamos una aplicación Web por defecto para este virtual.
- Pulsamos Create.
- Defininos los parámetros de loggin y HTTP:
- (opcional) Pulsamos sobre la pestaña Logging y rellanamos los atributos de HTTP access log.
- Seleccionamos la pestaña HTTP y rellenamos los parámetros HTTP.
- Definir los servidores que responderán a este host virtual.
- Seleccionamos la pestaña Targets.
- Seleccionamos la pestaña Servers. Veremos una lista de servidores disponibles.
- Seleccionamos un servidor en la columna available y usamos el botón de la flecha derecha para moverlo a la columna chosen.
- Definir el cluster que responderá a este host virtual (opcional). Previamente debemos haber definido un Cluster WebLogic.
- Seleccionamos la pestaña Targets.
- Seleccionamos la pestaña Clusters. Veremos una lista de servidores disponibles.
- Seleccionamos un cluster en la columna available y usamos el botón de la flecha derecha para mover el cluster a la columna Chosen. El host virtual es dirigido a todos los servidores del cluster.
- Dirigir aplicaciones Web al host virtual.
- Pulsamos sobre el nodo Web Applications en el panel izquierdo.
- Seleccionamos la aplicación Web que queremos dirigir.
- Seleccionamos la pestaña Targets en el panel derecho.
- Seleccionamos la pestaña Virtual Hosts.
- Seleccionamos un host virtual en la columna available y usamos el botón de la flecha derecha para moverlo a la columna chosen.
Configurar Logs de Acceeso HTTP
WebLogic Server puede mantener un log de todas las transaciones HTTP en un fichero de texto, en el formato de log normal o en el formato de log extendido. El fomato de log extendido nos permita personalizar la siguiente convención estándar. Podemos configurar los atributos que definen el comportamiento de los logs de acceso HTTP por cada servidor o por cada host virtual que definimos.
Rotación de Log
También podemos elegir la rotación del fichero de log basándonos en el tamaño del fichero o en el tiempo. Cuando se cumplen uno de estos criterios, el fichero de log de accesos actual se cierra y se crea un nuevo fichero. Si no configuramos la rotación, el fichero de logs de accesos logs HTTP crecerá indefinidamente. El nombre de este fichero incluye una parte numérica que se incrementa en cada rotación. Se mantienen ficheros de logs de Accesos HTTP separados para cada Servidor Web que hemos definido.
Configurar el Log de Accesos HTTP Usando la Consola de Administración
Para configurar el log de accesos HTTP usamos la Consola de Administración:
- Si tenemos configurado hosting virtual:
- Seleccionamos el nodo services en el panel izquierdo.
- Seleccionamos el nodo virtual hosts. El nodo se expande y muestra una lista de host virtuales.
- Seleccionamos un host virtual.
Si no tenemos configurado el hosting virtual:
- Seleccionamos el nodo servers en el panel izquierdo. El nodo se expande y muestra una lista de servidores.
- Seleccionamos un servidor.
- Seleccionamos la pestaña Logging.
- Seleccionamos la pestaña HTTP.
- Activamos la caja Enable Logging.
- Introducimos los valores para nuestro Log File Name.
- Seleccionamos Common o Extended de la lista desplegable etiquetada Format.
- Seleccionamos el tipo de rotación a By Size o By Date.
- By Size: Rota el fichero log cuando su tamaño excede el valor introducido en el parámetro Log Buffer Size.
- By Date: Rota el fichero de Log después del número de minutos especificado en el parámetro Rotation Period.
- Si hemos seleccionado Size como el tipo de rotación, seelccionamos el valor del buffer al valor máximo debytes que queremos tener en el fichero.
- Configuramos el parámetro Flush Every con el número de segundos después de los cuales el log de acceso escribe entradas de log.
- Si hemos seleccionado Date como el tipo de rotación, seleccionamos el tiempo de rotación a la primera fecha en que queramos que se rote el fichero Log. (Efectivamente sólo si el tipo de rotación se configura como Date). Introducimos la fecha usando el formato de java.text.SimpleDateFormat, MM-dd-yyyy-k:mm:ss.
- Si hemos seleccionado Date como el tipo de rotación, configuramos el periodo de rotación con el número de minutos después del que se rotará el fichero Log.
Formato de Log Común
El formato de log por defecto para la información HTTP es el formato común de http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-format. Este estándar sigue este patrón:
host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes
donde:
- host
Es el nombre DNS o el número IP del cliente remoto.
- RFC931
Cualquier información devuelta por IDENTD para el cliente remoto; WebLogic Server no soporta identificación de usuario.
- auth_user
Si el usuario del cliente remoto usa un userid para autentificación, el nombre de usuario; de otro modo “-”.
- day/month/year:hour:minute:second UTC_offset
Día, mes año y hora de día (en formato de 24 horas) con la diferencia horaria entre la hora local y GMT, encerrado entre corchetes.
- "request"
Primera línea de la petición HTTP enviada por el cliente remoto encerrada en dobles comillas.
- status
- Código de estado HTTP devuelto por el servidor, si está disponible; de otro modo “-”.
- bytes
Número de bytes listados como content-length en la cabecera HTTP, sin incluir la cabecera HTTP, si se conoce; sino “-”.
Configurar el Log de Accesos HTTP usando el Formato Extendido
WebLogic Server también soporta un formato de fichero extendido, versión 1.0, según se define en la W3C. Este es un estándar emergente, y WebLogic Server sigue el borrador de la especificación de W3C en www.w3.org/TR/WD-logfile.html. La referencia definitiva puede encontrarse en la página www.w3.org/pub/WWW/TR.
El formato de fichero de log extendido nos permite especificar el tipo y orden de la información grabada sobre cada comunicación HTTP. Para activar el formato de información extendida, configuramos el atributo Format en la pestaña HTTP en la Consola de Administración como Extended. (Puedes ver el paso 4 en: Configurar el Log de Accesos HTTP Usando la Consola de Administración).
Podemos especificar qué información se debería grabar en el fichero Log con directivas, incluidas en el propio fichero log. Una directiva empieza una nueva línea y comienza con un signo #. Si el fichero log no existe, se crea uno nuevo con las directivas por defecto. Sin embargo, si el fichero de log ya existe cuando se arranca el servidor, debe contener directivas legales al principio del fichero.
Crear Directivas Fields
La primera línea de nuestro fichero log debe contener una directiva con el número de versión del formato del fichero. También debe contener una directiva Fields cerca del principio del fichero:
#Version: 1.0
#Fields: xxxx xxxx xxxx ...
donde cada xxxx describe los campos de datos a grabar. Los tipos de campos se especifian como simples identificadores, o pueden tomar un formato prefijo de identificador, según se define en la especificación W3C. Aquí tenemos un ejemplo:
#Fields: date time cs-method cs-uri
Este identificador instruye al servidor a grabar la fecha y la hora de la transación, el método de solicitud que usó el cliente, y la URI de la solicitud por cada acceso HTTP. Cada campo está separado por un espacio en blanco, y cada registro se añade en una nueva línea en el fichero log.
Nota:
La directiva #Fields debe ser seguida por una nueva línea en el fichero log, para que el primer mensaje de log no se añada en la misma línea.
|
Identificadores de Campos Soportados
Los siguienes identificadores no requieren prefijo:
- date
La fecha en la que se completó la transación, el campo tiene el tipo <date>, según define la especificación W3C.
- time
La hora en la que se completó la transación, el campo tiene el tipo <time>, según define la especificación W3C.
- time-taken
El tiempo que tardó en completarse la transación, en segundos, el campo tien el tipo <fixed>, según define la especificación W3C. La fecha en la que se completó la transación, el campo tiene el tipo <date>, según define la especificación W3C.
- bytes
El número de bytes transferidos, tiene el tipo <integer>.
Observa que el campo cached definido en la especificación W3C no está soportado en WebLogic Server.
Los siguientes identificadores requieren prefijos, y no pueden usarse sólos. Las combinaciones de prefijos soportadas se explican individualmente.
- Campos relacionados con la dirección IP:
Estos campos dan la dirección IP y el puerto del cliente o del servidor que responde. Este campo tiene el tipo <address>, según lo define la especifiación W3C. Los prefijos soportados son:
- c-ip
La dirección IP del cliente.
- s-ip
La dirección IP del servidor
- Campos relacionados con el DNS.
Estos campos ofrecen el nombre de dominio del cliente o del servidor. Este campo tiene el tipo <name>, según lo define la especificación W3C. Los prefijos soportados son:
- c-dns
El nombre de dominio del cliente.
- s-dns
El nombre de domino del servidor solicitado.
- sc-status
El código de estado de la respuesta, por ejemplo (404) indicando un estado “File not found”. El tipo del campo es <integer>, según lo define la especificación W3C.
- sc-comment
El comentario devuelto con el código de estado, por ejemplo “File not found”. Este campo tiene el tipo <text>.
- cs-method
El método de solicitud, por ejemplo GET o POST. Este campo tiene el tipo <name>, según define la especificación W3C.
- cs-uri
La URI solicitada completa. Este campo tiene el tipo <uri>, según lo define la especificación W3C.
- cs-uri-stem
Sólo la primera parte de la URI (omitiendo la query). Este campo tiene el tipo <uri>, según lo define la especificación W3C.
- cs-uri-query
Sólo la porción query de la URI. Este campo tiene el tipo <uri>, según lo define la especificación W3C.
Crear Identificadores de Campos Personalizados
También podemos crear campos definidos por el usuario para incluirlos en un fichero de log de accesos HTTP que use el formato extendido. Para crear un campo personalizado identificamos el campo en el fichero de log ELF usando la directiva Fields y luego creamos una clase Java que genere la salida deseada. Podemos crear una clase separada para cada campo, o la clase Java puede sacar varios campos. Puedes encontrar un ejemplo de clase Java en Clase Java para Crear un Campo ELF Personalizado.
Para crear un campo personalizado:
- Incluimos el nombre de campo en la directiva Fields, usando la forma:
X-myCustomField.
Donde myCustomField es el nombre totalmente cualificado de la clase.
- Creamos una clase Java con el mismo nombre totalmente cualificado de la clase y personalizamos el campo que hemos definido en la directiva Fields (por ejemplo, myCustomField). Esta clase define la información que queremos almacenar en nuestro campo personalizado. La clase Java debe implementar el siguiente interface:
weblogic.servlet.logging.CustomELFLogger
En nuestra clase Java, debemos implementar el método logField(), que toma un objeto HttpAccountingInfo y un objeto FormatStringBuffer como sus argumentos:
- Usamos el objeto HttpAccountingInfo para acceder a los datos de la solicitud y respuesta HTTP que queremos mostrar en el campo personalizado. Los métodos Getter se proporcionan para acceder a esta información.
- Usamos la clase FormatStringBuffer para crear los contenidos de nuestro campo personalizado. Los métodos se proporcionan para crear salidas adecuadas.
- Compilamos la clase Java y añadimos la clase a la sentencia CLASSPATH usada para arrancar WebLogic Server. Probablemente necesitaremos modificar las sentencias CLASSPATH en los scripts que usamos para arrancar WebLogic Server.
Nota:
No debemos situar esta clase dentro de una aplicación Web o Enterprise en formato expandido o jar.
|
- Configuramos WebLogic Server para usar el formato de log extendido.
Nota:
Cuando escribamos la clase Java que define nuestro campo pesonalizado, no deberíamos ejecutar ningún código que pueda relentizar el sistema (por ejemplo, acceder a bases de datos o ejecutar I/O importantes o llamadas a red). Recuerda que se guarda una entrada en el fichero log de accesos HTTP por cada petición HTTP.
|
Nota:
Si queremos sacar más de un campo, delimitamos los campos con un caracter tab. Para más información sobre los delimitadores de campos y otros problemas de formateo ELF, puedes visitar http://www.w3.org/TR/WD-logfile-960221.html.
|
Ejemplo de clase:
import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* This example outputs the User-Agent field into a
custom field called MyCustomField
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}
Evitar Ataques de Denegación de Servicio
Un ataque de Denegación-de-Servicio es un intento malicioso de sobrecargar un servidor con peticiones. Un tipo común de ataques es enviar enormes cantidades de datos en un método HTTP POST. Podemos seleccionar tres atributos en WebLogic Server para evitar este tipo de ataques. Estos atributos se seleccionan desde la Consola de Administración, bajo Servers o Virtual Hosts. Si definimos estos atributos para un host virtual, los valores configurados para el host virtual sobreescriben a los configurados para el servidor.
- PostTimeoutSecs
Podemos limitar la cantidad de tiempo que WebLogic Server espera entre bloques de datos recibidos en un POST HTTP.
- MaxPostTimeSecs
Limita la cantidad total de tiempo que gasta un WebLogic Server recibiendo datos POST. Si este limite se dispara, se lanza una PostTimeoutException y aparecerá el siguiente mensaje en el log del servidor:
Post time exceeded MaxPostTimeSecs.
- MaxPostSize
Limita el número de bytes de datos recibidos en un POST desde una sola petición. Si se alcanza este límite, se lanzará una excepción MaxPostSizeExceeded y se enviará el siguiente mensaje al log del servidor:
POST size exceeded the parameter MaxPostSize.
Se envía un código de error HTTP 413 (Request Entity Too Large) al cliente.
Si el cliente está en modo escucha, obtiene estos mensajes. Si no lo está, se rompe la conexión.
Configurar un Servidor WebLogic para Tunneling HTTP
El tunneling HTTP proporciona una forma de simular una conexión socket con estado entre WebLogic Server y un cliente Java cuando nuestra única opción es usar el protocolo HTTP. Generalmente se usa para enrutar a través de un puerto HTTP en un firewall de seguridad. HTTP es un protocolo sin estado, pero WebLogic Server proporciona tunneling funcionalmente para hacer que la conexión parezca ser una T3Connection normal. Sin embargo, podemos esperar alguna perdida de rendimiento en comparación con una conexión de socket normal.
Configurar la Conexión de Tunneling HTTP
Bajo el protocolo HTTP, un cliente sólo podría hacer una petición, y luego aceptar una respuesta del servidor. El servidor podría no comunicar voluntariamente con el cliente, y el protocolo es sin estado, lo que significa que no es posible una conexión contínua en los dos sentidos.
El tunneling HTTP de WebLogic simula una T3Connection mediante el protocolo, HTTP, evitando estas limitaciones. Hay dos atributos que podemos configurar en la Consola de Administración. Podemos acceder a estos atributos en la sección Servers, bajo la pestaña Tuning situada debajo de la pestaña Configuration. Se acoseja que los dejemos en sus valores por defecto a menos que experimentemos problemas de conexión. Estas propiedades las usan los servidores para determinar si la conexión del cliente es todavía válida, o si el cliente todavía está vivo.
Conectar con un Servidor WebLogic desde el Cliente
Cuando nuestro cliente solicita una conexión con un WebLogic Server, todo lo que necesitamos hacer para usar el tunneling HTTP es especificar el protocolo HTTP en la URL. Por ejemplo:
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);
Desde el lado del cliente, se añade una etiqueta especial al protocolo htpp, para que el Servidor WebLogic sepa que ésta es una conexión tunneling, en lugar de una petición HTTP normal. Nuestro código de aplicación no necesita hacer ningún trabajo exra para hacer que esto suceda.
El cliente debe especificar el puerto en la URL, incluso si el puerto es 80. Podemos configurar nuestro Servidor WebLogic para que escuche peticiones HTTP en cualquier puerto, aunque la elección más común es el puerto 80 porque normalmente tiene pemitido el paso por los firewalls.
Especificamos el puerto de escucha para el Servidor WebLogic en la Consola de Administración bajo el nodo “Servers”, en la pestaña “Network”.
Usar I/O Nativa para Servir Ficheros Estáticos (Sólo Windows)
Cuando se ejecuta WebLogic Server sobre Windows NT/2000 podemos especificar que WebLogic Server use la operación TransmitFile del sistema en lugar de usar los métodos Java para servir ficheros estáticos como ficheros HTML, los ficheros de texto, y ficheros de imágenes. Usando I/O nativa podemos proporcionar mejoras de rendimiento cuando se sirven grandes ficheros estáticos.
Para usar I/O nativa, añadimos dos parámetros al descriptor de despliegue web.xml de una aplicación Web que contenga los ficheros a servir usando I/O nativa. El primer parámetro, weblogic.http.nativeIOEnabled debería configurarse como TRUE para permitir el servicio de ficheros por I/O nativa. El segundo parámetro weblogic.http.minimumNativeFileSize configura el tamaño de fichero para usar I/O nativa. Si el fichero a servir es mayor que este tamaño, se usara la I/O nativa. Si no especificamos este parámetro, se usa un valor de 400 bytes.
Generalmetne, la I/O nativa proporciona una mayor ganancia de rendimiento cuando sirve ficheros mayores; sin embargo, cuando se incrementa la carga de una máquina que ejecuta WebLogic Server, esta ganancia disminuye. Podríamos necesitar expermientar para encontrar el valor correcto de weblogic.http.minimumNativeFileSize.
El siguiente ejemplo, muestra las entradas completas que deberíamos añadir al descriptor de desarrollo web.xml. Estas entradas deben situarse en el fichero web.xml después del elemento <distributable> y antes del elemento <servlet>.
<context-param>
<param-name>weblogic.http.nativeIOEnabled</param-name>
<param-value>TRUE</param-value>
</context-param>
<context-param>
<param-name>weblogic.http.minimumNativeFileSize</param-name>
<param-value>500</param-value>
</context-param>
Tutoriales
