BEA WebLogic: Guía de Administració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:

  1. En el panel izquierdo, en el nodo Web Application.
  2. Seleccionamos nuestra aplicaci�n Web.
  3. En el panel derecho, puslamos la pesta�a Targets.
  4. 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.)
  5. Pulsamos Apply.
  6. Pulsamos el nodo Servers (o host virtual) en el panel izquierdo.
  7. Seleccionamos el servidor o host virtual apropiado.
  8. En el panel derecho, pulsamos la pesta�a General.
  9. Seleccionamos la pesta�a HTTP.
  10. Seleccionamos una aplicaci�n Web de la lista desplegable etiquetada Default Web Application.
  11. Pulsamos Apply.
  12. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. Activamos la caja Enable Logging.
  3. Introducimos los valores para nuestro Log File Name.
  4. Seleccionamos Common o Extended de la lista desplegable etiquetada Format.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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:

  1. Incluimos el nombre de campo en la directiva Fields, usando la forma:
    X-myCustomField.
    
    Donde myCustomField es el nombre totalmente cualificado de la clase.
  2. 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.
  3. 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.
  4. 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.

  • Enable Tunneling
    Activa o desactiva el tunneling HTTP. Por defecto est� desactivado.
  • Tunneling Ping
    Cuando se configura una conexi�n tunnel HTTP, autom�ticamente el cliente env�a una petici�n al servidor, por eso el servidor podr�a ofrecer una respuesta al cliente. El cliente tambi�n podr�a incluir instrucciones en una petici�n, pero este comportamiento sucede sin importar si la aplicaci�n cliente necesita comunicar con el servidor. Si el servidor no responde (como parte del c�digo de la aplicaci�n) a la petici�n del cliente dentro del n�mero de segundos configurado en este atributo, lo hace de cualquier modo. El cliente acepta la respuesta y autom�ticamente env�a otra petici�n inmediatamente.

    Por defecto son 45 segundos; el rango v�lido va de 20 a 900 segundos.

  • Tunneling Timeout
    Si ha pasdo el n�mero de segundos configurado en este atributo desde la �ltima petici�n enviada por el cliente al servidor (en respuesta a una respuesta), entonces el servidor decide que el cliente est� muerto, y termina la conexi�n tunnel HTTP. El servidor chequea el tiempo en el intervalo especificado por este atributo, cuando de otra forma deber�a responder a la petici�n del cliente.

    Por defecto son 45 segundos; el rango v�lido va de 20 a 900 segundos.

.�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>

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR