BENEFICIOS DE MANEJAR VARIOS DOMINIOS

Un dominio de Weblogic Servidor (WLS), es una unidad administrativa perteneciente a un Servidore de Aplicaciones. Asi mismo, sólo un administrador debería de tener conocimiento de dominios existentes.

Actualmente una empresa puede tener diferentes tipos de aplicaciones dispersas geográficamente y organizadas en diferentes áreas. Debido a ello, puede existir muchos dominios separados. Pensando en ello si analizamos cada dominio es una unidad que se administra por separado y se puede organizar dicha administraciónde manera departamental dentro de una empresa (contabilidad, manufactura, transporte, etc).

Por otro lado, una empresa puede querer tener todas sus aplicaciones en diferentes dominios que puedan ir incorporando. Debido a que a menudo es imposible ampliar uno solo dominio para abarcar el total de aplicaciones de toda la empresa. Así mismo, se debe considerar que teniendo un solo dominio a nivel empresa, acarrearía el ser administrado en su conjunto y la configuración se convertiría casi imposible de manejar y requeriría un esfuerzo mayor en la administración que en el desarrollo e implementación de las aplicaciones propiamente.

Finalmente, para mantener un correcto dominio (segmentado / distribuido) para la administración, se debe de separar las aplicaciones en 'multiples dominios' permitiendo que las aplicaciones en un dominio, puedan acceder a los servicios en otros dominios. 

CENTRALIZAR INICIO DE SERVERs

Muchos de nosotros que trabajamos en nuestros ambientes con muchos servidores de aplicaciones, contenedores de servlets, etc, de diferentes vendors y con diferentes dominios creados por cada uno, tenemos la necesidad de que por cada escenario que queramos probar, tengamos que conocer la ruta donde Iniciar y/o Detener cada uno de estos Servidores. Así mismo, mientras más de estos tengamos más difícil será que nos acordemos las ubicaciones de ellos.

Una solución común a este problema es tener un .txt con todas las rutas como informativo por medio de un acceso directo en nuestro escritorio. Otra es ir a inicio/windows/NOMBRE_SERVER/... , pero si nos ponemos a pensar son muchos pasos los que se deben realizar constantemente. Analizando estos casos como informático debemos innovar con una mejor solución para este problema común.

Para ello la solución pensada y planteada es: Centralizar todas estas ubicaciones de rutas de servidores en un archivo .bat que como se menciona centralice y en base a una orden Inicie y/o Detenga los Servidores requeridos. Para ello haremos lo siguiente:

1. Se debe crear un archivo .bat de la siguiente manera:

2. En el 1er cuadro en Rojo se definen el menú que se visualizará para seleccionar.

3. En el 2do cuadro en Rojo se matricula las letras definidas en el 1er paso, según el orden, para el Choise correspondiente.

4. En el 3er cuadro en Rojo se ingresar los IF's correspondientes a las Letras anteriores y que invocarán a LABELs por cada configuración a crear más a abajo:

5. Se crearán  la configuración por cada LABEL un bloque con la DOMAIN_HOME y en base a esta, las variables: COMANDO_START y COMANDO_STOP para los controles respetivos. Esto se deberá realizar por cada configuración nueva que se requiera hacer:

El resultado de esto es un herramienta que centralizará todos los acceso al inicio de los servidores de manera facil e intuitiva y que hará que uno ya no se preocupe de este problema común. En este caso se puede apreciar una variada gama de servidores entre los que resaltan: SOAUITE. OSB, Tomcat, ETOM, etc ...

Para los interesados pueden descargar el .bat desde aquí:
http://www.mediafire.com/download/p76ttp6ppry6or2/Iniciador_Servidores.zip

TRANSFORMACIONES DE FORMATOS CON 'MFL' EN OSB

Usualmente en BPEL se acostumbra utilizar el 'File Adapter' para leer archivos NO XML y transformarlos a formato XML, pero en OSB junto con el adaptador de archivos también existe otra forma NO muy conocida de realizar dicha tarea. Esta se conoce como MFL y la podemos utilizar para transformar datos NO XML a datos XML y viceversa.

