Java en castellano. BEA WebLogic: Guía de Administración java jsp

El Plug-In para Microsoft Internet Information Server permite que las peticiones sean pasadas (proxy) desde un Microsoft Internet Information Server (IIS) a un Servidor WebLogic. El Plug-In mejora la instalación de un IIS permitiendo que el Servidor WebLogic maneje aquellas peticiones que requieren las funcionalidades dinámicas de WebLogic.

El plug-in se ha pensado para un entorno en el que Microsoft Internet Information Server sirve páginas estáticas, y otra parte del árbol de documentos (páginas dinámicas mejor generadas por Servlets HTTP o JavaServer Pages) se delega en el Servidor WebLogic, que podría estar operando en un proceso diferente, posiblemente en un host diferente. En el usuario final -- el navegador -- las peticiones HTTP delegadas al Servidor WebLogic parecerán que vienen de la misma fuente. La funcionalidad del tunneling HTTP del protocolo cliente-servidor de WebLogic también puede operar a através del Plug-In, proporcionando acceso a todos los servicios del Servidor WebLogic.

Almacen de Conexiones y Keep-Alive

El Plug-In para Microsoft Internet Information Server mejora el rendimiento usando un almacen de conexiones re-utilizables desde el plug-in hacia el Servidor WebLogic. El Plug-In implementa conexiones HTTP 1.1 keep-alive entre el plug-in y el Servidor WebLogic re-utilizando la misma conexión en el almacen para subsecuentes respuestas desde el mismo cliente. Si la conexión está inactiva por más de 30 segundos, (u otra cantidad de tiempo definida por el usuario) se cierra y se devuelve al almacen.

Peticiones Proxy

El plug-in pasa (hace de proxy) peticiones al Servidor WebLogic basándose en una configuración que nosotros especificamos. Podemos pasar peticiones basándonos en la URL de la peticiones (o en una porción de la URL). Esto se llama proxy por path. También podemos pasar peticiones basándonos en el tipo MIME del fichero solicitado. También podemos usar una combinación de ámbos métodos. Si una petición cumple los dos criterios, se pasa por path. También podemos especificar parámetros adicionales para aquellos tipos de peticiones que definen un comportamiento adicional del plug-in.

Plataformas Soportadas

Para obtener la última información sobre los sistemas operativos y la compatibilidad de las versiones IIS con el Plug-In de Microsoft Internet Information Server, puedes ver la página http://e-docs.bea.com/wls/platforms/index.html#iis.

Instalar el Plug-In para Microsoft Internet Information Server

Para instalar el Plug-In de Microsoft Internet Information Server:

Copiamos el fichero iisproxy.dll desde el directorio /bin de nuestra instalación de WebLogic Server dentro de un directorio de conveniencia que sea accesible por IIS. Este directorio también debe contener el fichero iisproxy.ini.

Arrancamos el IIS Internet Service Manager, selecccionándolo desde el menú de Inicio de Microsoft IIS.

En la panel izquierdo del Service Manager, seleccionamos nuestra website (por defecto es “Default Web Site”).

Pulsamos en la flecha “Play” de la barra de herramientas para arrancar.

Abrimos las propiedades para la website seleccionada pulsando con el botón derecho del ratón sobre la selección de webiste en el panel izquierdo.

En el panel Properties, seleccionamos la pestaña Home Directory, y pulsamos el botón Configuration en la sección Applications Settings.

Configuramos el tipo de fichero a pasar (proxy):

Sobre la pestaña App Mappings, pulsamos el botón Add para añadir los tipos de ficheros y configurarlos para ser pasaddos a WebLogic Server.

En la caja de diálogo, navegamos hasta encontrar el fichero iisproxy.dll.

Seleccionamos la Extension del tipo de fichero que queremos pasar a WebLogic Server.

Marcamos el checkbox Script engine.

Desmarcamos el checkbox Check that file exists.

Seleccionamos los métodos de exclusión según sea necesario para crear una instalación segura.

Cuando finalizamos pulsamos el botón OK para grabar la configuración. Repetimos este proceso por cada tipo de fichero que queramos pasar a WebLogic.

Cuando hayamos terminado de configurar los tipos de ficheros, pulsamos el botón OK para cerrar el panel Properties.

