Bien pues aqui de regreso a este lindo blog, queridos 2 lectores..
Bien tengo varios temas pendientes, ejemplos de Mule temas de SOA Governance.. documentacion de Servicios, etc etc etc... en fin... ya estoy trabajando en ellos.
Bueno pues a lo que me trajo este "quejapost". hace ya unos meses escribimos un post acerca de la importantcia de los contratos, en el que basicamente podriamos concluir con la frase que he tomado hace tiempo "la culpa no la tiene el SERVICIO, si no quien lo IMPLEMENTA ( o mejor aun QUIEN LO DISEÑA )"...
Y me vuelvo a preguntar ¿y los estandares apa?..... lo que mas me "encanta" es que cuando se les cuestiona a ciertas personas de la implementacion de sus servicios, contestan "pus si estamos usando WSDL, SOAP, XSD son estandares no?"... ahora si que me pasa como condorito cuando sucede eso.......ploof!!
Bueno pues deseo compartirles que hace unos dias nos toco participar en una integracion entre Secretaria de Economia y el Seguro Social.... concretamente para las parte de alta rapida de empresas..... bueno pues nosotros seremos expositores de algunos servicios, para lo cual agendamos una reunion con estos monitos de Economia para tratar asuntos tecnicos.
Para no hacer el cuento largo, el cuate tecnico me dice "Nosotros necesitamos que ustedes expongan un servicio que reciba un STRING y regrese un STRING y en el se coloque el XML tal y como se definieron los XSD de entrada salida" ... charros y me vuelvo a preguntar ¿y los estandares apa? .... pense que no podria haber algo mas feo que usar un ANY en un servicio Web.... pero que sorpresa me lleve con estos cuates.... en fin..
Lo mas chusco, fue cuando le comente que "nosotros no podriamos usar un servicio expuesto de esa manera, que era necesario hacer el WSDL concreto con los valores de entrada, salida, y mensajes de error" y este amigo comenta "es que tenemos una tecnologia de bus de integracion ESTANDAR (claro es estandar usar STRING) que permite DESACOPLARNOS de otras soluciones y si me mueves el contrato, entonces no podemos hacerlo ( y entonces endonde quedo lo desacoplado del asunto)" ...
Bueno pues despues de desahogarme con ustedes.. .el mensaje que deseo dar a este post es:
- Definan contratos de negocio: usenlo como su diccionario de datos, en algunas framworks como el SOMA se le llama "Service Interface"
- Especifiquen sus servicios: es decir entradas, salidas, mensajes de error, todo ello usando XSDs, en SOMA esto es "Service Contract" y esta en la disciplina de "Service Specification"
- Definan sus WSDLs, en la medida de lo posible NO usen Any o String para mandar cualquier XML de respuesta.... eso le quita el sentido a elaborar un Contrato de Negocio
- En la definicion de su Servicio, siempre consideren informacion necesaria para manejo de errores: ERROR, NUMERO, DESCRIPCION.
Porque si no volvere a preguntarme ¿y los estandares apa?
Por una integracion mejor, hasta la vista
Tuzo
martes 16 de junio de 2009
sábado 6 de junio de 2009
Un día después
Como lo anuncié algunos días atrás, ayer se realizó el RubyCamp en el Instituto de Física de la UNAM en la misma línea de otros eventos estilo 'BarCamp' que se han venido haciendo recientemente y como tal concentra a gente innovadora y entusiasta de la tecnología, particularmente del lenguaje de programación Ruby y su 'killer app': Ruby on Rails.
Alex Juárez y su equipo de trabajo se encargaron del 99% del trabajo de organización del evento el cual incluyo una extensa lista de ponentes (/me incluido) que trataron una variedad de temas pero que nos dejaron con el ansía de seguir realizando eventos de este tipo donde escuchar experiencias e ideas de gente que usa estas herramientas para ganarse el pan y no solo bluffing mercadológico para vendernos algo.
Me parece que es necesario seguir ampliando los espacios para compartir experiencias y traer más material del tema en español. Comentaba en una oportunidad que si bien existen toneladas de información en inglés, es necesario crear nuestra base de conocimientos y compartirla, intercambiar dudas, preguntas, inquietudes sin temor a no obtener respuesta ni a una competencia desleal.
Me sigue inquietando el hecho de que seguimos protegiendo nuestros 'productitos' o 'sistemitas' más que a un niño pequeño e indefenso y por otra parte, en la edición de mayo-julio de la revista Software Guru viene una entrevista a Jorge Zavala que si bien no reconozco en algún ámbito dice algunas frases que me parecen bien ciertas,
También hace referencia a los 'Super Happy Dev House' que se han venido realizando y en lo particular lo asocio con algunos de los eventos 'BarCamp' que han pasado. Hay gente que buscamos compartir lo que creemos bueno, nuestras experiencias y nuestras ambiciones y encontrar algunos otros con las mismas inquietudes, buscar una o más relaciones 'ganar-ganar' donde los beneficios se repartan entre los participantes.
Me quedé con un costal de ideas y un delicioso sabor de boca después de esta experiencia y sin lugar a dudas creo que este ha sido el mejor evento en lo que va del año. Realmente espero el siguiente para participar de nuevo y encontrar más personas participando, intercambiando experiencias y conocimiento.
Finito.
Alex Juárez y su equipo de trabajo se encargaron del 99% del trabajo de organización del evento el cual incluyo una extensa lista de ponentes (/me incluido) que trataron una variedad de temas pero que nos dejaron con el ansía de seguir realizando eventos de este tipo donde escuchar experiencias e ideas de gente que usa estas herramientas para ganarse el pan y no solo bluffing mercadológico para vendernos algo.
Me parece que es necesario seguir ampliando los espacios para compartir experiencias y traer más material del tema en español. Comentaba en una oportunidad que si bien existen toneladas de información en inglés, es necesario crear nuestra base de conocimientos y compartirla, intercambiar dudas, preguntas, inquietudes sin temor a no obtener respuesta ni a una competencia desleal.
Me sigue inquietando el hecho de que seguimos protegiendo nuestros 'productitos' o 'sistemitas' más que a un niño pequeño e indefenso y por otra parte, en la edición de mayo-julio de la revista Software Guru viene una entrevista a Jorge Zavala que si bien no reconozco en algún ámbito dice algunas frases que me parecen bien ciertas,
- "fail fast", si tienes una idea, enfréntala a la realidad, si es buena y funciona, invierte en ella sino continua con la siguiente.
- Necesitas gente con mentes frescas antes que grandes recursos financieros.
- Los negocios son para venderse, no quedarse toda la vida con ellos.
También hace referencia a los 'Super Happy Dev House' que se han venido realizando y en lo particular lo asocio con algunos de los eventos 'BarCamp' que han pasado. Hay gente que buscamos compartir lo que creemos bueno, nuestras experiencias y nuestras ambiciones y encontrar algunos otros con las mismas inquietudes, buscar una o más relaciones 'ganar-ganar' donde los beneficios se repartan entre los participantes.
Me quedé con un costal de ideas y un delicioso sabor de boca después de esta experiencia y sin lugar a dudas creo que este ha sido el mejor evento en lo que va del año. Realmente espero el siguiente para participar de nuevo y encontrar más personas participando, intercambiando experiencias y conocimiento.
Finito.
viernes 29 de mayo de 2009
RubyCamp
El próximo viernes 5 de junio se realizará el evento RubyCamp en las instalaciones del IFUNAM. Como el nombre lo indica, la organización del evento cae en el formato de los Barcamps y las 'no-conferencias'. Se van a concentrar varios conocidos que trabajan activamente con Ruby y con Ruby On Rails dando breves pero sustanciosas pláticas pero también veo en la agenda del evento, gente nueva en la onda Ruby On Rails.
Así que se extiende la invitación a todos los lectores, más detalles los pueden encontrar en el sitio del evento , en la lista de correos o simplemente síguenos en twitter .
Finito.
domingo 29 de marzo de 2009
SOA no solo es Tecnología de Información
Arquitectua Orientada a Servicios ...
Algunos ya dicen que SOA está desapareciendo, que ha sido un fracaso.
La verdad, creo que mucho de lo que ha pasado es que la industria ha visto el implementar SOA como comprar e instalar productos, o como una iniciativa de Tecnologia de Informacion, o por construir WebServices se dicen SOA.
Eso lleva a que al final, para la organización no hay mucho cambio con respecto a la manera como la tecnología de información se implanta.
Es típico, que en cualquier organización, primero se empieza a diseñar un servicio con procesos manuales. Una vez que se empieza a operar dicho proceso, se dan cuenta que tienen muchas labores dignas de automatizar, y van y solicitan a sistemas, una nueva aplicación.
Y por desgracia, cuando llega al área de sistemas, se enfoca a que dicha aplicacion solucione para ese proceso, sin tomar en cuenta todo el contexto de la organización. Y luego cuando se dan cuenta los de sistemas, a jalar copias de base de datos de otras aplicaciones, a intercambiarse archivos planos, interfaces punto a punto y dependencias altas entre las aplicaciones.
Y mientras, la organización perdiendo oportunidades de oro, teniendo escenarios donde por falta de una integración entre sus sistemas, se tardan un largo tiempo en obtener resultados.
He ahi la importancia de una arquitectura comun para las soluciones de tecnologia de información. El chiste de la arquitectura es poner orden, organizar.
Ahora, si dicha orientación se da, pensando que se construyen servicios que permiten automatizar las actividades de los procesos, entonces lo que se puede provocar es que la tecnología se vaya constituyendo a través de servicios de negocio.
El camino que deriva la creación de un servicio debe ser asi:
* Estrategia de negocio u organización. Define los objetivos a alcanzar.
* Servicios de negocio. Manera como la organización entrega un bien o servicio a sus clientes,empleados y/o proveedores.
* Capacidades de Arquitectura Empresarial. Las funcionalidades de tecnología.
* Plataforma de Tecnología de Información. Componentes de software y hardware.
Es decir, cualquier servicio, se origina por alguna necesidad de negocio y tiene como vista, compartir y reutilizar información.
Pero las personas que estan en la organización, en lugar de concebir la automatización de sus procesos a través de aplicaciones, lo hacen a través de servicios.
Pero a ellos no les debe importar si esta en un sistema UNIX con Oracle y Java, o si está en Windows con SQL Server y C#. Lo que debe importar es la información que ofrece y las operaciones de negocio que realiza.
En resumen, SOA no es algo nuevo. Es lo que siempre se ha buscado como, lograr que la tecnología de información sirva al negocio.
SOA es una iniciativa de negocio guiada por el departamento de tecnología de información, que transforma la manera como la información se hace disponible, que permite que el area de tecnología de información ya no sea de apoyo, si no que se convierta en sustantiva.
Es dificil para alguien que ha tenido una preparación de ingeniera de sistemas, llegar a estas conclusiones.
Normalmente nos acostumbramos a resolver problemas técnicos, de hecho a veces perdemos el foco y hacemos soluciones técnicamente complejas. Pero en algunos casos, ni sabemos que problema del negocio estamos solucionando o cuanto es el impacto (y tambien cuando falla el asunto, no somos capaces de medir).
En cambio, enfocado a servicios, el desarrollador de soluciones sabe claramente la contribución al negocio.
Asi que, dudo que SOA sea un fracaso. El reto es cambiar la manera de pensar de la gente de sistemas y de los usuarios, en los cuales ya se deje de ver la tecnología de información como algo opcional.
Algunos ya dicen que SOA está desapareciendo, que ha sido un fracaso.
La verdad, creo que mucho de lo que ha pasado es que la industria ha visto el implementar SOA como comprar e instalar productos, o como una iniciativa de Tecnologia de Informacion, o por construir WebServices se dicen SOA.
Eso lleva a que al final, para la organización no hay mucho cambio con respecto a la manera como la tecnología de información se implanta.
Es típico, que en cualquier organización, primero se empieza a diseñar un servicio con procesos manuales. Una vez que se empieza a operar dicho proceso, se dan cuenta que tienen muchas labores dignas de automatizar, y van y solicitan a sistemas, una nueva aplicación.
Y por desgracia, cuando llega al área de sistemas, se enfoca a que dicha aplicacion solucione para ese proceso, sin tomar en cuenta todo el contexto de la organización. Y luego cuando se dan cuenta los de sistemas, a jalar copias de base de datos de otras aplicaciones, a intercambiarse archivos planos, interfaces punto a punto y dependencias altas entre las aplicaciones.
Y mientras, la organización perdiendo oportunidades de oro, teniendo escenarios donde por falta de una integración entre sus sistemas, se tardan un largo tiempo en obtener resultados.
He ahi la importancia de una arquitectura comun para las soluciones de tecnologia de información. El chiste de la arquitectura es poner orden, organizar.
Ahora, si dicha orientación se da, pensando que se construyen servicios que permiten automatizar las actividades de los procesos, entonces lo que se puede provocar es que la tecnología se vaya constituyendo a través de servicios de negocio.
El camino que deriva la creación de un servicio debe ser asi:
* Estrategia de negocio u organización. Define los objetivos a alcanzar.
* Servicios de negocio. Manera como la organización entrega un bien o servicio a sus clientes,empleados y/o proveedores.
* Capacidades de Arquitectura Empresarial. Las funcionalidades de tecnología.
* Plataforma de Tecnología de Información. Componentes de software y hardware.
Es decir, cualquier servicio, se origina por alguna necesidad de negocio y tiene como vista, compartir y reutilizar información.
Pero las personas que estan en la organización, en lugar de concebir la automatización de sus procesos a través de aplicaciones, lo hacen a través de servicios.
Pero a ellos no les debe importar si esta en un sistema UNIX con Oracle y Java, o si está en Windows con SQL Server y C#. Lo que debe importar es la información que ofrece y las operaciones de negocio que realiza.
En resumen, SOA no es algo nuevo. Es lo que siempre se ha buscado como, lograr que la tecnología de información sirva al negocio.
SOA es una iniciativa de negocio guiada por el departamento de tecnología de información, que transforma la manera como la información se hace disponible, que permite que el area de tecnología de información ya no sea de apoyo, si no que se convierta en sustantiva.
Es dificil para alguien que ha tenido una preparación de ingeniera de sistemas, llegar a estas conclusiones.
Normalmente nos acostumbramos a resolver problemas técnicos, de hecho a veces perdemos el foco y hacemos soluciones técnicamente complejas. Pero en algunos casos, ni sabemos que problema del negocio estamos solucionando o cuanto es el impacto (y tambien cuando falla el asunto, no somos capaces de medir).
En cambio, enfocado a servicios, el desarrollador de soluciones sabe claramente la contribución al negocio.
Asi que, dudo que SOA sea un fracaso. El reto es cambiar la manera de pensar de la gente de sistemas y de los usuarios, en los cuales ya se deje de ver la tecnología de información como algo opcional.
sábado 3 de enero de 2009
Bolero de Ravel y Arquitectura Orientada a Servicios
Desde hace un rato se me habia ocurrido esta idea, en un concierto donde tocaron el Bolero de Maurice Ravel.
Todo la obra esta llevada por un solo patron musical, sin embargo es interesante notar como los distintos instrumentos de la orquesta lo interpretan.
Y al final, gracias al poderoso concepto de la armonia (lo que para los nosotros los de software es el equivalente de arquitectura) se puede hacer que toda la orquesta utilice el mismo tema y de un efecto total.
Y de ahi es donde empieza la analogia.
Si el patron musical se toma como analogia de un servicio, en el cual, sea cual sea el rol del componente de software, se debe de hablar de una manera estandar y comun.
Para poner el patron comun, se pone un canal de integracion (el service bus) que es responsable de recibir, procesar y transformar mensajes. Si se le dice a todos los demas componentes de software como usar a dicho canal de integracion (ejecutar el patron musical), se puede empezar con la ejecucion.
Entonces llega una aplicacion Java y toma el patron como modelo. Si quiere informacion debe publicar un mensaje a un canal de integracion. Y la aplicacion Java, para dar informacion a otros, debe publicarse como servicio al canal de integracion, ya sea utilizando JMS o SOAP, de manera sincrona o asincrona.
Y por otro lado, llega un sistema de base de datos, el cual puede exponer sus registros como servicios, e intercambiarlos como XML, los cuales deja disponible via el canal de servicios, de nuevo utilizando SOAP.
Y de repente se une un sistema ERP o un CRM. Aunque dichos sistemas ya estan hechos, tambien necesitan informacion y compartir informacion con otras aplicaciones. Cada vez que realizan una actividad, reportan al canal de integracion, un evento de negocio. Dan de alta a un cliente, a enviar un mensaje al canal. Que en una aplicacion se refleja un movimiento de dinero, el ERP recibe un evento de negocio.
Y entonces, es posible combinar las aplicaciones Java, las bases de datos, el ERP y el CRM. Y entonces llega los servicios compuestos a la arquitectura, que ensamblan a todos los componentes entre si y utilizan al canal de integracion para orquestar, transformar y comunicar a todos los servicios nucleo entre si.
Y muchos de esos servicios compuestos, representan los servicios que da una empresa, o servicios de negocio. Cada servicio de negocio es una actividad de un proceso. El proceso necesita ejecutar actividades, tomar informacion de donde necesite. Entonces se incorpora a la arquitectura el administrador de procesos de negocio, que permite concebir todas las actividades de la empresa como procesos. Se pueden medir, se pueden simular, se pueden mejorar. Y sigue hablando el mismo patron, enviar mensajes al canal de integracion, utilizar protocolos comunes. El proceso toma informacion de los clientes, refleja operaciones en finanzas, toma decisiones del sistema de recursos humanos, crea nueva informacion.
Y entonces, cada servicio compuesto, se expone como una interface de usuario a un portal. En el portal los usuarios pueden acceder a toda la informacion que quieren, hablando con los servicios, siguiendo el mismo ritmo que los anteriores componentes.
Y eso permite que los usuarios del portal tengan voz propia, que usen la informacion para mejorar su trabajo, que pueden ensamblar su informacion. Y tienen agilidad para cambiar su trabajo.
Y asi se logra la federacion de todo el software de una organizacion!! Todos hablando de la misma manera, organizados para un fin comun, de acuerdo a la arquitectura empresarial y ayudando a iniciar el cambio en una organizacion muy grande pero que le da la oportunidad de decir: !Puedo cambiar!
Los dejo con un video con la version abreviada del Bolero de Ravel, pero bastante bien interpretado, y con voces humanas
Todo la obra esta llevada por un solo patron musical, sin embargo es interesante notar como los distintos instrumentos de la orquesta lo interpretan.
Y al final, gracias al poderoso concepto de la armonia (lo que para los nosotros los de software es el equivalente de arquitectura) se puede hacer que toda la orquesta utilice el mismo tema y de un efecto total.
Y de ahi es donde empieza la analogia.
Si el patron musical se toma como analogia de un servicio, en el cual, sea cual sea el rol del componente de software, se debe de hablar de una manera estandar y comun.
Para poner el patron comun, se pone un canal de integracion (el service bus) que es responsable de recibir, procesar y transformar mensajes. Si se le dice a todos los demas componentes de software como usar a dicho canal de integracion (ejecutar el patron musical), se puede empezar con la ejecucion.
Entonces llega una aplicacion Java y toma el patron como modelo. Si quiere informacion debe publicar un mensaje a un canal de integracion. Y la aplicacion Java, para dar informacion a otros, debe publicarse como servicio al canal de integracion, ya sea utilizando JMS o SOAP, de manera sincrona o asincrona.
Y por otro lado, llega un sistema de base de datos, el cual puede exponer sus registros como servicios, e intercambiarlos como XML, los cuales deja disponible via el canal de servicios, de nuevo utilizando SOAP.
Y de repente se une un sistema ERP o un CRM. Aunque dichos sistemas ya estan hechos, tambien necesitan informacion y compartir informacion con otras aplicaciones. Cada vez que realizan una actividad, reportan al canal de integracion, un evento de negocio. Dan de alta a un cliente, a enviar un mensaje al canal. Que en una aplicacion se refleja un movimiento de dinero, el ERP recibe un evento de negocio.
Y entonces, es posible combinar las aplicaciones Java, las bases de datos, el ERP y el CRM. Y entonces llega los servicios compuestos a la arquitectura, que ensamblan a todos los componentes entre si y utilizan al canal de integracion para orquestar, transformar y comunicar a todos los servicios nucleo entre si.
Y muchos de esos servicios compuestos, representan los servicios que da una empresa, o servicios de negocio. Cada servicio de negocio es una actividad de un proceso. El proceso necesita ejecutar actividades, tomar informacion de donde necesite. Entonces se incorpora a la arquitectura el administrador de procesos de negocio, que permite concebir todas las actividades de la empresa como procesos. Se pueden medir, se pueden simular, se pueden mejorar. Y sigue hablando el mismo patron, enviar mensajes al canal de integracion, utilizar protocolos comunes. El proceso toma informacion de los clientes, refleja operaciones en finanzas, toma decisiones del sistema de recursos humanos, crea nueva informacion.
Y entonces, cada servicio compuesto, se expone como una interface de usuario a un portal. En el portal los usuarios pueden acceder a toda la informacion que quieren, hablando con los servicios, siguiendo el mismo ritmo que los anteriores componentes.
Y eso permite que los usuarios del portal tengan voz propia, que usen la informacion para mejorar su trabajo, que pueden ensamblar su informacion. Y tienen agilidad para cambiar su trabajo.
Y asi se logra la federacion de todo el software de una organizacion!! Todos hablando de la misma manera, organizados para un fin comun, de acuerdo a la arquitectura empresarial y ayudando a iniciar el cambio en una organizacion muy grande pero que le da la oportunidad de decir: !Puedo cambiar!
Los dejo con un video con la version abreviada del Bolero de Ravel, pero bastante bien interpretado, y con voces humanas
domingo 16 de noviembre de 2008
Mashups o Web como servicio
Explicando brevemente un concepto que se ha manejado ultimamente, mashups (asociado con Web 2.0)
Un mashup es un componente web (que a la vezpuede ser consumido como un webservice tipo SOAP o REST) y que integra informacion de distintas fuentes de informacion.
Es decir, un mashup permite consumir informacion de una pagina Web o un WebService o de servicios como Google Maps, Blogger, Flicker o del.icio.us.
Resuelve problemas en los cuales, si es necesario consumir datos de una aplicacion Web, basada en HTML, permite capturar la informacion que se tiene en una pagina.
El concepto es muy interesante y poderoso, ya que es un mecanismo que permite exponer paginas Web como servicios.
Les recomiendo visiten la documentacion del proyecto WSO2 server mashup.
Otro ejemplo, pero no tan accesible para probar (es decir, algun gerente de ventas te estara cuestionando para que usar el software antes de dartelo) es el de la empresa JackBe , con su tecnologia Presto
Cierro este comentario, dejando que mediten las posibilidades de integrar a las aplicaciones informacion que vienen de Internet.
Un mashup es un componente web (que a la vezpuede ser consumido como un webservice tipo SOAP o REST) y que integra informacion de distintas fuentes de informacion.
Es decir, un mashup permite consumir informacion de una pagina Web o un WebService o de servicios como Google Maps, Blogger, Flicker o del.icio.us.
Resuelve problemas en los cuales, si es necesario consumir datos de una aplicacion Web, basada en HTML, permite capturar la informacion que se tiene en una pagina.
El concepto es muy interesante y poderoso, ya que es un mecanismo que permite exponer paginas Web como servicios.
Les recomiendo visiten la documentacion del proyecto WSO2 server mashup.
Otro ejemplo, pero no tan accesible para probar (es decir, algun gerente de ventas te estara cuestionando para que usar el software antes de dartelo) es el de la empresa JackBe , con su tecnologia Presto
Cierro este comentario, dejando que mediten las posibilidades de integrar a las aplicaciones informacion que vienen de Internet.
domingo 28 de septiembre de 2008
Web Services con Mule CXF y Spring
Hola que tal
Despues de un rico desayuno en un agradable domingo en casa de mis padres, saque del polvo mi cuenta de integracion y pues aqui estamos; Antes de entrar en materia he de comentarles que han pasado muchas cosas interesantes en el trabajo, una que me tiene muy entusiasmado es el proyecto de SOA, mas alla del nombre, es interesante ver como gran parte de la comunidad de sistemas tiene su propia definion de SOA lo entendemos de diferentes maneras (no quiero pensar en la gente que es de negocio).. es un reto interesante en lo personal ya que se derivan muchas cosas desde la parte tecnica como la parte de venta la parte de convencer todo lo que vamos a estar haciend... en fin. Estuve leyendo el ultimo post de gustavo y comparto la opinion acerca de nuestros hermanos de la india, asi como en mexico, en la india hay gente muy trabajadora, muy comprometida y sobretodo sencilla, ya les contare mas detalle lo que estamos haciendo por aca en el trabajo.
Bien pues despues de lo anterior..... el post de hoy habla de de como combinar Spring, CXF y MULE, para generar y exponer servicios web usando el ESB Mule.
Bien, en muchas ocasiones me ha tocado ver como compañeros del trabajo les encargan generar un servicio web que exponga funcionalidad de negocio y me sorprende ver como tardan mas en generar todo la talacha que implica el exponer el servicio, que en lo que generan sus servicios de negocio.... creo que todo lo anterior tiene una explicacion, no estamos acostumbrados a trabajar con frameworks. Hoy en dia existen framworks como spring que como dicen en muchas paginas "hace la plomeria el plumbing", este tipo de marcos de trabajo nos permiten concentrarnos en generar nunestros componentes de negocio. En el siguiente ejemplo vamos a ver como exponemos un POJO como servicio web.
Bien los ingredientes son:
El codigo como sigue
public interface ICalculadora {
public float suma(float a, float b);
public float resta(float a, float b);
public float division(float a, float b);
public float multiplicacion(float a, float b);
}
y la implementacion
public class CalculadoraImpl implements ICalculadora {
public float division(float a, float b) {
if (b==0) return -1;
else return a/b;
}
public float multiplicacion(float a, float b) { return a*b;}
public float resta(float a, float b) { return a-b; }
public float suma(float a, float b) { return a+b; }
}
woow!!!, ahora bien si este pojo lo queremos usar con spring lo unico que necesitamos haces es su archivo de configuracion el application context:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="calculadora"
class="ejercicio.CalculadoraImpl"
scope="singleton">
</bean>
</beans>
Ahora bien... hasta aqui nada nuevo... para los que han manejado spring no tiene nada de complicado lo anterior. Bien, pues vamos a hacer la pregunta que generalmente se coloca en el google "How do I expose my POJO as a webservice in Mule?", hay varios caminos... uno de ellos es usando CXF de apache para lo cual debemos de colocar una serie de anotaciones en nuestra clase y nuestra interfaz... veamos:
import javax.jws.WebResult;
import javax.jws.WebService;
@WebService
public interface ICalculadora {
@WebResult(name="suma")
public float suma(float a, float b);
@WebResult(name="resta")
public float resta(float a, float b);
@WebResult(name="division")
public float division(float a, float b);
@WebResult(name="multiplicacion")
public float multiplicacion(float a, float b);
}
y para la implementacion:
import javax.jws.WebService;
@WebService(endpointInterface = "ejercicio.ICalculadora",
serviceName = "Calculadora")
public class CalculadoraImpl implements ICalculadora {
public float division(float a, float b) {
if (b==0) return -1;
else return a/b;
}
public float multiplicacion(float a, float b) {
return a*b;
}
public float resta(float a, float b) {
return a-b;
}
public float suma(float a, float b) {
return a+b;
}
}
Las anotaciones usadas @WebService indican que la clase es un servicio web y @WebResult los valores a recibir. Estas anotaciones serviran para que CXF y Mule compongan el WSDL que describira nuestro servicio.
Una vez colocadas las anotaciones lo que sigue es generar nuestro archivo de configuracion de Mule mule-config.xml tal y como sigue:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:soap="http://www.mulesource.org/schema/mule/soap/2.0"
xmlns:cxf="http://www.mulesource.org/schema/mule/cxf/2.0"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
http://www.mulesource.org/schema/mule/soap/2.0 http://www.mulesource.org/schema/mule/soap/2.0/mule-soap.xsd
http://www.mulesource.org/schema/mule/cxf/2.0 http://www.mulesource.org/schema/mule/cxf/2.0/mule-cxf.xsd">
<spring:beans>
<spring:import resource="springContext.xml"/>
</spring:beans>
<model name="servicescalculadora">
<service name="Calculadora">
<inbound>
<cxf:inbound-endpoint address="http://localhost:65082/services/Calculadora" />
</inbound>
<component>
<spring-object bean="calculadora" />
</component>
</service>
</model>
</mule>
Bien pues ya tenemos todos los componentes, ahora vamos a ejecutar nuestro archivo de configuracion de mule, si lo hacen si el ide consideren todas las dependencias para que el poryecto compile:
MULE_HOME\mule -config mule-config.xml
Se ejecuta el servidor de mule al finalizar debemos de ver algo como lo siguiente:
INFO: Setting the server's publish address to be http://localhost:65082/services/Calculadora
Bien, pues listo! ya estsmos en posibilidades de ver el WSDL
http://localhost:65082/services/Calculadora?WSDL
Ahora solo es cuestion de ejecutar pruebas con nuestro servicio web, en lo personal yo uso SOAP UI, pero pues lo pueden hacer con cualquier herramienta que pueda mandar peticiones hacia sua servicios web.
Bueno pues es todo, esperemos que les sirva, quejas y sugerencias seran bien recibidas.
Por una integracion mejor, hasta la vista!!
Tuzo
Despues de un rico desayuno en un agradable domingo en casa de mis padres, saque del polvo mi cuenta de integracion y pues aqui estamos; Antes de entrar en materia he de comentarles que han pasado muchas cosas interesantes en el trabajo, una que me tiene muy entusiasmado es el proyecto de SOA, mas alla del nombre, es interesante ver como gran parte de la comunidad de sistemas tiene su propia definion de SOA lo entendemos de diferentes maneras (no quiero pensar en la gente que es de negocio).. es un reto interesante en lo personal ya que se derivan muchas cosas desde la parte tecnica como la parte de venta la parte de convencer todo lo que vamos a estar haciend... en fin. Estuve leyendo el ultimo post de gustavo y comparto la opinion acerca de nuestros hermanos de la india, asi como en mexico, en la india hay gente muy trabajadora, muy comprometida y sobretodo sencilla, ya les contare mas detalle lo que estamos haciendo por aca en el trabajo.
Bien pues despues de lo anterior..... el post de hoy habla de de como combinar Spring, CXF y MULE, para generar y exponer servicios web usando el ESB Mule.
Bien, en muchas ocasiones me ha tocado ver como compañeros del trabajo les encargan generar un servicio web que exponga funcionalidad de negocio y me sorprende ver como tardan mas en generar todo la talacha que implica el exponer el servicio, que en lo que generan sus servicios de negocio.... creo que todo lo anterior tiene una explicacion, no estamos acostumbrados a trabajar con frameworks. Hoy en dia existen framworks como spring que como dicen en muchas paginas "hace la plomeria el plumbing", este tipo de marcos de trabajo nos permiten concentrarnos en generar nunestros componentes de negocio. En el siguiente ejemplo vamos a ver como exponemos un POJO como servicio web.
Bien los ingredientes son:
- La distribucion de Mule (que esta basada en spring)
- Si gustan usamos Eclipse Mule IDE
El codigo como sigue
public interface ICalculadora {
public float suma(float a, float b);
public float resta(float a, float b);
public float division(float a, float b);
public float multiplicacion(float a, float b);
}
y la implementacion
public class CalculadoraImpl implements ICalculadora {
public float division(float a, float b) {
if (b==0) return -1;
else return a/b;
}
public float multiplicacion(float a, float b) { return a*b;}
public float resta(float a, float b) { return a-b; }
public float suma(float a, float b) { return a+b; }
}
woow!!!, ahora bien si este pojo lo queremos usar con spring lo unico que necesitamos haces es su archivo de configuracion el application context:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="calculadora"
class="ejercicio.CalculadoraImpl"
scope="singleton">
</bean>
</beans>
Ahora bien... hasta aqui nada nuevo... para los que han manejado spring no tiene nada de complicado lo anterior. Bien, pues vamos a hacer la pregunta que generalmente se coloca en el google "How do I expose my POJO as a webservice in Mule?", hay varios caminos... uno de ellos es usando CXF de apache para lo cual debemos de colocar una serie de anotaciones en nuestra clase y nuestra interfaz... veamos:
import javax.jws.WebResult;
import javax.jws.WebService;
@WebService
public interface ICalculadora {
@WebResult(name="suma")
public float suma(float a, float b);
@WebResult(name="resta")
public float resta(float a, float b);
@WebResult(name="division")
public float division(float a, float b);
@WebResult(name="multiplicacion")
public float multiplicacion(float a, float b);
}
y para la implementacion:
import javax.jws.WebService;
@WebService(endpointInterface = "ejercicio.ICalculadora",
serviceName = "Calculadora")
public class CalculadoraImpl implements ICalculadora {
public float division(float a, float b) {
if (b==0) return -1;
else return a/b;
}
public float multiplicacion(float a, float b) {
return a*b;
}
public float resta(float a, float b) {
return a-b;
}
public float suma(float a, float b) {
return a+b;
}
}
Las anotaciones usadas @WebService indican que la clase es un servicio web y @WebResult los valores a recibir. Estas anotaciones serviran para que CXF y Mule compongan el WSDL que describira nuestro servicio.
Una vez colocadas las anotaciones lo que sigue es generar nuestro archivo de configuracion de Mule mule-config.xml tal y como sigue:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:soap="http://www.mulesource.org/schema/mule/soap/2.0"
xmlns:cxf="http://www.mulesource.org/schema/mule/cxf/2.0"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
http://www.mulesource.org/schema/mule/soap/2.0 http://www.mulesource.org/schema/mule/soap/2.0/mule-soap.xsd
http://www.mulesource.org/schema/mule/cxf/2.0 http://www.mulesource.org/schema/mule/cxf/2.0/mule-cxf.xsd">
<spring:beans>
<spring:import resource="springContext.xml"/>
</spring:beans>
<model name="servicescalculadora">
<service name="Calculadora">
<inbound>
<cxf:inbound-endpoint address="http://localhost:65082/services/Calculadora" />
</inbound>
<component>
<spring-object bean="calculadora" />
</component>
</service>
</model>
</mule>
Bien pues ya tenemos todos los componentes, ahora vamos a ejecutar nuestro archivo de configuracion de mule, si lo hacen si el ide consideren todas las dependencias para que el poryecto compile:
MULE_HOME\mule -config mule-config.xml
Se ejecuta el servidor de mule al finalizar debemos de ver algo como lo siguiente:
INFO: Setting the server's publish address to be http://localhost:65082/services/Calculadora
Bien, pues listo! ya estsmos en posibilidades de ver el WSDL
http://localhost:65082/services/Calculadora?WSDL
Ahora solo es cuestion de ejecutar pruebas con nuestro servicio web, en lo personal yo uso SOAP UI, pero pues lo pueden hacer con cualquier herramienta que pueda mandar peticiones hacia sua servicios web.
Bueno pues es todo, esperemos que les sirva, quejas y sugerencias seran bien recibidas.
Por una integracion mejor, hasta la vista!!
Tuzo
Suscribirse a:
Entradas (Atom)
