Mira tíº que bien hoy vamos a aumentar un poco nuestro vocabulario, y a parte de poder hablar de SOA (arquitectura orientada a servicios) algo que íºltimamente está en la boca de todos, vamos a poder hablar también de ESB (bus de servicios empresariales).
Más abajo os voy a dejar un link donde se explica qué es un ESB mucho más a fondo de lo que os voy a contar yo, pero antes, me gustaría al menos daros unas pinceladas con las principales ventajas que ESB nos ofrece, para que tengáis un poco las cosas enfocadas antes de abordar la lectura más técnica.
Imaginaos que habéis creado una aplicación orientada a servicios, donde vuestra capa de negocio permanece a parte de vuestra capa presentación y de vuestro modelo. La gran ventaja que esto supone será ya conocida por muchos, los servicios que provee la capa de negocio podrán ser consumidos por cualquier aplicación que pueda acceder al servidor de negocio y no íºnicamente por la aplicación que vosotros habéis creado. Esto añade valor a vuestra aplicación, la hace reutilizable y al mismo tiempo mantenible. Por supuesto además incorpora todas las ventajas de usar SOA, independencia de dispositivo, plataforma, adiós al problema de los firewall al utilizar el puerto 80 y blablabla…
Hagamos otro esfuerzo de imaginación y pensemos el caso de que llevamos en nuestra empresa ya 10 aplicaciones orientadas a servicios, al menos una por cada uno de los departamentos que conforman nuestra empresa. ¿Cuántos servicios podemos tener ya en marcha? ¿100? ¿500? ¿1000? Esto empieza a hacerse algo inmanejable, ¿no?
Ante esta situación se nos presentan varios problemas:
1) Catálogo de servicios inmanejable. ¿Cómo nos organizamos teniendo 1000 servicios en marcha?
2) Míºltiples conexiones punto a punto. Por cada uno de las aplicaciones de servicios con las que quiero trabajar necesito una conexión puto a punto con ella. Necesita saber exactamente dónde está.
3) Seguridad. ¿De verdad quiero que se tenga visibilidad sobre todo el catálogo de servicios disponibles?
Bien, pues ahora, si os sigue interesando el tema de los buses de servicios empresariales, aquí abajo tenéis un PDF donde en las primeras hojas tenéis una descripción mucho más concisa del tema 🙂
https://www.tibco.com/international/spain/resources/es_esb_for_soa.pdf
Saludos.
Miguel.
Category: Servicios Web
.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.
Buscando una arquitectura preparada para hacerse mayor.
Así como en el post anterior estuvimos hablando de qué tecnología web debemos elegir a la hora de comenzar un proyecto, hoy vamos a hacer algo similar pero a la hora de elegir una arquitectura.
Vamos a poner varias restricciones al proyecto para hacerlo algo más real y voy a intentaros contar lo que a mi parecer sería la mejor solución al problema.
Pongamos que tenemos una aplicación de escritorio la cual queremos migrar a las íºltimas tecnologías del momento. Nuestra aplicación se nos ha quedado algo antigua y ya no queremos invertir más pasta en su mantenimiento, así que hemos decidido ponernos manos a la obra y buscar una solución arquitectónica adecuada a la información con la que contamos actualmente.
Nuestra aplicación de escritorio sigue al pie de la letra una arquitectura cliente-servidor, donde tenemos una base de datos central, ubicada en un servidor remoto a la cual conectamos para realizar transacciones centralizadas. Además, tenemos la posibilidad de en un momento dado, por una caida del servicio central, trabajar con varios módulos de la aplicación de forma local (almacenamos la información que gestionamos en una base de datos local y al recuperarse la conexión podremos volcar nuestros cambios a la base de datos central). Además, nuestra aplicación contiene toda la lógica de negocio, por lo que ante cualquier necesidad de actualización del mismo, debemos compilar nuevamente y distribuirla a todos nuestros clientes.
Incorporo un pequeño esquema para que os hagáis un poco más a la idea de todo.
Bien, pues entonces, entre las primeras posibilidades que tenemos para renovar la aplicación es mantener la misma arquitectura, coger su código que estaba programado en Pepito.CHUF versión 2.0 y reprogramar todo internamente mediante la versión 7.0 de Pepito.CHUF. Seguramente nos vamos a dar bastante prisa. Formulario a formulario, despacito y con buena letra al final podemos obtener algo muy similar. Y si encima de paso lavamos la cara un poco a la presentación, pues oye, el cliente más contento que chuflainas porque le da la sensación que tiene una aplicación íºltimo modelo de la tecnología.
El artículo parece que se va a quedar aquí, pero vamos a darle un poco de emoción a la cosa y vamos a pensar que nos llegan ecos de que parte de la aplicación debería ser accesible a través de web. Menudo problema ya que si necesitamos trabajar puntualmente de forma desconectada… vamos a necesitar obligatoriamente tener parte web y parte escritorio. De todas maneras todo esto son rumores, y como nosotros tenemos bastante prisa para desarrollar todo esto, tal vez lo mejor que podamos hacer es tirar todo para escritorio, pero, cubriéndonos un poco las espaldas con la arquitectura, preparándola para hacerse algo mayor si más adelante se requiriera. Además, de paso, vamos a dar otro gran salto de arquitectura, sacando todo el modelo de negocio de la propia aplicación fuera de ella.
A continuación otra foto para que os hagáis un poco más a la idea.
Como véis entre la base de datos y la aplicación cliente hemos colocado un servidor de aplicaciones con servicios web.
¿Ventajas? Pues unas cuantas, ante cualquier cambio de modelo de negocio no vamos a necesitar actualizar las aplicaciones cliente, haremos el cambio en el servicio web y listo. Pero la ventaja más gorda es que estamos preparados para crecer en cualquier momento y hacer accesible nuestro modelo de negocio a cualquier tipo de dispositivo y/o tecnología.
Por ejemplo, si mañana, o pasado queremos implantar alguno de los módulos de la aplicación a través de web (por ejemplo el módulo de administración), seguramente tendremos ya tres cuartos del trabajo hecho, y íºnicamente deberemos crear una nueva capa de presentación, pero esta vez web.
íšltima foto, esta vez la definitiva.
Como véis, añadiendo una aplicación web en otro servidor web ya disponemos de una capa de presentación web, la cual conecta con el mismo servidor de servicios web con el que sigue trabajando la aplicación de escritorio. Qué bien, nos hemos evitado tener que duplicar el modelo de negocio para trasladarlo a la web. Y además, por cierto, como podéis ver, la cosa ha evolucionado hasta el punto que alguno de los operadores de la aplicación es capaz también de acceder a la misma a través de un dispositivo móvil. ¿Cuál ha sido el esfuerzo de desarrollo para esto íºltimo? Pues crear la capa de presentación del dispositivo móvil, punto y final.
¿Os hacéis a la idea del esfuerzo que requiriría disponer de acceso independientemente del dispositivo si hubiéramos mantenido la misma arquitectura de la aplicación inicial? Y por cierto, por ahora íºnicamente hemos hablado de arquitectura y no de plataforma… mediante esta solución nuestra aplicación web podría estar hecha en JSP+STRUTS, mis servicios web en PHP, mi aplicación de escritorio en .NET y nuestra base de datos… pues la que más os guste. ¿Lo veis posible mediante la primera arquitectura?
Como véis, la idea feliz de todo esto ha sido que en un momento que existía cierta incertidumbre hemos invertido algo más en arquitectura, y esto nos ha permitido que la aplicación sepa hacerse mayor con un esfuerzo muy inferior.
Saludos.
Miguel.
Arquitectura Orientada a Servicios
Arquitectura Orientada a Servicios, o lo que es lo mismo Service Oriented Architecture (SOA).
Como siempre, tiro de Wikipedia para mostraros la definición “oficial” https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
¿Aplicaciones? Puf.
Un ejemplo simple de la potencia que desprende esta arquitectura. Imaginaros una aplicación encargada de capturar las tomas de los contadores de agua de una comunidad. La aplicación consta de dos partes, una web, que emplean en una oficina central, y otra en una PDA, que utiliza el técnico que realiza la toma. En la aplicación web se encargan de hacer estadísticas, realizar los cobros… la aplicación del técnico se encarga de mostrarle las direcciones de las comunidades de vecinos a las que debe acudir… seleccionar el abonado y asignarle la toma del contador. Ambas aplicaciones tienen una capa de presentación bastante distina, una es web, y otra es una aplicación de escritorio para pda. Pero ambas necesitan en un momento dado obtener los datos de un abonado en concreto. ¿Realizamos la misma consulta para ambas aplicaciones? No, llamamos al mismo servicio web, que nos devolverá los mismos datos, y ya será la propia capa de presentación de cada aplicación la que se encargar de mostrarlo de la manera que deba.
Añadidle a esto la transparencia que supone, las aplicaciones no tienen ni idea de cómo va el modelo y el controlador, sólo tienen la vista, les da igual cómo está programado, la vista recibe XML y punto.
Saludos.
Miguel.