Nota:
Cualquier información de path que añadamos a la URL después del servidor y del puerto se pasa directamente a WebLogic Server. Por ejemplo, si solicitamos un fichero desde IIS con la URL:

http://myiis.com/jspfiles/myfile.jsp

es pasada a WebLogic Server con una URL como:

http://mywebLogic:7001/jspfiles/myfile.jsp

Creamos el fichero iisproxy.ini.
El fichero iisproxy.ini contiene parejas nombre=valor que definen los parámetros de configuración para el plug-in. Los parámetros se listan en Parámetros Generales para Plug-Ins de Servidores Web.

Nota:
Los cambios en los parámetros no tendrán efecto hasta que no reiniciemos el “IIS Admin Service” (bajo services, en el panel de control).

BEA recomienda que situemos el fichero iisproxy.ini en el mismo directorio que contiene el fichero iisproxy.dll. También podemos usar otras localizaciones. Si situamos el fichero en otro lugar, observa que WebLogic Server busca iisproxy.ini en los siguientes directorios, y en el siguiente orden:
- En el mismo directorio donde está iisproxy.dll.
- El directorio home de la versión más reciente de WebLogic Server que esté referenciada en el Registro de Windows. Si WebLogic Server no encuentra el fichero iisproxy.ini aquí, continúa buscando en el registro de Windows viejas versiones de WebLogic Server y busca el fichero iisproxy.ini en los directorios home de dichas instalaciones.
- c:\weblogic

Definimos el nombre de host y el puerto del Servidor WebLogic al que Microsoft Internet Information Server pasará las peticiones. Dependiendo de nuestra configuración, hay dos formas de definir el host y el puerto:
- Si estamos pasando peticiones a un sólo servidor WebLoigc, definimos los parámetros WebLogicHost y WebLogicPort en el fichero iisproxy.ini. Por ejemplo:
```
WebLogicHost=localhost
WebLogicPort=7001
```
- Si estamos pasando peticiones a un cluster de servidores WebLogic, definimos el parámetro WebLogicCluster en el fichero iisproxy.ini. Por ejemplo:
```
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001
```

Configuramos el paso por path. Además de pasar por el tipo de fichero podemos configurar el Plug-In Microsoft Internet Information Server para que sirva ficheros basándose en su path especificando algunos parámetros adicionales en el fichero iisproxy.ini. Pasar por path tiene preferencia sobre el paso por tipo MIME.
Para configurar el paso (proxy) por path:
- Situamos el fichero iisforward.dll en el mismo directorio que el fichero iisproxy.dll y añadimos el fichero iisforward.dll como un filtro de servicio en IIS (WebSite Properties ?ISAPI Filters tab ?Add el iisforward dll).
- Registramos .wlforward como un tipo especial de fichero a manejar por iisproxy.dll.
- Definimos la propiedad WlForwardPath en iisproxy.ini. WlForwardPath define el path pasado al Servidor WebLogic, por ejemplo:
```
WlForwardPath=/weblogic.
```
- Seleccionamos el parámetro PathTrim para cortar el WlForwardPath cuando sea necesario. Por ejemplo, usando:
```
WlForwardPath=/weblogic
PathTrim=/weblogic
```
  cortamos una petición desde IIS a Weblogic Server. Por lo tanto, /weblogic/session es cambiado por /session.
- Si queremos que las peticiones no contengan información extra de path (en otras palabras, que las peticiones sólo contengan el nombre del host), seleccionamos el parámetro DefaultFileName con el nombre de la página de bienvenida de la Aplicación Web a la que se le está pasando la petición. El valor de este parámetro se añade a la URL.
- Si necesitamos depurar nuestra aplicación, seleccionamos el parámetro Debug=ON en el fichero iisproxy.ini. Se genera un fichero c:\tmp\iisforward.log que contiene un diario de la actividad del plug-in que podemos usar para depurar.

Seleccionamos cualquier parámetro adicional del fichero iisproxy.ini. Los parámetros se listan en Parámetros Generales para Plug-Ins de Servidores Web.

Si estamos pasando servlets desde IIS al Servidor WebLogic y no estamos pasando por path, debemos leer la sección Pasar Servlets desde IIS al Servidor WebLogic.

Crear ACLs através de IIS

