Navaja de Occam
La navaja de Occam (navaja de Ockham o principio de economía o de parsimonia) hace referencia a un tipo de razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta.
Principio Fundamental de KISS
El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería.
Este término es un acrónimo que corresponde a la frase en inglés “Mantenlo simple, estíºpido” (Keep It Simple, Stupid). Para evitar ser tosco, el acrónimo se hace corresponder con otras expresiones tales como “Manténgalo breve y simple” (“Keep It Short and Simple”) u otras similares, pero que mantienen la misma idea del principio.
Ambas descripciones han sido extraidas de Wikipedia.
Saludos.
Miguel.
Category: Arquitectura
Caché en la Capa de Acceso a Datos
En muchas aplicaciones suele ser comíºn que existan conjuntos de datos que cambien muy poco o nada a lo largo del tiempo. Por ejemplo, si almacenamos en nuestra base de datos tablas con Países, Provincias, Comunidades Autónomas… lo más seguro es que los registros que conformen la tabla no varíen en el tiempo o si lo hacen sean cambios totalmente excepcionales.
Si esto es así e imaginando el típico formulario web donde tenemos que seleccionar un desplegable con provincias, podría resultar ineficiente hacer una consulta a base de datos por cada carga del formulario que realizaran los distintos usuarios de la aplicación. ¿Para qué vamos a consultar otra vez la base de datos si podemos asegurar en un 99% que no habrán cambiado? Sobre todo teniendo en cuenta que el acceso a base de datos suele ser de lo que más penaliza el rendimiento de una aplicación.
Una buena idea sería que en segíºn que métodos de nuestra capa de acceso a datos, antes de realizar una consulta directa a una tabla, comprobáramos si los datos ya se han almacenado en entidad física mucho más rápida de acceder que la base de datos, por ejemplo, en una caché. Inicialmente esta caché estaría vacía, en la primera carga se rellenaría a partir de la información de la base de datos, y el resto de veces ya se atacaría siempre a la memoria cache.
El resultado, claramente es un tiempo de respuesta mucho más bajo en cada transacción de este tipo.
¿Algíºn ejemplo con pseudo-codigo?
public Lista<ProvinciaDTO> GetProvincias()
{
if (IsVacio(CacheProvincias))
{
CacheProvincias = RellenaConAccesoATablaProvincias();
}
return TransformaCacheEnLista(CacheProvincias);
}
Como véis sólo rellenaremos la caché de provincias con los datos de la tabla si la caché está vacía, si no lo está, directamente retornaremos los datos desde la caché.
En el pseudo-código no se están resolviendo temas de concurrencia (cómo resolver si dos usuarios al mismo tiempo comprueban si está vacío y da verdadero), y se abstrae 100% la solución propia de cómo cachear precisamente para hacerlo independiente de la tecnología en que queráis aplicar el método.
Otro tema interesante que podrían incorporarse, es la posibilidad de que la caché caduque, es decir, que no se almacene la información en la caché de forma infinita mientras la aplicación no se reinicie, si no que se establezcan periodos temporales en los como máximo la caché será renovada. Por ejemplo si tenemos una tabla que almacene Marcas puede que nos interese que se reuneve la caché cada 24 horas ya que almenos una vez al día se añade una marca nueva (me lo estoy inventando obviamente, es por dar un ejemplo). Si ante la petición de un usuario se comprueba que la caché está caducada, esta se vaciaría y se volvería a rellenar de forma automática tras una consulta a la tabla correspondiente de la base de datos.
¿Interesante?
Saludos.
Miguel.
Evento Microsoft sobre la Arquitectura Orientada a Servicios
El próximo jueves 8 de mayo se va a producir un evento on-line por parte de Microsoft relacionado con la Arquitectura Orientada a Servicios.
La descripción del evento es la siguiente:
“Uno de los temas más polémicos en los íºltimos tiempos en Arquitectura de Software es la orientación a servicios, y cómo esto mejora la agilidad, flexibilidad y el rehíºso de mis soluciones. En esta sesión, nos enfocaremos en la orientación a servicios desde una perspectiva de arquitectura de software, analizaremos cómo un enfoque orientado a servicios difiere de arquitecturas basadas en objetos y componentes, así como también la discusión de algunos retos organizacionales que se experimentan al adoptar una arquitectura orientada a servicios”
Muy interesante a priori, el íºnico problema es que para poder verlo en directo tendréis que estar delante del ordenador de 11 a 12 de la noche… 🙂 O esperar más adelante a que pongan a disposición la grabación para ver el vídeo off-line.
Mas información y suscripción al evento Aquí
Un saludo.
Miguel.
Arquitectura en Pizarra
Para los que les llame la atención los temas relacionados con la arquitectura de software, hoy cambiamos un poco el tema de las arquitecturas en varias capas, de la que hemos hablado bastante en este blog, para presentar otra arquitectura diferente, la Arquitectura en Pizarra.
Me limito a dejar el link a la descripción de Wikipedia (ha sido una semana complicada), da una pincelada suficiente, sin profundizar, al menos para que nos hagamos un poco a la idea de su funcionamiento.
https://es.wikipedia.org/wiki/Arquitectura_en_pizarra_%28inform%C3%A1tica%29
Saludos.
Miguel.
Uso de Capas. Nuevo Ejemplo.
Hoy volvemos otra vez al tema de aplicaciones con una arquitectura en n-capas. Lo de la “n” viene al hilo de que las capas tienden a “n”, vamos, que no está definido con cuántas capas vamos a trabajar en total, si no que nuestro “n” dependerá de la arquitectura que necesitemos montar para nuestra solución.
Empezamos con una pequeña descripción del problema:
“La aplicación que necesitamos crear es un sistema de gestión de reservas. Las reservas pueden llevarse a cabo de dos maneras diferentes. La primera directamente sobre una intranet propia, a través de web, en la cual un operador sea capaz de realizar una reserva contra una plaza de un vuelo de una compañía aérea en concreto. La segunda se realiza de forma externa a través de internet. Son las propias compañías las que mediante envíos de XML que siguen un estándar propio de cada una de ellas, contactan contra nuestra aplicación, actualizando las plazas, reservas, disponibilidades, cupos y horarios de los vuelos.”
Para resolver el problema vamos a trabajar con una arquitectura de n-capas. Siendo nuestro “n” en este caso igual a 5.
1) Capa de Presentación
2) Capa de Negocio
3) Capa de Acceso a Datos
4) Capa de Datos
5) Capa de Preformato
A continuación muestro un gráfico con la representación de la solución de arquitectura.
La clave de esta solución de software está en la unión entre la capa de Presentación, Negocio y Preformato. La capa de Preformato será la encargada de traducir la información que llega de forma diferente desde cada una de las compañías y traducirla a la jerarquía de objetos que se utiliza para la comunicación dentro de la aplicación. Está claro que tanto trabajando directamente sobre la intranet, como a través de las conexiones externas, los conceptos a tratar, las entidades de negocio, van a ser las mismas. Lo íºnico que debemos hacer es traducir en nuestro propio “idioma” todo lo que llegue desde fuera, para poder trabajar con una capa de negocio comíºn. Esto va a liberarnos de muchísimo trabajo, sobre todo de mantenimiento. La íºnica capa que va a depender de las definiciones de las compañías aéreas va a ser la de preformato. Ante un cambio de cualquiera de las compañías el resto de capas ni se va a inmutar.
También es efectiva esta solución a la inversa, es la capa de preformato la que sabe cómo debe comunicarse con cada una de las compañías aéreas. Entre la capa de Negocio y Preformato se comunicarán siempre de la misma manera.
Como podréis apreciar en este punto no hemos hablado de tecnologías con las que resolver el problema, ni tan siquiera cómo va a ser la comunicación XML entre las compañías y nuestra capa de preformato, pero como podréis ver también esto es algo que en principio no tiene por qué afectar a la definición de alto nivel que estamos realizando.
¿Dudas? ¿Mejoras?
Saludos.
Miguel.
MVC y Aplicaciones N-Capas con ASP.NET y Visual Studio 2005
Para los defensores de que el patrón MVC es algo que viene de Java y que ASP.NET no está preparado para llevarlo a cabo, por favor, consulten el siguiente enlace en el que se muestra un ejemplo muy muy sencillo de implementación del patrón
https://msdn2.microsoft.com/en-us/library/ms998540.aspx
Para los interesados en ver un ejemplo magistral de implementación de una aplicación ASP.NET en N-CAPAS, os recomiendo consultar el siguiente enlace
https://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416
Un saludo a todos y feliz año.
Miguel.
Buenas Prácticas: Los servicios web no deberían devolver tipos específicos de la tecnología
Típico ejemplo de esta situación es un servicio web hecho en .NET que devuelve un Dataset.
Si se nos garantiza que el consumidor del servicio va a ser siempre un cliente .NET aíºn la cosa se sostiene un poco. El problema es si por ejemplo intentamos consumir un servicio que da un Dataset por otra tecnología que no es .NET.
Para los que tengáis experiencia trabajando con servicios sabréis que una vez que creas un servicio que devuelve un objeto o tiene por parámetro un objeto definido en el servicio, desde el cliente que consume el servicio tenemos visibilidad sobre la definición de dicho objeto. Si yo tengo un servicio que recibe por parámetro un objeto coche, yo desde el cliente puedo rellenar dicho objeto coche y pasárselo por parámetro al servicio. Lo mismo ocurre si el coche me lo devuelve el servicio, yo puedo conocer sus propiedades y extraer los valores de las mismas.
¿Pero qué ocurre con un dataset? ¿Ocurre lo mismo? Pues no.
El principal problema de un Dataset es que en tiempo de diseño no conocemos cuál es su contenido. Sólo lo sabemos en tiempo de ejecución. Ya “sólo” por este “pequeño” problema tenemos ya un agujero del tamaño de un tonel respecto a la protección de tipos en tiempo de diseño. Podemos pedirle lo que quiera al dataset, porque el compilador no va a darnos ningíºn tipo de alarma, nos vamos a enterar en tiempo de ejecución generando una excepción si la consulta sobre el dataset no era correcta.
Este problema se vuelve más complicado aíºn si consumimos el servicio desde por ejemplo un cliente java, ya que para interpretar el contenido del dataset en tiempo de ejecución no nos va a quedar más remedio que leer el mensaje xml que nos llega con el contenido, leerlo e interpretarlo a pelo.
¿Cual es entonces mi recomendación? No es difícil respuesta adivinarlo si leéis los artículos de esta web, por mi parte está claro, Data Transfers Objects 🙂 O Value Objects, que es lo mismo 🙂
Saludos!
Miguel.
El negocio es el negocio
En el artículo anterior ya estuvimos comentando que lo de la arquitectura orientada a servicios está hoy en día hasta en la sopa, que no hasta en la SOAP (chiste malo).
Qué bonito es lo de la orientación a servicios, vamos a encapsular el negocio, pero… ¿tenemos todos claro qué es lo que tenemos que almacenar en el negocio?
Lo comento porque es un error bastante comíºn pensar que en el negocio de nuestra arquitectura orientada a servicios debemos almacenar por ejemplo nuestro acceso a datos de forma encapsulada. Me explico con un ejemplo. Pongamos que tenemos un servicio que compra un coche, el cual a la hora de llamarlo crea una nueva entrada en la tabla “Compra”. Pero claro, cuando compramos un coche no sólo tenemos que registrarlo en la tabla “Compra” si no que seguramente tendremos que trabajar con el Stock, y dependiendo de nuestro Stock tal vez tengamos que hacer una petición de nuevo Stock. Además, puede darse el hecho que segíºn la petición de nuestro cliente la compra la haga financiada y la compra financiada le obligue a pagar un seguro de vida por cada uno de los meses que se le esté financiado la compra.
Wou, cuantas cosas. ¿Esto quiere decir que tenemos que hacer un servicio web por cada uno de las posibilidades que hablábamos en el anterior párrafo? Pues no, eso es un error de concepto de cómo usar la capa de negocio. La capa de negocio tiene que encapsular el negocio, es decir, ocultarlo a los consumidores del mismo.
Si uno de los clientes que llama al servicio web quiere comprar un coche llamará al servicio web de compra de coche pero no se va a preocupar de todas la otra casuística del stock y de la financiación y toda la historia, porque de eso no sabe nada. Nuestro consumidor del servicio no tiene por qué saber cómo funciona nuestro negocio, eso es cosa nuestra. El servicio web se encargará de todo internamente abstrayendo al cliente.
¿Se entiende el concepto?
Saludos.
Miguel.
ESB (Bus de Servicios Empresariales) + SOA (Arquitectura Orientada a Servicios)
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.
.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.