WEB SERVICE VS SOCKET

cuando usar una o la otra???

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

WS o Socket

El WS es para publicar/consumir servicios. He estado en proyectos que hasta los repositorios los exponen como WS lo cual se me hace una pésima decisión. El costo de marshal/unmarshal es bastante alto si lo comparas incluso con EJB que veo que a muchos les caen gordos. Si es un mal necesario cuando diferentes plataformas requieren comunicarse.

Los sockets mas que nada los veo como un canal de comunicación para notificar eventos (mensajes cortos) servidor-clientes o viceversa. Lo bueno de ellos es que son muy eficientes en el intercambio de mensajes. Lo malo con ellos es que puedes enviar cualquier cosa incluso datos sin contrato por lo que no se garantiza que lo que se envía sea válido para quien lo quiera interpretar.

Imagen de ezamudio

multiplataforma

Un web service no es la única forma de comunicarse entre distintas plataformas. Concretamente, SOAP-XML no es el único formato de datos. Puedes lograr lo mismo usando JSON o BSON o protocol buffers o Thrift.

Y la pregunta supongo que debería ser si usar web services o algún otro protocolo o formato de mensajería... porque "sockets" pues todo usa sockets, o qué, las peticiones de SOAP viajan por arcoiris? En una invocación de un web service, el cliente abre un socket al servidor, y una vez establecida esa conexión se comunican usando HTTP.

Imagen de skuarch

Para mi

web services para comunicar entre diferentes lenguajes, sockets para todo lo demas obviamente dependiendo de las circunstancias

Sockets cuando quieras

Sockets cuando quieras implementar tu propio protocolo desde cero y/o cuando quieras implementar un protocolo existente desde cero ( HTTP por ejemplo, porque harias eso, eso otra cosa)

WebServices cuando quieres usar un mecanismo de mas alto nivel.

Imagen de ezamudio

pfff

hablan de esto como si solamente hubiera las dos alternativas: web service, o un socket y ya. Se puede implementar un web service a manita, empezando por el puro socket. Y se pueden implementar servicios complejos de comunicación host to host o cliente-servidor, peer-to-peer, etc sin tener usar un puro socket y tener que implementar absolutamente todo lo que va encima.

Ejemplos: Thrift, Protocol Buffers, j8583, y bueno, sin irnos tan lejos, ese componente tan simple y tan útil que viene en el JDK, el HttpURLConnection, que es un cliente muy pero muy simple de HTTP pero que sirve para muchos casos en que hay que comunicarse via HTTP usando JSON o XML o algún formato de datos binario, propietario, etc.

Pues la pregunta es para

Pues la pregunta es para cuando usar uno u otro, pero si claro no son los unicos.

Tambien habria que mencionar aqui CORBA y RMI (jejej nomas por trolear)

Imagen de Nopalin

Que tanto traen con RMI?

Que tanto traen con RMI?

Dicen por ahi que cada habla dependiendo de como le fue en la feria. En todos los proyectos que he realizado que son cliente-servidor, ambos los hago en java y la comunicacion es con RMI. Transfiero todo tipo de objetos y datos primitivos, pueden ser muy pequeños o hasta varios megas para cuando transfiero el contenido binario de un archivo o cuando son alrededor de 10 mil registros en una consulta (ya se que ésto es pésimo, pero en mi defensa se crea un archivo de excel que genera gráficas, lo cual tambien es pésimo pudierno usar jfreechart, pero bueno el cliente lo que pida no? ya lo dijo luxpess solo hay que dejarle bien al claro al cliente las limitaciones jeje). Después de 8 años de uso y nunca habiendo tenido un problema por serializacion/deserializacion que se pierdan los datos, lentitud o alguna otra cosa, RMI sigue siendo mi preferido cuando es de JVM a JVM.

Puden decirme algo contundente por el cual RMI deberia ser marcado como deprecated? Pudieran tal vez hablarme maravillas de otros y en comparacion de rendimiento igual, pero si RMI hace la chamba y la hace muy bien, ¿cual es la desventaja entonces?

Imagen de ezamudio

deprecated?

No sabía que hubiera quienes quieren marcar RMI como deprecated. Es probablemente el mecanismo más sencillo para comunicación entre JVMs como bien mencionas.

En el caso concreto que mencionas, si tienes broncas de performance o de ancho de banda, yo sí le echaría un ojo a protocol buffers. En cuanto a peformance le da vueltas a RMI, aunque es más engorroso de usar.

Con RMI yo sí he tenido problemas de deserialización cuando hay versiones distintas de la clase que estás transmitiendo, pero pues el error es bastante claro y simplemente se arregla sincronizando las versiones de clases en ambos lados.

Imagen de Nopalin

Eso de la serializacion no es

Eso de la serializacion no es problema de RMI si no del programador, seria similar a cuando se modifica la firma de un metodo remoto usando webservices de 2 a 3 params, y el cliente lo llama solo pasandole 2, el error es inminente.

En cuando a performances, tal vez en un ambiente de altisima concurrencia donde se necesite comprimir al maximo la información transmitida para agilizar la transferencia, seria la única manera que veo de poder utilizar algun otro mecanismo. ¿O en que casos reales han tenido la necesidad ustedes?

Imagen de ezamudio

Volumen

En ningún momento dije que fuera un error inherente a RMI. Efectivamente es un problema en la serialización, lo menciono porque creo que es un problema común al usar RMI si se transmiten clases de la aplicación y uno de los dos lados se actualiza y el otro no. No es culpa de RMI.

En cuanto a casos reales: Pues no nada más altísima concurrencia, simplemente para transferir un alto volumen de datos, conviene más usar algo que pueda serializar, transmitir y del otro lado deserializar muy rápidamente.

Otro caso en donde puedes usar protobuf en vez de RMI, es si quieres comunicarte con otras plataformas (.NET por ejemplo, o ruby, ObjC etc). Es multiplataforma, pero funciona más rápido que RMI, ya ni hablar de web services. Pero esto es lo que empecé comentando yo, ya le estamos dando vueltas al asunto.

También uso RMI en producción porque no he tenido necesidad de sustituirlo por algo más eficiente. Funciona, y funciona bien.