Los ACLs no funcionan a través del Plug-In de Microsoft Internet Information Server si el IIS no pasa la cabecera de autorización. Usamos la siguiente información para asegurarnos de que la cabecera de Autorización es pasada.

Cuando usamos Autenticación Básica, el usuario entra con derechos de log local. Para permitir el uso de Autenticación básica, concedemos a cada cuenta de usuario los derechos de usuario Log On Locally en el servidor IIS. Observa que podrían resultar dos problemas del uso de logon local de la Autenticación básica:

Si el usuario no tiene permisos de logon local, la Autenticación básica no funcionará incluso si las configuraciones de FrontPage, IIS, y Windows NT parecen ser correctas.

Un usuario que tenga permisos de logon local y que pueda obtener acceso físico al ordenador host que ejecuta IIS podría arrancar una sesión interactiva en la consola.

Para permitir la Autenticación Básica, en el pestaña Directory Security de la consola, nos aseguramos que que la opción Allow Anonymous está a "on" y todas las demás opciones están a "off".

Fichero iisproxy.ini de Ejemplo

Aquí tenemos un fichero iisproxy.ini de ejemplo, para usarlo con un sólo servidor WebLogic (sin clusters). Las línea de comentarios empiezan con el carácter "#":

# This file contains initialization name/value pairs
# for the IIS/WebLogic plug-in.
WebLogicHost=localhost
WebLogicPort=7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2

Aquí tenemos un fichero iisproxy.ini de ejemplo con un cluster de Servidores WebLogic:

# This file contains initialization name/value pairs
# for the IIS/WebLogic plug-in.
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2

Nota:
Si estamos usando SSL entre el Plug-In y el servidor WebLogic el número de puerto debería está definido como el puerto de escucha SSL.

Usar SSL con el Plug-In de Microsoft Internet Information Server

Podemos usar el protocolo Secure Sockets Layer (SSL) para proteger la conexión entre el Plug-In de Microsoft Internet Information Server y el Servidor WebLogic. El protocolo SSL proporciona confidencialidad e integridad de los datos pasados entre el Plug-In de Microsoft Internet Information Server y el Servidor WebLogic. Además, el protocolo SSL permite al plug-in autenticarse a si mismo en el Servidor WebLogic para asegurar que la información es pasada a un principal seguro.

El Plug-In de Microsoft Internet Information Server no usa el protocolo de transporte (http o https) para determinar si se usará o no el protocolo SSL para proteger la conexión entre el plug-in y el Microsoft Internet Information Server. Para usar el protocolo SSL con el Plug-In de Microsoft Internet Information Server, configuramos el Servidor WebLogic que recibe las peticiones pasadas para usar el protocolo SSL. Se usa el puerto de este servidor que está configurado para comunicación segura SSL para comunicar con el Microsoft Internet Information Server.

Para usar el protocolo SSL entre el Plug-In de Microsoft Internet Information Server y el Servidor WebLogic:

Configuramos el Servidor WebLogic para SSL. Para más información puedes ver Configurar el Protocolo SSL.

Configuramos el puerto de escucha SSL del Servidor WebLogic. (Ver Configurar el Puerto de Escucha).

Seleccionamos el parámetro WebLogicPort en el fichero iisproxy.ini al puerto de escucha configurado en el paso 2.

Seleccionamos el parámetro SecureProxy en el fichero iisproxy.ini a ON.

Seleccionamos cualquier parámetro adicional en el fichero iisproxy.ini que defina información sobre la conexión SSL. Puedes ver una lista completa de parámetros en Parámetros SSL para Plug-Ins de Servidores Web.
Por ejemplo:
```
WebLogicHost=myweblogic.com
WebLogicPort=7002
SecureProxy=ON
```

Pasar Servlets desde IIS al Servidor WebLogic

Los Servlets se pueden pasar por path si la iisforward.dll está registrada como un filtro. Deberíamos llamar a nuestro servelt con una URL similar a esta:

http://weblogic:7001/weblogic/myServlet

Para pasar servlets si iisforward.dll no está registrada como un filtro, debemos configurar el paso por tipo de fichero. Para pasar Servlets por tipo de fichero:

Registramos un tipo de fichero arbitrario (extensión) con IIS para pasar la petición al Servidor WebLogic, como se describe en el paso 7 de Instalar el Plug-In de Microsoft Internet Information Server.

Registramos nuestro servlets en la Aplicación Web apropiada.