En este post se procederá a mostrar cómo transformar los datos NO XML a datos XML utilizando MFL. Para mostrar este funcionamiento, se ha preparado un dummy de un Servicio Virtual que consistirá en lo siguiente:

"Se ingresará una trama (Formato: NO XML) en una ubicación específica, que será procesada por el OSB. Esta trama procederá a ser transformada en formato XML para ser enviada de Request contra el WS. El Response del WS será transformado a formato NO XML (Trama), para ser finalmente depositado en una ubicación de salida como archivo generado".

DUMMY:

1. Considerando que la Trama INPUT tendrá este formato y será ubicado en una ruta local (especificada en el Proxy Service más adelante):

2. Definir y crear una RUTA BASE, que contendrá 4 directorios:

- TEMP: Directorio encargado de procesar los archivos de manera temporal.

- ERROR: Directorio encargado de almacenar los archivos con error en el proceso.

- INPUT: Directorio donde se ubicarán las tramas a procesar.

- OUTPUT: Directorio donde se generarán las tramas de respuesta del proceso.

3. Definir la estructura de directorios de muestro proyecto OSB:

4. Creamos un BusinessService que referencie y controle por medio del WSDL incrustado en el proyecto al WebService: 'http://localhost:8090/mockDatosClienteService?wsdl',(Un MockServices que he iniciado por medio de SOAPUI):

5.  Crear los archivos MFL (sobre el proyecto: new/MFL), tal como se explicó por medio de estos archivos se configurarán las transformaciones NO XML a XML y XML a NO XML. Con esta lógica ya podremos definir el MFL INPUT: encargado de transformar TRAMA a REQUEST y el MFL OUTPUT: encargado de transformar RESPONSE a TRAMA:

Para esto se debe de conocer antes de definir las tramas, los datos REQUEST/RESPONSE del WS a consumir:

5.1. Crear el archivo: DatosCliente_IN.mfl, para la transformacion INICIAL,considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

5.2. Crear el archivo: DatosCliente_OUT.mfl, para la transformacion FINAL, considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

6. Crear los XQuery consideranto las transformaciones que se manejaran:

6.1.  DatosCliente_IN.xq: Encargado de transformar la Trama (NO XML) hacia el REQUEST del WS: 

6.2.  DatosCliente_OUT.xq: Encargado de transformar la el RESPONSE del WS hacia la Trama (NO XQML) a generar:  

7. Crear un BusinessService de tipo Messaging Service que referencie y controle un MFL (Trama):

Definir el directorio donde se generarán las tramas de respuesta (OUTPUT) al finalizar procesamiento:

 

Definir parte del nombre de los archivos que se generarán para cada procesamiento, así mismo la extensión de los archivos de salida propiamente:

8.  Crear un ProxyService que controle los mensaje INPUT (Trama), que se dejarán en la ruta configurada:

Definir la ruta INPUT donde se depositará la trama:

Configurar tiempo, intervalo, formato y directorios (rutas) de control con relación a las tramas INPUT:

Creamos desde Message Flow los nodos que soportarán el funcionamiento del Servicio Virtual:

Con esto tenemos el Servicio Virtual completado, para las pruebas simplemente bastaría con depositar la trama INPUT en el directorio definir y automáticamente el flujo del Servicio Virtual se activará y a nivel de consola se visualizará el resultado:

PRUEBA:

1. Ubicar la trama en la ruta INPUT definida (C:\Ficheros\MFL\INPUT):  

2. El Servicio Virtual en un tiempo determinado procesará el mensaje (Trama):

3. Finalmente, por cada registro en la trama se generarpa y consumirá un REQUEST del WS y así mismo generará un archivo OUTPUT por cada RESPONSE:

Para los interesados se pueden descargar las fuentes del Dummy (OSB 11g - '11.1.1.7') desde aquí:  http://www.mediafire.com/download/fdz82c149nt8yfq/DummyNoXml_To_Xml.jar