.NET Remoting y Servicios Web

Antes de nada comienzo como muchas veces dejando primero unos links a definiciones algo más concretas para luego pasar a desarrollar un poco el tema, que en este caso trata de Remoting y Servicios Web
https://en.wikipedia.org/wiki/.NET_Remoting
https://es.wikipedia.org/wiki/Servicio_Web
Es curioso porque lo de los servicios web se oye hoy en dí­a por todas partes. Está en boca de todo el mundo, y la verdad es que hay motivos de sobra para esto ya que ha supuesto una revolución en cuanto a la arquitectura y ante la intercomunicación de sistemas desarrollados en diferentes plataformas y tecnologí­as. Al rey lo que es del rey, y bajo mi punto de vista los servicios web no son una moda, si no algo que realmente tiene potencia y valor. No estoy diciendo que sea la solución para todo y que después de esto no vaya a haber nada más (eso nunca pasa, al final siempre sale algo mejor), pero insisto en el hecho de que ha supuesto una verdadera revolución en la intercomunicación de sistemas.
Cuando nos ponemos a hablar de Remoting para .NET entonces la cosa ya cambia. No todo el mundo sabe muy bien para qué funciona, o tal vez ni lo hayan oido nombrar nunca. La verdad es que en parte sus razones hay, sobre todo por el hecho de que Remoting es algo que pertenece íºnicamente a la plataforma .NET y que está desarrollado por Microsoft y para plataformas Microsoft. Puedes hacer un servicio web en una plantaforma Java, PHP, Ruby on Rails, .NET y consumirlo desde cualquier otra plataforma, pero un servicio de Remoting vas a tener que pasar por el tubo para ponerlo en marcha tanto en la creación como en la consumición.
¿Y esto quiere decir que es mejor solución optar por los servicios web que por un servicio de remoting? Pues no, como siempre la mejor solución va a depender del problema.
A la hora de decidirse lo primero que hay que tener claro es que tanto remoting como los servicios web vienen a resolver parte de la misma problemática, es decir, encapsulan el modelo de negocio en un servidor de aplicaciones, el cual puede ser accesible desde otras aplicaciones. La lógica de la aplicación no está en la aplicación, si no en el servidor de servicios web o el de remoting. Además, mira tíº por donde, podemos levantar un servicio web y un servicio de remoting en un mismo servidor web (Internet Information Server). Y encima, los dos trabajan sobre http, por lo que nos quitamos de encima todo el problema de puertos, firewall y toda la pesca. ¿Sobre la seguridad? IIS nos solventa el problema en ambos casos.
¿Entonces que les diferencia? Paso a enumerar:
1) Un servicio de remoting es más eficiente que un servicio web si serialiamos los mensajes de remoting en formato binario.
2) Un servicio web es totalmente independiente de la plataforma que lo consume ya que utiliza SOAP como estándar de comunicación.
3) Un servicio de remoting debe ser creado y consumido por aplicaciones .NET.
4) Es más sencillo crear y mantener un servicio web que un servicio de remoting.
5) Un servicio web puede utilizar íºnicamente http como canal de comunicación, en cambio un servicio de remoting puede trabajar también mediante TCP. Si unimos TCP+Serialización binaria es cuando conseguimos la mayor eficiencia trabajando con remoting.
6) Si utilizamos remoting mediante TCP vamos a tener que trabajarnos por nuestras cuenta todo lo referente a seguridad y autenticación, mientras que si lo montamos sobre un IIS y http, IIS nos va a resolver toda la papeleta.
Para terminar os dejo una captura de pantalla de un ejemplo de arquitectura donde Remoting y Servicios Web conviven. Como podréis observar los clientes .NET internos consumen servicios de remoting, mientras que los usuarios que acceden a través de internet consumen servicios web. Como tenemos completamente separado el modelo de negocio todo esto es posible, ¿qué bonito verdad? ¿A que mola la capa de fachada de negocio? Hablaremos un dí­a de estos del patron de diseño Faí§ade. ¿No os suena un poco la cosa? A simple vista parece un modelo de factorí­a como el que podrí­amo usar para diferentes bases de datos, pero aplicado a diferentes tipos de servicios.

Saludos.
Miguel.