Llamamos a nuestro servlet con una URL formada siguiendo este patrón:

http://www.myserver.com/virtualName/anyfile.ext

donde virtualName es el patrón de URL definido en el elemento <servlet-mapping> del descriptor de despliegue de la aplicación Web para este servlet, y ext es un tipo de fichero (extensión) registrada con IIS para ser pasada para el Servidor WebLogic. la parte anyfile de la URL se ignora en este contexto.

Nota:

Si los enlaces de imagenes llamados desde el servlet son parte de la aplicación Web, también debemos pasar las peticiones de las imágenes al sevidor WebLogic registrando el tipo de fichero apropiado (probablemente .gif y .jpg) con IIS. Sin embargo, podemos elegir servir estas imágenes directamente desde IIS si se desea

Si el servlet que está siendo pasado tiene enlaces que llaman a otros servlets, estos enlaces también deben ser pasados al servidor WebLogic, conforme al patrón mostrado arriba.

Probar la Instalación

Después de instalar y configurar el Plug-In de Microsoft Internet Information Server, seguimos los siguientes pasos para desplegarla y probarla:

Nos aseguramos de que el Servidor WebLogic e IIS está ejecutándose.

Grabamos un fichero JSP dentro del documento raíz de la Aplicación Web por defecto.

Abrimos un navegador y seleccionamos la URL con el IIS más filename.jsp como se muestra en este ejemplo:
```
http://myii.server.com/filename.jsp
```
Si filename.jsp se ve en nuestro navegador, el plug-in está funcionando.

Errores de Conexión y Control de Fallos en Clustering

Cuando el Plug-In de Microsoft Internet Information Server intenta conectar con el Servidor WebLogic, usa varios parámetros de configuración para determinar cuánto tiempo esperar las conexiones con el host del Servidor WebLogic y, después de establecida la conexión, cuánto esperar por una respuesta. Si el plug-in no puede conectar o no recibe una respuesta, intentará conectar y envíar la petición a otro Servidor WebLogic del Cluster. Si la conexión falla o no hay respuesta de ningún servidor WebLogic del cluster, se envía un mensaje de error.

Fallos de Conexión

El fallo de un host al responder a una petición de conexión podría indicar posibles problemas con la máquina host, problemas de red, u otros varios fallos de servidor.

El fallo de un Servidor WebLogic al responder, podría indicar que WebLoigc no se está ejecutando que no está disponible, un cuelgue de servidor, un problema de base de datos, u otro fallo de aplicación.

Control de Fallos con un Sólo Servidor (sin cluster)

Si estámos ejecutando un sólo Servidor WebLogic se aplica la misma lógica descrita aquí, excepto en que el plug-in sólo intenta conectar con el servidor definido en el parámetro WebLogicHost. Si el intento falla, se devuelve un mensaje de error HTTP 503. El plug-in continúa intentando conectar con el Servidor WebLogic hasta que se excede el tiempo ConnectTimeoutSecs.

La Lista de Servidores Dinámica

Cuando especificamos una lista de servidores WebLogic en el parámetro WebLogicCluster, el plug-in usa esa lista como punto de entrada para el balance de carga entre los miembros del cluster. Después de que se haya enrutado la primera petición a uno de esos servidores, se devuelve una lista dinámica que contiene una lista actualizada con los servidores que hay en el cluster. La lista actualizada añade cualquier nuevo servidor en el cluster y borra cualquier otro que haya dejado de formar parte de él, o que haya fallado al responder peticiones. Esta lista se actualiza automáticamene con la respuesta HTTP cuando ocurre un cambio en el cluster.

Control de Fallos, Cookies y Sesiones HTTP

Cuando una petición contiene una información de sesión almacenada en un cookie, en los datos POST, o codificando la URL, la ID de la sesión contiene una referencia al servidor específico en que se estableció originalmente la sesión (llamado servidor primario) y una referencia a un servidor adicional donde se ha replicado la sesión original (llamado servidor secundario). Una petición que contiene una cookie intenta conectar con el servidor primario, si el intento falla, la petición se enruta hacia el servidor secundario. Si ambos servidores fallan, la sesión se pierde y el plug-in intenta hacer una nueva conexión con otro servidor de la lista dinámica del cluster. Puedes ver más información en la siguiente figura: