Mostrando entradas con la etiqueta Web Services. Mostrar todas las entradas
Mostrando entradas con la etiqueta Web Services. Mostrar todas las entradas

viernes, 31 de mayo de 2013

Introducción a los servicios web

La primera vez que un programador se enfrenta a la tarea de tener que realizar un servicio web (en adelante WS, Web Service) se suele encontrar un poco perdido. Normalmente se recurre a internet o a algún libro especializado. El problema es que son tantas las tecnologías con las que se puede desarrollar un WS, y son tantos los tipos de WS que existen, protocolos y demás, que a no ser que alguien ayude pueden pasar horas hasta que el programador obtenga el resultado deseado.

En mi caso he desarrollado muchos WS en distintos lenguajes como java, python y php; y distintas tecnologías, como XMLRPC, SOAP, MAVEN, AXIS, AXIS2… y os comento que me he encontrado con muchos problemas, siendo algunos de ellos de solución muy compleja.

Desde hace un tiempo sigo mi propia metodología para realizar WS. En realidad lo que os voy a contar no es de mi propia cosecha, sino que fue una gran aportación de un amigo (JT). Evidentemente yo hice mis cambios y lo adapté a mi forma de trabajar, pero sirvan estos posts como agradecimiento.

Durante cuatro posts, este inclusive, voy a contar lo que es un WS. No voy a hacer como muchos libros que profundizan tanto en los detalles que no se sabe por donde cogerlos, sino que voy a ir al grano. La estructura a seguir será la siguiente:

  • En este primer post, daré una explicación light de lo que es un WS y comentaré el ejemplo que realizaré.
  • En el segundo post programaré una aplicación “productor”.
  • El tercer post será un ejemplo de manejo de la interfaz de eclipse para obtener datos del “productor”.
  • El cuarto y último post lo usaré para crear un “cliente” y una aplicación que use dicho “cliente”.

Así pues, que comience el espectáculo:

¿Qué es un Web Service?

Para responder a esta pregunta, me remito a la descripción dada en la Wikipedia: Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.

¿Y esto que significa?

Imaginemos la siguiente situación: Tenemos una aplicación (llamada A) que almacena datos de películas. Dicha aplicación sólo está accesible vía web, y queremos que otra aplicación distinta (llamémosla B) muestre los datos de la aplicación A. En este ejemplo la aplicación A se llama productor, ya que produce los datos, y la aplicación B se llama consumidor o cliente.

Para que la aplicación A pueda compartir los datos, es necesario que publique un archivo de descripción del servicio. Dicho archivo debe estar bien formado y contiene una descripción de los métodos que acepta el WS, y de los datos que utiliza tanto si son de llamada como de retorno. Además si dichos datos son clases propias de la aplicación, también deben estar descritas en el archivo. A dicho archivo se le denomina WSDL (Web Services Description Language). En realidad esto es una verdad a medias, puesto que los tipos de datos no son necesarios que estén. Lo que pasa es que si el WSDL está completo el cliente se puede generar de forma automática, ya sea con maven, con eclipse o con cualquier otra aplicación que lo permita. Si no lo estuviera es requisito indispensable que el programador que va a realizar el cliente conozca a la perfección los tipos de datos, etc.

Como podéis imaginar realizar este archivo a mano resulta una tarea tediosa, ya que cualquier error en el mismo hace que no funcione, y para colmo estos errores son difíciles de localizar. Ahora pensad, si hacer un simple xsd es complicado, imaginad un super xsd, es decir, un WSDL.

Sigamos con la teoría. Tenemos una aplicación productora que además de producir datos, publica un archivo que describe que operaciones se pueden realizar con ella. Pues lo que nos quedaría sería leer dicho archivo, y generar una aplicación que sea capaz de usar los métodos y los datos definidos en el WSDL. La aplicación productora a su vez publica una url a la que conectaremos el cliente, y así las dos aplicaciones se comunicarán y pasarán información entre ellas.


Diagrama de funcionamiento de un WS

En resumen:

El productor publica un archivo WSDL que describe como interactuar con él, y además dispone de una url para poder realizar dicha interacción.

El cliente interactúa con el productor y muestra los datos en su aplicación. El WSDL sirve para generar las clases y llamadas a métodos que usará el cliente.

En el próximo post realizaremos una aplicación que será el productor del WS.

Saludos.

lunes, 10 de diciembre de 2012

Problemas con WSGEN. Métodos duplicados en el wsdl

Hoy al generar un ws con wsgen, el wsdl me ha dado el warning:

cvc-identity-constraint.4.2.2: Duplicate key value [getCuentas] declared for identity constraint "message" of element 
 "definitions".

Lo que pasaba es que en el archivo wsdl, uno de los métodos me aparecía duplicado. Este problema estaba causado porque había definido la interfaz en la forma:

 @WebService(targetNamespace = "http://xxx.xxx.com", name = "XxxxWSInterface")
@SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL)
public interface BcieWSInterface {

Casualmente me fijé que el método que salía por duplicado era el que devolvía Tipo_dato. En realidad no sé porqué estaba ese tipo declarado en la interfaz, creo que dejé a eclipse arreglar algo y me lo añadió.

Al arreglar la interfaz y dejarla sin el Tipo_dato

 @WebService(targetNamespace = "http://xxx.xxx.com", name = "XxxxWSInterface")
@SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL)
public interface BcieWSInterface {

y volver a generar se creó el wsdl correctamente :D En fin, una cagada mia, que menos mal que resolví en poco tiempo.

Saludos

sábado, 17 de noviembre de 2012

CProject. Gestor de proyectos en Android

Desde hace tiempo estoy buscando un gestor de proyectos en android que cumpla con mis necesidades, pero no encuentro ninguno. Así que hace 4 días me pregunté: ¿y si retomo mi proyecto de sincronización de tareas Android-OpenERP y le doy un lavado de cara?. Dicho y hecho. En 4 días, con sus noches, he realizado un pequeño proyectito.

CProject - Créditos del proyecto.

Aún le queda mucho por mejorar. Por ahora sólo se pueden crear proyectos nuevos, tareas en dichos proyectos, y salvar toda la información en SQLite en el propio dispositivo. Por supuesto también se pueden migrar los proyectos a OpenERP mediante Web-Services.
CProject - Action bar con botón que ejecuta Web Service para migrar datos a OpenERP.

En mi lista de TODOs para el proyecto tengo en mente mejorar e implementar una serie de cosas, como por ejemplo que se pinte el diagrama de Gantt, asignar etiquetas a los proyectos, estadísticas, popups para introducir fechas, etc.

CProject - Pantalla de introducción de nombre de proyecto.

En sucesivos post iré comentando el estado del proyecto, he incluso cuando termine algunas características más grabaré algún vídeo para subirlo al blog.
Por último, si alguien está interesado en el proyecto, o desea que implemente alguna característica especial, o simplemente quiere colaborar, que contacte conmigo.
Saludos.
Related Posts Plugin for WordPress, Blogger...