lunes, 31 de agosto de 2015

APLICACIÓN 'WS-ADDRESSING' ...

'WS-Addressing' es una especificación WS, que permite incluir en un mensaje SOAP información sobre el servicio emisor en  lo relacionado a los destinatarios, a quién se le requiere responder, a quién se debe informar en caso de error, etc, por medio de los mecanismos propios SOAP.

Ahora hablando ya no tan técnicamente, lo que facilita esta especificación es hacer que desde un 1er 'servicio X', al consumir un 2do 'servicio Y', este 'servicio Y' (independientemente de su tipo: Oneway, Sincrono ó Asincrono) permita redireccionar una copia de la 'respuesta' procesada de dicho 'servicio Y' hacia un 3er 'servicio Z' (se podría enviar más de 1 copia). El efecto 'Callback' se cumplirá por medio de esta solución.

El dummy preparado acontinuación muestra la aplicación de esta funcionalidad a nivel de servicios, desarrollado con JAX-WS (Metro) en JDeveloper v11.1.1.7 y desplegado en: Weblogic 12c. Asi mismo, las características de los componentes son las siguientes:

1- DummyAddressingWS: Servicio SOAP en el que se ha aplicado las funcionalidad de 'WS-Addressing' en sus operaciones a nivel de WSDL y código. Las respuesta posibles de las operaciones, serán replicadas a otro servicio definidos internamente de manera directa. Así mismo, internamente el .jar (proxy client), del servicio: 'DummyAddressingCallbackWS', justamente para la realización del efecto de replicación.


2- DummyAddressingCallbackWS: Servicio SOAP que expondrá operaciones que serán consumidas por el servicio: 'DummyAddressingWS_Proxy' (Callback). 


3- DummyAddressingWS_Proxy: Proyecto de tipo Test, el cual contendrá internamente el .jar (proxy client), del servicio: 'DummyAddressingWS', para el procesamiento requerido. Es importante comentar que el consumo por JAX-WS (Metro), será un poco diferente, ya que se requiere especificar una configuración a nivel de código necesaria a causa de la aplicación del 'Addressing'.


Para los interesados, las fuentes propias del dummy mostrado pueden ser descargadas aquí:
http://www.mediafire.com/download/wnd8d8zb3s3cpuv/Dummy_Addressing-Callback.zip


Saludos.


viernes, 21 de agosto de 2015

SOA: SERVICIOS & TECNOLOGÍA

En esta oportunidad brindaré mi opinión personal sobre este muy buen post titulado:
'RESTful APIs are also SOA'
http://www.soa4u.co.uk/2013/09/restful-is-also-soa.html?showComment=1440170531922#c6039681206622596310


ESPAÑOL:
Totalmente de acuerdo con el post, al hablar de SOA como tal NO hay diferencia al hablar tanto de las APIS REST como los WebService (SOAP), no debemos considerarlos como cosas completamente diferentes (tecnológicamente hablando), ya que en si viendolo desde el punto de vista de arquitectura SOA, ambos son considerados como servicios (servicios REST y servicios WS), tal como 'Thomas Erl' lo menciona en sus libros. En si un servicio es una lógica a la cual se le ha aplicado el paradigma de la “Orientación a Servicios” y durante la Fase Análisis son llamados: 'Servicios Candidatos' son considerados 'Activos de la Empresa' (Estos servicios propiamente pueden ser de cualquier tecnología incluídas: REST y WS, eso si con estándares definidos).

Por otro lado, a nivel de WS, sobre los WSDL estoy muy de acuerdo ya que brinda un orden a nivel de interface para client/provider (Top-down), algo que REST no maneja hasta el momento (WADL no estandarizado formalmente a nivel de compañias y vendors) y es liminado a definir una buena especificación en documentación.

INGLES:
Totally agree with the post, to talk about SOA as such there is no difference in speaking both as the WebService REST APIs (SOAP), we should not regard them as completely different things (technologically speaking), and that if seeing it from the point SOA view, both are considered as services (REST and WS service) as 'Thomas Erl' mentions in his books. Whether a service is a logic which has been applied to the paradigm of "Service Orientation" and during Phase Analysis are called 'Candidate Services' are considered 'Assets Company' (These services themselves may be of including any technology: REST and WS, that if defined standards).

On the other hand, at the level of WS on the WSDL I agree very much as it provides a command-level interface for client / provider (Top-down), something that REST does not handle so far (WADL not formally standardized level companies and vendors) and is bound to define a good specification documents.

jueves, 13 de agosto de 2015

'VIRTUALIZACIÓN' DE SERVICIOS POR 'OSB'

Como bien se sabe por el surgimiento de la 'Arquitectura Orientada a Servicios' (SOA) y del requerimiento de comunicación que tienen los servicios entre ellos, nace la necesidad a nivel de arquitectura de mejorar dicha comunicación, apoyándonos en el patrón de diseño "Bus de servicios", para que por medio de un ESB evitar las conexiones ‘punto a punto’, mejorar el Enrutamiento, Integración, mantenimiento, etc. En si el objetivo es proveer una capa de ‘Virtualización’ de servicios entre los proveedores y los clientes respectivamente.

En si el tutorial a continuación mostrará de manera rápida como realizar este requerimiento, técnicamente hablando, mediante el OSB (Oracle Service Bus) v12c, tal como la imagen a continuación lo detalla, osea en base al WSDL de un servicio (simularemos mediante un MockService), virtualizaremos este mediante el OSB exponiendo este 2 posibles protocolos de acceso SOAP y XML/JSON osea la comunicación expuesta será por WebService y REST.


Es bueno mencionar que desde la version 12c en la Oracle SOASuite, el OSB ha tenido grandes mejores entre las que resalta el ya no uso de la ide Eclipse como herramienta base para el desarrollo en OSB (v11g), ya que si de por si su manejo en Eclipse era relativamente facil, creaba un poco de controversia del porque BPEL se manejaba en JDeveloper y OSB en Eclipse y en muchos casos se necesitaba de la manipulación de ambas Ides (JCA). Debido a esto desde esta última versión tanto BPEL como OSB serán desarrollado puramente desde JDeveloper. Desde mi punto de vista no es mi Ide preferida y reniego mucho por la falta de 'Drag and Drop', que es una buena Ide y tiene otras cosas muy positivas entre sus mejoras.

Para la descarga del siguiente tutorial dar click aqui:
http://www.mediafire.com/download/6x3saeba2fqxj1s/Virtualizacion+de+Servicio+por+OSB.pdf

Para la descarga la fuente utilizada en el tutorial dar click aqui:
http://www.mediafire.com/download/oje13r7bqwvu915/Virtualizacion+de+Servicio+por+OSB+-+Fuente.zip


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

domingo, 9 de agosto de 2015

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



miércoles, 5 de agosto de 2015

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.

lunes, 3 de agosto de 2015

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


sábado, 1 de agosto de 2015

'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