Nada que decir, hoy exponemos. Tan tan!
Para no terminar mi aporte de forma tan abrupta les cuento que la exposicion basicamente tendra 3 partes bien definidas: Introduccion, WS-I (Basic Profile) & Proyecto Tango, y finalmente un par de ejemplos.
Saludos,
Jose
martes, 21 de octubre de 2008
lunes, 20 de octubre de 2008
Ruby-RoR-Ws
Un resumen bastante bueno para comprender tanto Ruby, como Rails y WS en RoR lo encontramos en:
http://maximilien.org/tutorials/2007/ws_on_rails/Web_Services_on_Rails.ppt
Para el desarrollo en Rails es muy importante el modelo MVC pues dependiendo de la funcionalidad de las clases así serán ubucadas en carpetas. Acordemonos que Rails trabaja bajo el concepto de "Convention over configuration".
a) Para el acceso a BB contamos con ActiveRecords = Object relational mappings
b) Podemos definir un controller de la forma
class ConferenceController < ApplicationController
def index
render_text “Welcome to ConfApp”
end
def list
@conference_page, @conferences = paginate :conferences, :per_page => 10
end
def new
@conference = Conference.new
end
def show
@conference = Conference.find params[:id]
end
#...
end
c) Las vistas se desarrollan con archivos .rhtml que son similares a los jsp y asps. Cada controlador tiene una carpeta para sus vistas.
d) Action Web Services nos proporciona Server-side support para SOAP y XML-RPC Web services. Soporta WSDL (no en su totalidad)
http://maximilien.org/tutorials/2007/ws_on_rails/Web_Services_on_Rails.ppt
Para el desarrollo en Rails es muy importante el modelo MVC pues dependiendo de la funcionalidad de las clases así serán ubucadas en carpetas. Acordemonos que Rails trabaja bajo el concepto de "Convention over configuration".
a) Para el acceso a BB contamos con ActiveRecords = Object relational mappings
b) Podemos definir un controller de la forma
class ConferenceController < ApplicationController
def index
render_text “Welcome to ConfApp”
end
def list
@conference_page, @conferences = paginate :conferences, :per_page => 10
end
def new
@conference = Conference.new
end
def show
@conference = Conference.find params[:id]
end
#...
end
c) Las vistas se desarrollan con archivos .rhtml que son similares a los jsp y asps. Cada controlador tiene una carpeta para sus vistas.
d) Action Web Services nos proporciona Server-side support para SOAP y XML-RPC Web services. Soporta WSDL (no en su totalidad)
Aplicacion para prueba de webservices
Como parte de la exposicion de dispositivos moviles, se implementara el tipico webservice de Calculadora (que se usa como ejemplo muy comunmente).
Para consumir este servicio se utilizara el API de J2ME soportado por el dispositivo, que incluye una version reducida de jax-rpc. Las pruebas, dado que no tenemos un dispositivo blackberry real, se haran con emulador.
De ser posible, dado que el servicio es en realidad sencillo, puede explorarse la posibilidad de hacer el mismo cliente pero para palm (con el api de .net), o, por que no, con un gateway sms... en este ultimo (y remoto caso), se probaria con un emulador de sms propiamente (logica smpp)
Para consumir este servicio se utilizara el API de J2ME soportado por el dispositivo, que incluye una version reducida de jax-rpc. Las pruebas, dado que no tenemos un dispositivo blackberry real, se haran con emulador.
De ser posible, dado que el servicio es en realidad sencillo, puede explorarse la posibilidad de hacer el mismo cliente pero para palm (con el api de .net), o, por que no, con un gateway sms... en este ultimo (y remoto caso), se probaria con un emulador de sms propiamente (logica smpp)
Exposición Web Services con Adjuntos
Dentro de la agenda de exposición como comenta Jeffry hablaremos de MTOM, pero primero hablaremos de la implementación con DIME, en el lado de .NET utilizaremos Visual studio 2003 o 2005 con WSE 2.0, tanto para el server como para el cliente, luego desmostraremos la interoperatividad con Java en Axis (y al igual que en .Net haremos un servidor y un cliente).
Una vez hecho esto migraremos el código con WSE 2.0 a WSE 3.0 usando Visual Studio 2005, con el objetivo de use MTOM y probaremos su funcionabilidad. Una vez hecho probaremos la interoperatividad que como lo comenta Jeffry se ha tenido problemas.
Para el momento de la exposición ya tendremos un mayor avance.
Allan
Una vez hecho esto migraremos el código con WSE 2.0 a WSE 3.0 usando Visual Studio 2005, con el objetivo de use MTOM y probaremos su funcionabilidad. Una vez hecho probaremos la interoperatividad que como lo comenta Jeffry se ha tenido problemas.
Para el momento de la exposición ya tendremos un mayor avance.
Allan
miércoles, 15 de octubre de 2008
Interoperabilidad
Cuando se habla de interoperabilidad en servicios web, se tiene el concepto de que la simple tarea de poder comunicar dos tecnologías como .Net y Java es suficiente para que haya interoperabilidad entre las partes. Sin embargo muchas de las características más importantes para el cliente no se cumplen.
El proyecto Tango es una iniciativa de Sun para crear Interoperabilidad entre Java y .Net, y se ha utilizado Windows Comunication Foundation, para interactuar con los servicios web en la plataforma de .Net 3.0.
El proyecto Tango enfatiza su trabajo en tres aspectos de suma importancia para el uso de servicios web. Estas tres tecnologías son: Seguridad, Confiabilidad y Transacciones.
El motivo principal de la creación del proyecto Tango se divide en dos puntos muy precisos, los cuales son:
· Una implementación de las especificaciones clave de los servicios web (WS-*). http://wsit.dev.java.net/specification-links.html
· Interoperabilidad con el framework 3.0 de .NET.
El proyecto Tango es una iniciativa de Sun para crear Interoperabilidad entre Java y .Net, y se ha utilizado Windows Comunication Foundation, para interactuar con los servicios web en la plataforma de .Net 3.0.
El proyecto Tango enfatiza su trabajo en tres aspectos de suma importancia para el uso de servicios web. Estas tres tecnologías son: Seguridad, Confiabilidad y Transacciones.
El motivo principal de la creación del proyecto Tango se divide en dos puntos muy precisos, los cuales son:
· Una implementación de las especificaciones clave de los servicios web (WS-*). http://wsit.dev.java.net/specification-links.html
· Interoperabilidad con el framework 3.0 de .NET.
martes, 14 de octubre de 2008
WS-I Testing Tools V1.1
Ya en posts anteriores he hecho referencia a la organización WS-I y sus herramientas de verificación de interoperabilidad http://www.ws-i.org/. En resumen, tenemos que los autores del WS-I Basic Profile querían proporcionar una manera sencilla de asegurar la compatibilidad con esta especificación. Así es como crearon un conjunto de herramientas para que los desarrolladores puedan verificar que los artefactos generados fueran conformes al Basic Profile.
Este conjunto de herramientas está conformado por:
- Monitor: intercepta mensajes hacia y desde un servicio Web
- Analizer: inspecciona varios artefactos de servicios Web (incluyendo los mensajes interceptados por la herramienta Monitor)
Es importante mencionar que existen implementaciónes en Java y C# y, como parte de nuestra exposición, nos gustaría mostrar la forma de incorporar y utilizar estas herramientas en nuestros proyectos.
Por ejemplo, a continuación se muestran los pasos para la utilización de la implementación C#.
En primer lugar, descargaremos las herramientas "Interoperability Testing Tools V1.1" de la página del WS-I. En la carpeta "common/profiles" se encuentran los archivos correspondientes para cada perfil. Nosotros vamos a usar el fichero "BasicProfileTestAssertions.xml" para comprobar que cumplimos con el perfil básico.
En la carpeta "cs/bin", editamos el archivo "monitorConfig.xml" para configurar la herramienta de monitorización:
- Con la etiqueta indicamos el puerto en el que la herramienta escuchará las peticiones al servicio web que vamos a comprobar.
- Con la etiqueta indicamos el host y puerto real del servicio web.
Los demás valores podemos dejarlos tal y como vienen por defecto. De esa forma, la herramienta reenviará todos los mensajes recibidos en el puerto indicado en listenPort al host y puerto indicados en schemeAndHostPort y guardará todos estos mensajes en un fichero "tracelog.xml" que usaremos más adelante.
Una vez completada la configuración, ejecutamos la herramienta "monitor.exe" para comenzar a monitorizar.
A continuación tenemos que crear un archivo WSDL modificado para que la URL donde el cliente vaya a buscar el servicio Web se encuentre en el host y puerto donde tenemos escuchando a la herramienta "monitor.exe" en lugar del host y puerto real, por lo demás, el archivo WSDL es igual. La herramienta "monitor.exe" se encargará de redireccionar las peticiónes que reciba al host real que hemos indicado antes en el archivo de configuración y de paso monitorizará todos los mensajes intercambiados en el proceso, que quedarán almacenados en el archivo "tracelog.xml".
Después de alguna llamada al servicio Web que pase a través del monitor ya tendremos unos cuantos mensajes en el archivo de logging, así que podemos cerrar la herramienta de monitorización.
A continuación editamos el archivo"analizerConfig.xml" para configurar la herramienta de análisis:
- Con la etiqueta indicamos el nombre del puerto del servicio Web.
- Con la etiqueta indicamos la dirección del archivo WSDL.
Si dejamos los demás valores tal y como vienen por defecto, la herramienta utilizará los mensajes almacenados en el archivo "tracelog.xml" y el archivo "BasicProfileTestAssertions.xml" para hacer las pruebas.
Finalmente ejecutamos la herramienta "Analyzer.exe" para conseguir el archivo "report.xml" que contiene los resultados de los tests.
Saludos,
Eduardo
Este conjunto de herramientas está conformado por:
- Monitor: intercepta mensajes hacia y desde un servicio Web
- Analizer: inspecciona varios artefactos de servicios Web (incluyendo los mensajes interceptados por la herramienta Monitor)
Es importante mencionar que existen implementaciónes en Java y C# y, como parte de nuestra exposición, nos gustaría mostrar la forma de incorporar y utilizar estas herramientas en nuestros proyectos.
Por ejemplo, a continuación se muestran los pasos para la utilización de la implementación C#.
En primer lugar, descargaremos las herramientas "Interoperability Testing Tools V1.1" de la página del WS-I. En la carpeta "common/profiles" se encuentran los archivos correspondientes para cada perfil. Nosotros vamos a usar el fichero "BasicProfileTestAssertions.xml" para comprobar que cumplimos con el perfil básico.
En la carpeta "cs/bin", editamos el archivo "monitorConfig.xml" para configurar la herramienta de monitorización:
- Con la etiqueta
- Con la etiqueta
Los demás valores podemos dejarlos tal y como vienen por defecto. De esa forma, la herramienta reenviará todos los mensajes recibidos en el puerto indicado en listenPort al host y puerto indicados en schemeAndHostPort y guardará todos estos mensajes en un fichero "tracelog.xml" que usaremos más adelante.
Una vez completada la configuración, ejecutamos la herramienta "monitor.exe" para comenzar a monitorizar.
A continuación tenemos que crear un archivo WSDL modificado para que la URL donde el cliente vaya a buscar el servicio Web se encuentre en el host y puerto donde tenemos escuchando a la herramienta "monitor.exe" en lugar del host y puerto real, por lo demás, el archivo WSDL es igual. La herramienta "monitor.exe" se encargará de redireccionar las peticiónes que reciba al host real que hemos indicado antes en el archivo de configuración y de paso monitorizará todos los mensajes intercambiados en el proceso, que quedarán almacenados en el archivo "tracelog.xml".
Después de alguna llamada al servicio Web que pase a través del monitor ya tendremos unos cuantos mensajes en el archivo de logging, así que podemos cerrar la herramienta de monitorización.
A continuación editamos el archivo"analizerConfig.xml" para configurar la herramienta de análisis:
- Con la etiqueta
- Con la etiqueta
Si dejamos los demás valores tal y como vienen por defecto, la herramienta utilizará los mensajes almacenados en el archivo "tracelog.xml" y el archivo "BasicProfileTestAssertions.xml" para hacer las pruebas.
Finalmente ejecutamos la herramienta "Analyzer.exe" para conseguir el archivo "report.xml" que contiene los resultados de los tests.
Saludos,
Eduardo
Exposicion: Posibles caracteristicas a Comparar.
Para tratar de comparar estos Frameworks, open source que soportan web service en php se debe tratar de compara la facilidad de programacion, instalacion, uso, entre otros aspectos basicos, pero comparar caracteristicas especiales es importate, para ello podemos buscar que caracteristicas especiales nos ofrecen:
El WSO2 para php cuanta con la siguiente pagina con caracteristicas especiales:
http://wso2.org/project/wsf/php/2.0.0/docs/features.html
Mientras que al buscar para NuSoap esto fue una de las pocas cosas encontradas:
http://phpwebservices.blogspot.com/2008/01/nusoap-feature-list.html
El hecho que aparentemente sea mas sencillo puede ser ampliamente compensado con un excelente desempeno en las caracteristicas basicas.
El WSO2 para php cuanta con la siguiente pagina con caracteristicas especiales:
http://wso2.org/project/wsf/php/2.0.0/docs/features.html
Mientras que al buscar para NuSoap esto fue una de las pocas cosas encontradas:
http://phpwebservices.blogspot.com/2008/01/nusoap-feature-list.html
El hecho que aparentemente sea mas sencillo puede ser ampliamente compensado con un excelente desempeno en las caracteristicas basicas.
Suscribirse a:
Entradas (Atom)