'SOASUITE 12c' [The JRE was not found]

Un error raro que sucede durante el inicio del 'Default Domain' que viene integrado con la 'SOASuite 12c' es el siguiente:

"The JRE was not found in directory C:\Oracle\MIDDLE~1\jdk160_29.(JAVA_HOME) Please edit your environment and set the JAVA_HOME variable to point to the root directory of your Java installation".

El error hace referencia a un error relacionado con el JRE que NO es reconocido y uno en primera instancia piensa que el problema es a causa del JDK que no es encontrado y procede a modificar variables de entorno, pero el error PERSISTE. Luego, se piensa en modificar en la ruta del dominio dentro de la SOASuite en el archivo: setDomain la variable JAVA_HOME, pero igual el error PERSISTE. Finalmente, uno opta por desinstalar TODO y se da cuenta que luego de  reinstalar TODO, el error aún PERSISTE.

La solución a este error es que debido a la instalación de varios Weblogic, JDeveloper y JDKs previamente, sus configuraciones de estos se quedan pegados en una ruta que es:"C:\Users\\AppData\Roaming\JDeveloper", en sí  lo que se debe hacer es simplemente ELIMINAR este directorio 'JDeveloper' completamente, así cuando se vuelva a iniciar JDeveloper y correr el Dominio por Default o otro, estos iniciarán sin este problema caprichoso.

CAMPOS DINÁMICOS EN 'WSDL / XSD'

Durante los desarrollos de servicios tipo Web Service, los que estamos en el ambiente de desarrollos relacionados a EAI / SOA principalmente, sabemos que para el manejo de los Web Service propiamente, como buena práctica, es estándar el diseñar los contratos de servicios (WSDL) para poder en base a ellos, realizar los Top-down respectivos y en base a estos generar las clases necesarias para poder realizar los implementaciones de los servicios propiamente.

En esta oportunidad mostraré una forma de cómo, al momento de diseñar la interface WSDL, los parámetros que se manejan tanto en el Request / Response, se puede manejar dinámicamente. En si cuando hablamos de dinamismo quiero decir que por ejemplo al momento de crear los parámetros tanto para el Request / Response, normalmente estos son diseñados basados en types: (xsd:string, xsd:int, etc) de la siguiente forma:

Ahora al ser diseñado de esta manera la cantidad de campos enviados serán siempre de un tamaño fijo y ante cualquier campo adicional que se desee agregar, se necesitará alterar la Interface WSDL (esto impactará en la generación de otro Top-down, tanto para el server como para el cliente proxy).

Una solución para evitar este problema es el diseño dinámico en los 'xsd:Type'. Esta idea también es diseñada dentro de un 'xsd:complexType' y 'xsd:element', pero la idea no es tener comúnmente una cantidad de campos fija, sino tener un objeto o lista de campos definidos como: ‘Campo/Valor’ de la siguiente manera:

De esta manera los Top-down brindará fácilmente enviar la cantidad deseada tanto en el Request como Response deseado y dentro de la implementación, dependiendo del lenguaje deseado por ejemplo en JAVA simplemente se deberá antes que nada iterar un FOR combinándolo con un IF para comparar y obtener los campos deseados independientemente de la cantidad de campos que se desee. Vale la pena indicar que de este modo, una vez implementado previamente el Web Service, ya no será necesario realizar algún tipo de cambio tanto en el server como en el cliente proxy respectivamente.

Espero que la información les haya servido

APLICACIÓN DE 'MTOM' EN SERVICIOS WEB.

En esta oportunidad hablaré un poco sobre un mecanismo no muy utilizado y conocido que es MTOM. Dicho MTOM (SOAP Message Transmission Optimization Mechanism), es un estándar a nivel de servicios Web, que permite la transferencia o envío de datos binarios (documentos, imágenes, mensajes de gran tamaño o con estructura compleja), de manera eficiente hacia y desde servicios Web.

MTOM requiere que el mensaje binario dentro del XML document sea codificado en 'base64', ya que dichos datos binarios serán envíados como attachment.

Para usar MTOM basta con seguir estos pasos:

1. Desde el SERVIDOR:

A. Habilitar el tipo de mensaje en el WSDL del servicio:

B. En la clase implementadora ingresa la anotación @MTOM respectiva, para que el servicio reconosca que se va a trabajar con MTOM:

C.  Al aplicar el Topdown respectivo, notaremos que la equivalencia al 'base64', será una variable de tipo 'byte[]', se deben de entender que en base al tipo de mensaje serializado que se defina como envío se deberá de parsea el 'contenType' respectivo. Ejmplo: "image/jpeg", "image/jpg", "image/gif", "application/pdf", etc. Así como las rutas absoludas de descarga de los adjuntos (imagen, pdf, etc) en el servidor ó si es en algún otro server, la solucion FTP ó SFTP respectiva.



2. Desde el CLIENTE:

A. Desde la aplicacion cliente se verá de realizar el envío del adjunto propiamente y su respectiva serialización, dicha serializacion variará dependiendo del tipo de adjunto que se requerirá envíar:

Para los interesados se comparte el siguiente dummy, que cumple todo lo explicado previamente para la aplicacion de MTOM. Implementado bajo el Ide ECLIPSE y con JAXWS. Los componentes adjuntados son:

- DummyMTOMCliente
- DummyMTOMServer


http://www.mediafire.com/download/x916kri9tiyrfyq/DummyMTOM.zip

Saludos.

DUMMY 'JODD MICROFRAMEWORKS'

Jodd (http://jodd.org/) es paquete ligero de código abierto y herramientas Java todas empaquetadas  en sólo 1 Mb. 

Entre las funcionalidad que brinda Jodd es Inyección de dependencia, marco MVC, motor AOP, manejo de DB-objeto,  herramientas utilitarias, analizador de HTML, manejador de  properties, manejador de BeanUtil, JDateTime, envió de correo, JSon parser, etc.

Una de las ventajas de Jodd es que está creado para maximizar la productividad con código intuitivo, pero de gran alcance mediante el uso de un diseño pragmático, el código se hace más pequeño y más simple.

Para los interesados se comparte el siguiente dummy que contiene gran cantidad de las funcionalidades que Jood brinda, en las cuales se desarrollado los métodos:
                   
-    procesando_BeanUtil();
-    procesando_StringUtil();
-    procesando_JDateTime();
-    procesando_Props();
-    procesando_Email();
-    procesando_DbQuery();
-    procesando_DbOomQuery();
-    procesando_PetiteBean();
-    procesando_Json();


Dummy:
http://www.mediafire.com/download/x2rfdh9pab094yc/Dummy_Jodd_MicroFrameworks.zip

'RELIABLE MESSAGING' ...

Se define como un SOA Pattern, en el cual el problema es comunicación del servicio que no puede ser Reliable Messaging garantizada al usar protocolos de mensajería o ser usado en ambientes poco fiables. En si lo que soluciona este patrón es aplicar un mecanismo para garantizar la entrega de la mensajería a un destino específico.

Para lograr este objetivo se aplica la especificación WS-ReliableMessaging (WS-RM), justamente para asegurar la entrega fiable del mensaje, así mismo dicha especificación va de la mano con otra especificación que es la WS-Addressing que ayuda en identificar servicios web y mensajes independientemente del protocolo de transporte utilizado.

Actualmente, existe muy poca información sobre estos temas, debido a ello el tutorial y dummy preparado a continuación muestra justamente la aplicación de: WS-ReliableMessaging, WS-Addressing en un servicio de tipo One-way el cual por ser propiamente ‘asíncrono’ no existe respuesta inmediata, pero mediante un callback la respuesta (que puede durar N tiempo) es respondida por medio de otra operación de manera automática:

[Tutorial]:
http://www.mediafire.com/download/4k9us8b743n9shr/Tutorial+Aplicacion+Reliable-+Messaging%2CAddressing%2C+Callback+con+JAXWS+.pdf

[Fuente]:
http://www.mediafire.com/download/ga7m2j2yno8rzny/DumyCallbackServiceWS.zip

VALIDACIONES Y CONTROL DE ERRORES EN WEB SERVICE

En esta oportunidad hablaremos un poco sobre estos temas comunes que durante los desarrollos de este tipo de servicios afromtaremos. 

En lo relacionado al CONTROL DE ERRORES en Web Service, tenemos 2 formas de manejarla:

1. MEDIANTE 'SOAP FAULTS': Esta opción agrega en el WSDL un 3er message para el control de excepciones, esto 
permitirá que antes algún posible error de cualquier tipo en el servicio, esta excepción sea y mostrada toda la traza del 
error en el fault de respuesta.

2. MEDIANTE 'RESPONSE PERSONALIZADO': Este manejo cubre el uso de un 'complexType' que soportará un idTransaccion y mensajeRespuesta, el cual serán siempre personalizados y seteados los mensajes ya sean exitoso o con error.


Por otro lado, a las VALIDACIONES de formato, existen varias formas:

1. MEDIANTE INTERFACE XSD:  Esta opción requiere que todas las restricciones sean ingresadas a nivel de .xsd por medio de 'simpleType', esto permitirá que si algún atributo del REQUEST no cumpla con la restricción automáticamente sea rechazado y no ingrese al flujo de servicio. Este manejo no permite identificar qué campo ha sido mal enviado. 

2. MEDIANTE VALIDACIONES EN CÓDIGO: Esta opción requiere que los atributos del REQUEST sean validados uno por uno mediante sentencias IF / ELSE. Y permite saber identificar qué campo es el que ha sido mal enviado por la aplicación consumidora.

RECOMENDACIONES:

Debido a mi experiencia puedo mencionar las siguientes recomendaciones:

CONTROL DE ERRORES:  Recomendaría la opcion#2, ya que brinda un mejor control tanto para la identificación de las transacciones, variedad de mensajes exitosos y erróneos que se pueden personalizar.

Esto ayuda sobre todo a las aplicaciones consumidoras para la identificación respectiva. Esta es una ventaja que la opcion#1, no se puede manejar ya que simplemente aquí ante un error revienta y muestra la traza completa del error.

VALIDACIONES:  Recomendaría un híbrido entre las 2 opciones, esto se manejaría definiendo un .xsd con las restricciones del servicio 'simpleType', este archivo sería utilizado para validar dichas restricciones a nivel de código pero directamente igualando REQUEST contra .xsd, si cumple con las restricciones se acceder al flujo del servicio y sino se responde el mensaje personalizado.

Si se tiene un desconocimiento de cómo aplicar esto por ejemplo en JAVA podemos apoyarnos en las librerías: JDOM, XMLBEANs y JAXB, para realizar las transformaciones y validaciones respectivas. 

APLICACIÓN DE ‘SSL’ [HTTPs], PARA EL CONSUMO DE WS CON JAXWS.

SSL: (Secure Sockets Layer) es un protocolo que proporciona autenticación y privacidad de la información sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.
Así mismo, tanto el cliente y el servidor negocian qué algoritmos criptográfico se va a usar. Actualmente se proporcionan las siguientes opciones:

• Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza.
• Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES y AES (Advanced Encryption Standard).
• Funciones de hash: MD5 o de la familia SHA.

El tutorial preparado muestra el manejo para consumir Web Service sobre Weblogic de tipo HTTPs, aplicando dos formas: aplicando la autenticación respectiva (certificado digital) y también, obviando dicha autenticación (saltándola):

El índice de contenido del tutorial es el siguiente:

1.   CONFIGURACIÓN WEBLOGIC SERVER.
2.   CONFIGURACIÓN PARA: [CERTIFICADOS DE CONFIANZA].
3.   CONSUMO DE WEBSERVICE [HTTPs].
      A.   Consumo de WS con Autenticación.
      B.  Consumo de WS SIN Autenticación.

• Para DESCARGAR el tutorial pulsar: Aquí.
• Así mismo, para descargar la fuente de cliente WS aplicando todo lo detallado en el tutorial, pulsar: Aquí

Espero haberlos ayudado, hasta la próxima.