Si vas a transportar datos binarios entre el cliente y el servidor vas a tener
un problema con los webservices, ya que la idea del webservice es comunicar
datos mediante xml, y un xml bien formado solo tiene texto y no datos binarios.
Una primera solucion es "serializar" la imagen a algo en hexa para meterla en
el xml y luego en el cliente "deserealizarla" para recobrar la imagen. Lo malo
es que si haces esto es muy probable que la imagen termine ocupando mas espacio
en el xml de lo que ocupa en binario.
Para resolver esto se creo MTOM (message transmission optimization mecanism),
de esta manera los datos binarios los envias por MTOM y el resto por SOAP.
Nunca use MTOM asi que no se que onda... pero al parecer es la solucion que se
propone para SOAP. Lo malo es que parece no estar bien soportado por las apis
WSDL con lo cual deberias codificar bastante codigo a mano.
De todas maneras elegir el protocolo se reduce a dos cuestiones, la primera es
la cantidad de datos que va a transportar tu webservice. Si vos queres llenar
una grilla en el cliente con las ultimas 10000 facturas de un usuario por
ejemplo, vas a tener un xml grande que puede (o no) aumentar considerablemente
el trafico de la red y que puede (o no) tardar un poco mas en parsearse. Ahora
si tu webservice va a retornar las ultimas 10 facturas realmente no va a haber
diferencia en la performance y es ahi en donde tenes que analizar la segunda
cuestion: que tan bien esta soportado el protocolo por las APIs del lenguaje en
el que quieras implementarlo.
Yo tuve que hacer un cliente para un 486 con 12mb de ram y 1Gb de rigido. En
eso solamente funcionaba windows 95, asi que me tuve que olvidar de java porque
no hay jvm, incluso tambien de .Net porque tampoco hay framework. Tampoco pude
usar PHP porque solo contaba con explorer 4 con lo cual soporte web igual a
cero. C++ es un quilombo para hacer interfaces graficas, asi que lo unico que
andaba ahi era visual basic 6. El cliente solo tenia las ventanas, un par de
procedimientos para conectarme a http y la parte del parseo del xml.
El servidor estaba en una maquina moderna en donde estaba el motor de la base
de datos y lo implemente el java usando glassfish (aunque creo que con un
tomcat hubiese alcanzado). Un webservice en java se hace simplemente agregando
una annotation al metodo que queres que funcione como webservice, asi que en 4
clicks (no exagero, fueron 4 clicks utilizando netbeans) ya tenia mi primer
webservice andando listo para probarlo. Como la velocidad era aceptable no
necesite cambiar el protocolo ni investigar mas al respecto, ni siquiera
hubiese necesitado saber que usaba SOAP de no ser porque no encontre manera de
que el cliente en visual basic 6 usara wsdl, entonces tuve que parsearlo como
un xml cualquiera y tuve que saber algo de SOAP muy basico. De todas maneras
mis webservices retornaban pocos datos, a lo sumo retornaba unos 20 datos para
mostrarlos en una grilla pero nada nada mas, ya que tampoco se justificaba
transportar mas poruqe en la pantalla mas de 20 a la vez no se ven. Toda la
logica y el procesamiento que lleva tiempo estaba en el servidor asi que con
consultas paginadas de a 20 era mas que suficiente.
Consumir un webservice es facil en la gran mayoria de los lenguajes, ahora
publicarlo ya no. En java y .NET es muy facil, en PHP es facil, en C++ ya se te
va a complicar.
Analiza cual va a ser la informacion que vas a intercambiar e implementa el
webservice con SOAP en un lenguaje facil de implementar y hace pruebas. La
ventaja de SOAP es que lo vas a implementar rapido asi que aprovecha esa
ventaja para testear si te sirve o no.
JSON es mas eficiente que SOAP, entonces por que no hacerlo directamente en
JSON? Justamente porque SOAP esta mejor soportado por las APIs que JSON segun
el lenguaje que elijas, asi que usar JSON te va a llevar mas tiempo de
desarrollo segun el lenguaje que elijas y tal vez no se justifique ya que tal
vez no haya diferencia visible de performance.
> Date: Sun, 22 Feb 2009 14:15:34 -0200
> Subject: Re: [Prog] desarrollo applicacion linux - win - web
> From: [email protected]
> To: [email protected]
>
> SOAP se me hace que es para obtener servicios o informacion puntuales.
> Es adecuado como protocolo para comunicar una GUI (cliente) y un servidor,
> entre los cuales hay mucho trafico de informacion, posiblemente imagenes o
> archivos de cierto tamaño ?
>
> _______________________________________________
> Lista de correo Programacion.
> [email protected]
> http://listas.fi.uba.ar/mailman/listinfo/programacion
_________________________________________________________________
¿Quieres saber cómo va a estar el clima mañana? ¡Ingresa ahora a MSN!
http://tiempo.cl.msn.com/
_______________________________________________
Lista de correo Programacion.
[email protected]
http://listas.fi.uba.ar/mailman/listinfo/programacion
