El patrón Circuit Breaker es muy parecido a un fusible, el cual se funde para evitar que una descarga eléctrica afecte al circuito, con la única diferencia de que el software, este fusible se puede restaurar cuando el problema allá pasado. Esto puede resultar un poco confuso, pero analicemos cómo funciona el patrón con el siguiente diagrama:

Antes de explicar cómo funciona el diagrama, debemos de comprender que son y el rol que tiene cada uno de los componentes involucrados:

• Client: representa al cliente que intenta consumir los servicios del Supplier, sin embargo, este lo hace por medio del Circuit Breaker.
• Circuit Breaker: es el componente que se encarga de la comunicación con el Supplier, el cual, mantiene un registro del estado de salud del servicio que usará para abrir el circuito cuando detecte que el Supplier está fallando.
• Supplier: representa el servicio de negocio remoto, el cual expone una serie de funcionalidad para ser consumida por el Client.

Una vez que entendemos esto, pasemos a explicar cómo funciona el patrón Circuit Breaker:

1. El Client realiza una primera llamada al Supplier por medio del Circuit Breaker.
   1. El Circuit Breaker determina que el servicio está operando correctamente el Supplier y redirecciona la petición al Supplier.
   2. El Supplier responde correctamente y envía la respuesta al Circuit Breaker para que sea este quien finalmente reenvíe la respuesta al Client.
2. El Client envía nuevamente una petición al Supplier por medio del Circuit Breaker
   1. El Circuit Breaker redirecciona la petición al Supplier
   2. En esta ocasión el Supplier responde con error o lanza un Timeout
   3. El Circuit Breaker recibe la respuesta de error y toma nota del error, el cual tiene un contado que determina cuantas veces ha fallado el Supplier de forma simultánea. En este caso, el contado de errores se establece en 1.
   4. El Circuit Breaker redirecciona el error al Client.
3. Seguido de un tiempo, el Client envía nuevamente una petición al Supplier por medio el Circuit Breaker.
   1. El Circuit Breaker redirecciona la petición al Supplier
   2. El Supplier nuevamente responde con error o Timeout
   3. El Circuit Breaker recibe la respuesta de error e incrementa el contado de errores en 2.
      1. Dada una configuración, el Circuit Breaker puede determinar que 2 es el número máximo de errores simultáneos que puede tolerar antes de realiza el corto circuito y abre el circuito con el Supplier.
      2. Un paso opcional pero muy deseable es tener algún componente de monitoreo que permite notificar a los administradores en tiempo real sobre los errores para poder tomar cartas en el asunto.
   4. El Circuit Breaker redirecciona el error al Client.
4. El Client nuevamente envía una nueva petición al Supplier por medio del Circuit Breaker.
   1. El Circuit Breaker determina el servicio no está respondiendo debido a los dos errores anteriores, por lo que retorna un error al Client indicándole que el Supplier está fuera de servicio.

Como podemos observar en la explicación anterior, el Circuit Breaker puede determinar que un determinado servicio (Supplier) está fuera de servicio al detectar que ha respondido con error de forma consecutiva un número determinado de veces.

NOTA: es común confundirse con el termino abierto y cerrado, pues podemos pensar que el estado abierto es cuando el servicio está disponible, sin embargo, como estamos utilizando la nomenclatura de los circuitos eléctricos, por lo que un circuito cerrado es cuando la electricidad flujo, por lo tanto, en este patrón, cerrado significa que existe comunicación con el Supplier.

Abriendo el circuito

En este punto te estarás preguntando, bien, ya he abierto el circuito, pero no me puedo quedar todo el tiempo así, necesito cerrarlo nuevamente una vez que el problema se ha resuelto. Pues bien, para eso, tenemos una funcionalidad adicional, en la cual configuramos cuanto tiempo debe esperar el Circuit Breaker antes de mandar una solicitud al Supplier. En este caso, por ejemplo, podríamos esperar una hora desde que se cerró el circuito para enviar una nueva petición, si esta petición retorna exitosamente, el Circuit Breaker cerrará nuevamente el circuito con el Supplier, pero, por el contrario, si este nuevamente retorna con error o Timeout, entonces el tiempo de espera se reiniciará y esperará otra hora antes de mandar una nueva petición para comprobar su disponibilidad.

Dicho lo anterior, veamos cómo quedaría el diagrama de secuencia para la reapertura del circuito:

1. En la parte superior partimos del escenario donde hemos abierto el circuito, lo cual explicamos anteriormente, por lo que nos saltaremos esta explicación. Solo asumamos que, en este punto, el circuito se encuentra abierto.
2. Una hora después de que el circuito se abrió, el Circuit Breaker redirecciona la siguiente petición al Supplier que estaba fallando para comprobar si ya se encuentra en funcionamiento.
   1. Tras redireccionar la petición al Supplier, este falla nuevamente y redirecciona el error al Circuit Breaker.
   2. El Circuit Breaker al darse cuenta que sigue fallando, reinicia el contador para esperar otra hora antes de volver a intentar consumir los servicios del Supplier.
3. Tras una hora desde el paso anterior, el Circuit Breaker redirecciona una nueva petición al Supplier para comprobar si ya se encuentra en funcionamiento.
   1. En este caso, el Supplier ya se encuentra operando correctamente, por lo que recibe la petición, la procesa y retornar exitosamente.
   2. El Circuit Breaker detecta la respuesta exitosa del Supplier y cierra nuevamente el circuito.

Circuit Breaker y los microservicios

En este punto ya hemos aprendido como es que el patrón Circuit Breaker abre el circuito ante una serie de errores consecutivos y como el circuito se cierra cuando el error es resuelto, pero hay algo de lo que no hemos hablado. ¿Te has preguntado que va a pasar con la aplicación si se abre el circuito? Es decir, una hora sin poder lanzar peticiones al Supplier podría causar un caos en nuestra aplicación, pues no podremos hacer nada hasta que el circuito sea restaurado.

Pues bien, te tengo buenas noticias, este patrón no fue diseñado para aplicaciones Standalone, si no que fue diseñado para arquitecturas cloud, donde tenemos alta disponibilidad y escalamiento, lo que quiere decir que debemos de tener múltiples instancias del Supplier, para asegurarnos de seguir operando ante la falla de una o múltiples instancias del mismo Supplier:

En la imagen anterior ya podemos observar cómo es que existe una serie de instancias de un mismo Supplier, por lo que en caso de que alguno falle, el Circuit Breaker deberá ser lo suficientemente inteligente para redireccionar la petición a otro Supplier en caso de que el primero falle, de esta forma, no retornamos el error al cliente, si no que reintentamos la ejecución en el siguiente Supplier disponible.

Ciclo de vida del Circuit Breaker

El Circuit Breaker se puede implementar como máquina de estados, la cual puede pasar por 3 estados diferentes, y cada estado afectará la forma en que funciona, los estados son:

• Closed: Este estado indica que el servicio destino está respondiendo correctamente. En caso de alcanzar un umbral de errores, pasará al estado Open.
• Open: Este estado indica que el servicio destino está fallando, por lo que toda invocación regresara un error de inmediato. Tras un tiempo de espera, pasará a estado Half-Open.
• Half-Open (medio abierto): Tras un tiempo en estado Open, el componente pase a Half-Open, lo que indica que puede recibir una pequeña cantidad de solicitudes para validar si el servicio está nuevamente activo. Si las solicitudes pasan exitosamente, el componente pasa a Closed, en otro caso, regresa a Open.

Entornos Asíncronos

Hasta este punto hemos analizado como es que este patrón se utiliza para servicios donde las invocaciones son síncronas, pero ¿qué pasaría si pasamos a un entorno donde los servicios a consumir se ejecutan de forma asíncrona? Por suerte, este patrón también se puede utilizar bajo estas circunstancias, aun que debemos de cambiar un poco la lógica, aunque el principio es el mismo.

En entornos síncronos, no tendremos respuestas con error ni timeout, por lo que las métricas que utilizábamos anteriormente no aplican, es por ello que podemos utilizar Colas (Queues):

En este caso, el Circuit Breaker en lugar de ejecutar directamente el servicio, tendrá que depositarlo en una Queue, de tal forma que el Supplier los podrá ir tomando a como pueda, lo que impide que lo saturemos de peticiones y lo hagamos colapsar, por otro lado, el Circuit Breaker podrá determinar el número de mensajes que tiene la Queue, y si este alcanza un umbral determinado, podríamos determinar que está fallando o que está procesando los mensajes demasiado lento, por lo que abrimos el circuito para impedir que se sature.

Como vemos, el funcionamiento es el mismo, lo que cambia es la forma de medir si un servicio está fallando o tarda mucho tiempo en procesar los mensajes.

Ventajas de implementar Circuit Breaker

Adicional a las ventajas obvias que podemos ver, como la tolerancia a fallas y el envío de solicitudes a servicios que sabemos que van a fallar, existen otros tipos de ventajas:

Monitoreo:

Dado que tenemos un componente que su única funcionalidad es sondear el estado de vida de los servicios, es posible tener un monitoreo en tiempo real, que nos indique los tiempos de respuesta promedio, frecuencia de falla, estado actual del servicio y, sobre todo, notificaciones en tiempo real si algún servicio comienza a fallar.

Sobrecarga:

La capacidad de abrir el circuito ante un error o Timeout que sabemos que va a pasar, nos ahorra el hecho de tener muchos hilos esperando a que el servicio responda, y más aún, si tenemos miles de usuarios, es probable tener muchísimos hilos detenidos, lo que provocaría que nuestro sistema se sobre cargue, incluso, puede provocar una bola de nieve que comience a afectar a otros componentes.

Tolerancia a fallas

Como ya lo dijimos, el Circuit Breaker puede redireccionar la petición al siguiente Supplier en caso de que alguno falle, evitando tener que enviarle el error al cliente.

Conclusiones

Como hemos analizado a lo largo de este artículo, utilizar el patrón Circuit Breaker permite que inundemos nuestra aplicación con una gran cantidad de solicitudes que sabemos de antemano que van a fallar, por lo que, en lugar de eso, re direccionamos las peticiones a una instancia del servicio que está operativo.

Este patrón de diseño es altamente utilizado en entornos distribuidos y con arquitecturas de microservicios, por lo que no es para nada recomendable utilizarlo para operaciones en memoria o servicios albergados de forma local. Recordemos que este patrón está diseñado para recursos remotos.

The post Circuit Breaker pattern appeared first on Oscar Blancarte - Software Architecture.

Este video es la continuación del video de introducción a al patrón Factory Method. En esta segunda entrega aprenderemos a utilizar el patrón mediante in ejemplo del mundo real, en el cual aprenderemos a crear una aplicación que permite conectarse a más de una base de datos, la cual podrá ser intercambiada por medio de la configuración.

The post Patrón Factory Method – Proyecto [Segunda parte] [Video] appeared first on Oscar Blancarte - Software Architecture.

En este video te enseñare la teoría que hay detrás del patrón Factory Method, este patrón permite la creación de objetos de un subtipo determinado a través de una clase Factory. Esto es especialmente útil cuando no sabemos, en tiempo de diseño, el subtipo que vamos a utilizar o cuando queremos delegar la lógica de creación de los objetos a una clase Factory. Utilizando este patrón podemos crear instancias dinámicamente mediante la configuración, estableciendo cual será la implementación a utilizar en un archivo de texto, XML, properties o mediante cualquier otra estrategia.

Puedes ver la segunda parte en aquí

The post Patrón Factory Method – Introducción [Primera parte] [Video] appeared first on Oscar Blancarte - Software Architecture.

Solo imagina un escenario, tenemos una aplicación A y otra aplicación B, la aplicación B genera nueva información de forma recurrente. La aplicación B no sabe de la existencia de la aplicación A y la aplicación A requiere obtener las novedades de la aplicación B.

En este escenario, la aplicación A esta forzada a consultar frecuentemente por nuevas actualizaciones (Polling), lo que implica que la aplicación A no se entere al memento de los cambios, si no que tendrá que esperar a que el polling se ejecute nuevamente para obtener los nuevos datos, adicional, la aplicación B sufre un degrado en el performance, pues cada vez que la aplicación A realiza una consulta, la aplicación B tiene que buscar en la base de datos las actualizaciones, si esto lo multiplicamos por todos los posibles clientes podremos entender mejor el problema.

Webhook

Una mejor alternativa al polling tradicional, es la implementación de un Webhook, el cual consiste en crear un sistema de notificaciones mediante HTTP, para lo cual, la aplicación B permitiría que la aplicación A o cualquier otra registren una URL a cuál notificar en caso de actualizaciones. La ventaja que ofrece esta arquitectura es que la aplicación B sigue sin conocer a la aplicación A, y en su lugar solo conoce una URL a la cual deberá notificar en caso de haber actualizaciones.

Cuando la aplicación B tiene nuevas actualizaciones, entonces lanza una llamada a la URL de la aplicación A. En esta llamada solo se envían los datos actualizados o un identificador para que posteriormente la aplicación A consulte todo el detalle.

Dado que las notificaciones son por medio de HTTP, hace que sea mucho más simple la comunicación, pues cualquier servidor puede recibir la petición y procesar el mensaje, también es compatible con servicios REST.

Esta arquitectura ofrece un mejor rendimiento y una actualización en tiempo real. Para empezar, la aplicación A ya no requiere realizar consultar frecuentemente para saber si hay actualizaciones, por otra parte, la aplicación B yo requiere consultar su base de datos para cada petición, en su lugar este notificará a todos los interesados como parte del proceso.

También puede interesarte como notificar aplicaciones mediante un sistema de mensajería como lo JMS, que explico en el articulo JMS en las integraciones.

Conclusiones

Como podemos ver, utilizar un Webhook siempre será más eficiente que utilizar los tradicionales Polling, sin embrago, un Webhook es más complicado de implementar, pues requiere de contemplar las notificaciones en cada uno de los procesos de actualización sobre el sistema origen.

Esto no quiere decir que no debemos de utilizar polling, ya que esta arquitectura se utiliza cuando no existe otra alternativa y el sistema origen no tiene un mecanismo para notificar a los clientes.

The post Webhook una alternativa al Polling appeared first on Oscar Blancarte - Software Architecture.

Esto quieres decir que un usuario podría entrar a varias aplicaciones sin necesidad de tener que autenticarse en cada una, en su lugar, solo requerirá autenticarse la primera vez en cualquiera de las aplicaciones y posteriormente podrá acceder al resto si pasar por el proceso de autenticación.

Métodos de autenticación tradicional

Para comprender mejor este concepto es importante entender cómo funcionan los métodos de autenticación tradicional, en el cual, los usuarios requieren de un inicio de sesión en cada aplicación o página web en la que requieren entrar:

Ilustración 1 – Método de autenticación tradicional

En los métodos de autenticación tradicional, el usuario tiene que autenticarse en cada aplicación en la que va requiriendo acceder, de esta manera, el usuario puede tener un usuario y contraseña diferente para cada aplicación. Cuando el usuario introduces sus credenciales, las aplicaciones van y comprueba que los datos del usuario son correctos directamente sobre su base de datos. Si las credenciales son correctas el usuario podrá acceder y operar el sistema.

Single SingOn (SSO)

A diferencia de los métodos tradicionales, SSO permite delegar el proceso de autenticación a una entidad externa, la cual tiene como única responsabilidad autenticar que el usuario es quien dice ser, una vez autenticado este regresa un comprobante o Ticket que deberá ser presentado a la aplicación a la cual se está solicitando el acceso. La aplicación toma el comprobante y lo valida contra la entidad de autenticación (SSO) y valida la veracidad del ticket y la vigencia del mismo, si todo está bien, entonces la aplicación permite al usuario operar el sistema. Cuando el usuario requiere entrar a otra aplicación distinta, tan solo requerirá presentar el ticket para poder autenticarse nuevamente hasta esta otra aplicación.

Ilustración 2 – Autenticación mediante Single SingOut

En esta imagen, podemos apreciar de forma más clara como es el proceso de autenticación mediante SSO. El usuario intenta entrar a la aplicación A, como el usuario no está autenticado, redirecciona al usuario a al proveedor de autenticación que soporte SSO, el usuario se autentifica ante el proveedor de autenticación, si se lleva acabo correctamente, este crea un token que le es enviado al usuario. A continuación, el proveedor de autenticación redirecciona nuevamente al usuario a la aplicación A. Cuando el usuario es redireccionado nuevamente a la aplicación A, el cliente ya cuenta con un token, el cual es enviado a la aplicación A para la autenticación. Finalmente, la aplicación A requiere validar el Token contra el proveedor de autenticación, si este es válido, entonces la aplicación A permite al usuario operar.

Puedes aprender más sobre los tokens y la autenticación en mi articulo autenticacion con json web tokens

Ilustración 3 – Autenticación en la aplicación B

Otro escenario a estudiar, es cuando el usuario intenta entrar a una segunda aplicación (Aplicación B) justo después de haber autenticado en la aplicación A. Lo que pasa es muy parecido a lo que acabamos de analizar. Como el usuario ya cuenta con un Token, solo requiere enviar el token al momento de conectarse con la aplicación B, seguido, este valida que el token sea válido con ayuda del proveedor de autenticación, este último le indica a la aplicación B que el token es válido, entonces la aplicación B permite al usuario operar la aplicación.

En caso de que el proveedor de autenticación regresara que el token es invalido, entonces la aplicación redirecciona al usuario al proveedor de autenticación para que inicie sesión nuevamente.

Ventajas y Desventajas

A continuación, listo algunas de las ventajas/desventajas que veo implementar SSO

Ventajas

• Simplifica la forma de autenticación para los usuarios.
• Permite tener una sola credencial para todos los aplicativos.
• Facilita el porte técnico, pues en caso de pérdida de contraseñas, solo modifica en un solo punto.

Desventajas

• Si falla la autoridad de autenticación, es muy probable que no se tenga accesos a las aplicaciones asociadas.
• Un único usuario/password para todas las aplicaciones aumenta el riesgo de seguridad, pues las mismas credenciales dan acceso a todas las aplicaciones.
• Requiere preparar a las aplicaciones para soportar SSO

Conclusiones

Single SingOn se ha convertido es una de las tecnologías favoritas de las compañías, pues en muchas ocasiones, es posible autenticarse a las aplicaciones con tan solo estar logeados en la computadora.

También tenemos los inicios de sesión mediante redes sociales han sido un éxito en la web, pues es posible acceder a páginas con nuestra cuenta de Google, Facebook, Twitter, etc.

En lo general, implementar Single SingOn es una muy buena estrategia, sin embargo, existe escenarios de alta seguridad, en donde tener un solo usuario/password podría ser muy riesgoso, ¿o te imaginas que los códigos nucleares de una nación se activarán con la contraseña de su Twitter?

The post Single SingOn (SSO) appeared first on Oscar Blancarte - Software Architecture.

Concurrencia:

La concurrencia es la capacidad del CPU para procesar más de un proceso al mismo tiempo, ¿simple no? Pero que implica esto realmente. Pues bien, para comprender esto es necesario entender cómo funciona un procesador. Un procesador puede procesar al mismo tiempo el mismo número de procesos que el número de CORES que tiene, de esta forma, si un procesador tiene un CORE, entonces solo podrá ejecutar un proceso a la vez, por otro parte, si tenemos 8 CORES, entonces podremos ejecutar hasta 8 procesos al mismo tiempo.

Ya con este punto claro, solo quedaría agregar que, en la concurrencia, los procesos en ejecución no tienen por qué estar relacionados, es decir, cualquiera puede iniciar y terminar en el momento que sea, y el resultado de uno no afecta al otro.

Paralelismo:

El paralelismo sigue la filosofía de “divide y vencerás”, ya que consiste en tomar un único problema, y mediante concurrencia llegar a una solución más rápido. El paralelismo lo que hace es tomar el problema inicial, dividir el problema en fracciones más pequeñas, y luego cada fracción es procesada de forma concurrente, aprovechando al máximo la capacidad del procesador para resolver el problema. La principal diferencia del paralelismo contra la concurrencia es que, en el paralelismo, todos los procesos concurrentes están íntimamente relacionados a resolver el mismo problema, de tal forma que el resultado de los demás procesos afecta al resultado final.

NOTA: En el paralelismo debe de haber un paso final que se encargue de unir los resultados de todos los procesos para poder arrojar un resultado final.

Puede resultas complicado entenderlo a primera vista, pero observemos la imagen anterior. Primero que nada, llega un proceso grande (Amarillo), el cual es divididos en cuatro partes(Naranja), las cuales coinciden con el número de CORES del procesador(Verde). Ahora bien, por cada CORE disponible se lanza un proceso concurrente para resolver una fracción del problema. Cuando el proceso de un CORE termina, deja su resultado como una parte del resultado final (Naranja), así al terminar todos los procesos concurrentes, tenemos un resultado final (Amarillo).

Escenario del mundo real:

Para comprender mejor como es que funcionan estos dos conceptos veremos un ejemplo simple de cada uno.

Ejemplo de concurrencia:

Empecemos con la concurrencia, imagina una aplicación de descarga de música, en la cual puedes descargar un número determinado de canciones al mismo tiempo, cada canción es independiente de la otra, por lo que la velocidad y el tiempo que tarde en descargarse cada una no afectara al resto de canciones. Esto lo podemos ver como un proceso concurrente, ya que cada descarga es un proceso totalmente independiente del resto.

Observa la imagen, cada descarga se procesa de forma separada, y al final a una descarga no le importa el estado de las demás. Ya que cada descarga es una tarea completamente diferente.

Ejemplo de paralelismo:

En el caso del paralelismo podemos imaginas la clásica página de viajes, donde nos ayudan a buscar el vuelo más barato o las mejores promociones, para hacer esto, la página debe de buscar al momento en cada aerolínea el vuelo más barato, con menos conexiones, etc. Para esto puedo hacerlo de dos formas, buscar secuencialmente en cada aerolínea las mejores promociones (muy tardado) o utilizar el paralelismo para buscar al mismo tiempo las mejores promociones en todas las aerolíneas.

Observemos en la imagen como el proceso parte de una entrada inicial (inputs) los cuales definen las características del vuelo a buscar, luego se utiliza la concurrencia para buscar en las cuatro aerolíneas al mismo tiempo. Veamos que en este proceso es indispensable que las 4 búsquedas terminen para poder arrojar un resultado. Podemos ver claramente la relación entre los 4 procesos, ya que el resultado de uno puedo afectar al proceso final.

Observemos también que una vez que los cuatro procesos terminan, hay un subproceso adicional encargado de unir los resultados y arrojar un resultado final.

Conclusiones:

Podrás observar que si bien, la concurrencia y el paralelismo está muy relacionados, no son la misma cosa, por lo tanto, la concurrencia ayuda a procesar varias tareas al mismo tiempo, mientras que el paralelismo resuelve una única tarea de una forma mucho más eficiente.

The post Concurrencia VS Paralelismo appeared first on Oscar Blancarte - Software Architecture.

Hoy en día es muy común escuchar a los arquitectos de software que su solución es robusta, segura y escalable (Si cómo no!!!), pero la realidad es que pocas aplicaciones están realmente preparadas para ser escaladas, ya que desde su diseño de arquitectura no fueron concebidas para soportarlo o realmente no está muy claro que es realmente escalamiento.

Como ya dijimos, el escalamiento es la capacidad del software para adaptarse al creciente número de usuario, transacciones, etc. ¿pero como un sistema se puede preparar para crecer indeterminadamente? La realidad es que las aplicaciones no pueden crecer infinitamente, por lo que siempre es clave determinar desde el diseño el grado de escalamiento que una aplicación podrá soportar, ya que por más estrategias que utilicemos el sistema ya no dará más.

Puede que los algoritmos utilizados no se puedan optimizarse más o la arquitectura no fue diseñada para un volumen tan alto de carga. Por otro lado, podríamos agregar más memoria al servidor, mas disco duro, cambiar a SSD, poner más cores, mejorar el enfriamiento, etc, etc. Sin embargo, llegara un momento que el hardware no puede crecer más, y tus sistemas simplemente explotaran, tendrás a los directores encima de ti preguntando cada 5 min ¿Qué paso? Y ¿En cuando tiempo quedarán listos los sistemas? El negocio está detenido, no podemos vender, los clientes están enojados, etc, etc, hasta el punto que tú mismo explotes con el sistema (hipotéticamente).

Escalabilidad Horizontal y Vertical

En la práctica existen muchas formas de hacer que un software sea escalable ya que podemos combinar técnicas de software y hardware e incluso arquitecturas de RED (por qué no), pero en esta ocasión me quiere centrar en la escalabilidad horizontal y vertical, porque sin duda es una de las características más importantes para sistemas de alta demanda o uso crítico.

Bien, como ya dijimos existen dos tipos de escalamiento, Horizontal y Vertical, ¿pero que quiere decir cada uno?

Escalabilidad vertical

La escalabilidad vertical o hacia arriba, este es el más simple, pues significa crecer el hardware de uno de los nodos, es decir aumentar el hardware por uno más potente, como disco duro, memoria, procesador, etc. pero también puede ser la migración completa del hardware por uno más potente. El esfuerzo de este crecimiento es mínimo, pues no tiene repercusiones en el software, ya que solo será respaldar y migrar los sistemas al nuevo hardware.

¿Bastante fácil no?, la realidad es que este tipo de escalamiento tiene algunos aspectos negativos, ya que nuestro crecimiento está ligado al hardware, y este; tarde o temprano tendrá un límite, llegara el momento que tengamos el mejor procesador, el mejor disco duro, la mejor memoria y no podamos crecer más o podríamos a lo mejor comprar el siguiente modelo de servidores que nos costara un ojo de la cara y el rendimiento solo mejorar un poco, lo que nos traerá el mismo problema el próximo año.

Ahora bien, no significa que este modelo de escalamiento sea malo, ya que lo podemos combinar con el escalamiento horizontal para obtener mejores resultados.

Ventajas:

• No implica un gran problema para las aplicaciones, pues todo el cambio es sobre el hardware
• Es mucho más fácil de implementar que el escalamiento horizontal.
• Puede ser una solución rápida y económica (compara con modificar el software)

Desventajas:

• El crecimiento está limitado por el hardware.
• Una falla en el servidor implica que la aplicación se detenga.
• No soporta la Alta disponibilidad.
• Hacer un upgrade del hardware al máximo pues llegar a ser muy caro, ya que las partes más nuevas suelen ser caras con respecto al rendimiento de un modelo anterior.

Escalabilidad horizontal

El escalamiento horizontal es sin duda el más potente, pero también el más complicado. Este modelo implica tener varios servidores (conocidos como Nodos) trabajando como un todo. Se crea una red de servidores conocida como Cluster, con la finalidad de repartirse el trabajo entre todos nodos del cluster, cuando el performance del cluster se ve afectada con el incremento de usuarios, se añaden nuevos nodos al cluster, de esta forma a medida que es requeridos, más y más nodos son agregados al cluster.

Para que el escalamiento horizontal funcione deberá existir un servidor primario desde el cual se administra el cluster. Cada servidor del cluster deberá tener un software que permite integrase al cluster, por ejemplo, para las aplicaciones Java, tenemos los servidores de aplicaciones como Weblogic, Widfly, Websphere, etc. y sobre estos se montan las aplicaciones que queremos escalar.

Ventajas:

• El crecimiento es prácticamente infinito, podríamos agregar cuantos servidores sean necesarios
• Es posible combinarse con el escalamiento vertical.
• Soporta la alta disponibilidad
• Si un nodo falla, los demás sigue trabajando.
• Soporta el balanceo de cargas.

Desventajas:

• Requiere de mucho mantenimiento
• Es difícil de configurar
• Requiere de grandes cambios en las aplicaciones (si no fueron diseñadas para trabajar en cluster)
• Requiere de una infraestructura más grande.

Failover

A pesar de que escalamiento vertical no soporta de forma natural la alta disponibilidad, sí que es posible habilitarla mediante una estrategia llamada Failover, la cual consiste en que cuando el servidor falla, mediante hardware se redireccionan las peticiones a un servidor secundario que es un espejo del principal, este servidor normalmente se encuentra en stand by, y solo se habilita cuando el primario falla, de la misma manera, cuando el primario se recupera, el secundario vuelve a pasar a stand by.

Por otra parte, la escalabilidad horizontal ya utiliza de forma natural el Failover, ya que al haber varios nodos, es posible pasar la carga al resto de nodos activos en caso de que uno falle. Ahora bien, esto no garantiza una alta disponibilidad total, ya que si el servidor primario falla puede tumbar todo el cluster, por lo que también se suele utilizar un ambiente espejo del cluster para garantizar la alta disponibilidad. Cabe mencionar que esto solo lo hacen empresas gigantes, ya que administrar dos cluster completos es un verdadero reto.

Failover

Hoy en día que las aplicaciones son parte fundamental de las empresas y que la falla en ellas puede incluso detener la operación de la empresa, llevándolas a perder grandes cantidades de dinero, es por eso que sumamente importante tener en mente el escalamiento de la aplicaciones y siempre tener un plan B en caso de que estas fallen, ¿Te imaginas la cantidad de dinero que perdería por hora, si la página de Amazon se callera? probablemente millones. Es por eso que debemos de estar preparados para escalar nuestras aplicaciones.

Si en este punto aun no estás seguro que escalamiento te va mejor, puedes analizar lo siguiente, si tu aplicación es de baja demanda y el número de usuarios está pensado para crecer poco a poco, la mejor solución puede ser el escalamiento vertical, ahora, si esta misma aplicación a pesar de su poco crecimiento es crítica para el negocio, entonces la puedes combinar con Failover para asegurar la alta disponibilidad.

Por otra parte, si tu aplicación esta pensaba para un crecimiento acelerado y crees que un servidor pueda quedar chico en un corto o mediano plazo, lo mejor será que empieces a pensar en escalamiento horizontal. Ahora bien si además del crecimiento la aplicación es de uso crítico, lo mejor será implementar un Failover. Si ya está utilizando escalamiento horizontal, recuerda que también puedes realizar escalamiento vertical a cada nodo del cluster, siempre y cuando el escalamiento vertical resulte más económico que agregar un nodo más.

Bueno, esas son mis conclusiones, que piensas ahora, ¿estas realmente preparado para el desastre?

The post Escalabilidad Horizontal y Vertical appeared first on Oscar Blancarte - Software Architecture.

SOAP vs REST es una comparación que muchos programadores o incluso arquitectos de software suelen preguntarse a la hora de desarrollar las API para sus sistemas, pero cual es realmente la diferencia que existe entre ellas, ¿Será que una es superior a la otra? ¿Será que REST llego para remplazar a SOAP? Pues bien, en este artículo trataremos de resolver esta gran duda.

Primero que nada, me gustaría aclarar un error muy común que puede hacer que distorsione por completo tu entendimiento con respecto a los Web Services y es que SOA no es igual que SOAP y tener Web Services no significa que tenemos SOA. Hace un tiempo publique un artículo donde hablaba acerca de la Arquitectura SOA por si quieres darle una repasada al tema.
Pues bien, ya con este punto aclaro, debemos entender que SOA (Service-Oriented Architecture) es un tipo de Arquitectura de Software y no una tecnología o producto. SOA es una arquitectura que se base en la integración de aplicaciones mediante Servicios, los servicios representan la medida más granular de la arquitectura, sobre la que se construyen otros artefactos como: composiciones, proxys, fachadas, BPM e incluso API completas. Ahora bien, si SOA tiene como médula espinal los servicios, ¿no son SOAP y REST servicios? ¡Revelador no!!
Entonces si REST y SOAP son en realidad servicios, entonces que diferencia existe entre las dos, cual es el propósito de que existan dos tecnologías que aparentemente hacen lo mismo. Primero entendamos que SOAP y REST siguen la misma Arquitectura (SOA), por lo que las dos deberían de apegarse a los mismos principios.

En este punto nos debe de quedar claro que tanto SOAP como REST son tecnologías que implementan la arquitectura SOA.

Que es SOAP:

Los servicios SOAP o mejor conocimos simplemente como Web Services, son servicios que basan su comunicación bajo el protocolo SOAP (Simple Object Access Protocol) el cual este definido por Wikipedia como “protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML”. Por lo tanto, queda claro que la comunicación se realiza mediante XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las principales diferencias contra REST. Los servicios SOAP funcionan por lo general por el protocolo HTTP que es lo más común cuando invocamos un Web Services, sin embargo, SOAP no está limitado a este protocolo, si no que puede ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc). Pero como comentaba, HTTP es el protocolo principal.

Si bien, me gustaría poner una sección de ventajas y desventajas, la realidad es que estas pueden ser lo contrario dependiendo del punto de vista y la situación concreta del problema a resolver por lo que me gustaría dejar un breve análisis de cuando utilizar SOAP. A mi parecer SOAP sigue siendo el mejor protocolo para la comunicación de Server to Server o Partner to Partner pues es un protocolo mucho más robusto, tiene un tipiado mucho más fuerte, permite agregar metadatos mediante los atributos (cosa que JSON no tiene), permite definir espacios de nombre, evitando la ambigüedad. Por lo mismo, SOAP es un formato más pesado, tanto en tamaño como en procesamiento, pues los XML tiene que ser parseado a un árbol DOM, resolver espacios de nombre (namespaces) antes de poder empezar a procesar el documento. Los XML además tienen métodos de validación muy potentes y ampliamente utilizados, a diferencia de JSON, el cual, si tiene forma de validar, pero no son tan potente y su utilización es pobremente utilizada (no significa que en el futuro no se estandarice su uso).

Nótese que, SOAP solo soporta formato XML, por lo que cuando lo que necesitamos es flexibilidad y un performance superior, podemos optar por REST. Tengo otro artículo donde hablo de XML vs JSON por si quieres profundizar en el tema.

Que es REST

Por otra parte, tenemos REST, el chico nuevo de la cuadra. REST ya tiene unos años, pero en realidad tiene poco que se le empezó a dar la importancia que hoy tiene. REST es una tecnología mucho más flexible que transporta datos por medio del protocolo HTTP, pero este permite utilizar los diversos métodos que proporciona HTTP para comunicarse, como lo son GET, POST, PUT, DELETE, PATCH y a la vez, utiliza los códigos de respuesta nativos de HTTP (404,200,204,409). REST es tan flexible que permite transmitir prácticamente cualquier tipo de datos, ya que el tipo de datos está definido por el Header Content-Type, lo que nos permite mandar, XML, JSON, Binarios (imágenes, documentos), Text, etc. que contrasta con SOAP que solo permite la transmisión de datos en formato XML. A pesar de la gran variedad de tipos de datos que podemos mandar con REST, la gran mayoría transmite en JSON por un motivo muy importante, JSON es interpretado de forma natural por JavaScript, lo que ha hecho que frameworks como Angular y React se aprovechen al máximo, pues pueden enviar peticiones directas al servidor por medio de AJAX y obtener los datos de una forma nativa. Los formularios de HTML pueden ser apuntados a los servicios REST sin ningún problema (por ejemplo).

Otra de las grandes ventajas que presenta JSON sobre SOAP es el performance, ya que los JSON son considerablemente más livianos en peso y mucho más rápido en su procesamiento. Pero como ya vimos, el performance tiene un costo, y es la robustez del mensaje como tal.

Ahora bien, desde mi punto de vista REST debería ser utilizado para obtener datos en aplicaciones WEB que funcionan principalmente con el Modelo MVC del lado del cliente, es decir, que todos los procesamientos se realizan desde el navegador y que solo va al backend para obtener o actualiza la base de datos. Otra de las situaciones es cuando tenemos aplicaciones donde los recursos de procesamiento son bajos y con ancho de banda limitado, como sería el caso de las aplicaciones móviles o robótica.

Te invito a que vas mi articulo “Construir un API REST con NodeJS“, en el cual hablo desde cero como implementar un API REST de la forma más simple y clara, utilizando NodeJS y Express. O puedes puedes ver la guia completa de cómo implementar un API REST con Java desde cero.

Te puede interesar mi video de Youtube”Qué es API REST? – 🚀Y por que es importante aprenderlo 🚀“

SOAP vs REST Conclusiones

Como vimos en este análisis, no hay un claro ganador, pues tanto SOAP como REST siguen siendo muy útiles en condiciones diferentes, incluso existen aplicaciones que ya exponente todas sus API’s en SOAP y REST para asegurar que la integración con ellas sea lo más natural posible sin importar la aplicación con la que se estén integrado.

Cabe mencionar que REST ha estado tomando fuerza a una velocidad impresionante y más con la llegada de NodeJS y las bases de datos NoSQL como MongoDB. Sin embargo, el hecho de que REST tome fuerza, no significa que le esté quitando protagonismo a SOAP, pues recordemos que con la llegada del Internet de las cosas (IOT) cada vez se conectan más dispositivos a internet que necesitan ser integrados (una gran oportunidad para REST) y es donde REST está tomando la delantera.

La verdad es que el futuro no se ve claro, pero lo que, si es que a pesar de que REST siga tomando fuerza, SOAP sigue siendo una tecnología muy robusta y extremadamente utilizada por lo que una cosa si es segura, a SOAP todavía le queda un largo camino.

A pesar de todo este análisis, lo importante es tu qué opinas, ¿cuál crees que sea el futuro?, ¿crees que REST poco a poco matara a SOAP? O ¿simplemente SOAP seguirá funcionando a la par con REST?.

The post SOAP vs REST ¿cual es mejor? appeared first on Oscar Blancarte - Software Architecture.

Cross Reference o Referencias cruzadas es una de las técnicas más utilizadas para la integración de aplicaciones basadas en Arquitectura SOA, en donde las distintas aplicaciones comparten información similar pero replicada en cada una de ellas.  De entrada puede resultar un poco tonto decir que la información se encuentre en varias aplicaciones, sin embargo existen escenarios donde esto es así y en realidad no está mal. Pero antes de debatir este punto me gustaría explicar en qué consiste Cross Reference.

Como funciona Cross Reference

Imaginemos un escenario de la vida real. Estamos a cargo del desarrollo de un ERP, el cual dentro de sus características está la de comunicarse con los proveedores para realizar pedidos de los productos que vendemos desde nuestro B2C (Business To Customer). Estos productos son solicitados a nuestros proveedores por medio de un WebService, el cual nos requiere como entrada los productos a comprar y la cantidad, entre otros datos más, los productos a comprar son indicados al proveedor por medio del ID del producto. El problema viene a continuación, tu pueden vender una Laptop marca ACME modelo XX la cual tiene un ID de producto XYZ, sin embargo este mismo producto para tu proveedor tiene un ID distinto, por ejemplo ABC. En este punto creo que ya somos más conscientes del problema ¿NO?. Sin entrar más en detalle imagina que el área de compras realizar su orden de compra para abastecer el producto bajo en existencia, esto generará la orden con el producto Laptops marca ACME modelo XX con ID XYZ. Aquí tenemos un problema, si yo le mando esa orden a mi proveedor me la rechazará por que el ID no lo reconoce, no sabe que producto le estas solicitando por lo que tendríamos que hacer un mapeo de los ID de nuestros productos con los productos de nuestro proveedor.

Este mapeo se realiza con las tablas XREF o Tablas de referencia cruzada, en la imagen podemos apreciar una tabla llamada products la cual tiene la relación de los ID de los productos con los ID de nuestros partners, de esta manera, cada ID nuestro corresponde contra un ID de nuestro partner. Cuando un producto es enviado al partner este deberá primero mapeado contra nuestra tabla XREF para obtener los ID que correspondan con el partner.

En la imagen podemos ver el proceso por el cual el pedido es procesado, el ERP genera el pedido y lo envía a una integración, el cual podrías ser un servicio o un BPEL para automatizar el proceso, el proceso realizaría el mapeo de claves contra la XREF generando un nuevo documento con los identificadores para el partner especifico.

Tablas XREF

Ya hablamos del proceso en sí, pero no hemos hablado de cómo es que las tablas XREF funcionan y cuál es la estructura que estas tablas deben de tener.  En la actualidad sobresalen dos formatos para estas tablas.

XREF por entidad

Este formato consiste en crear una tabla por cada entidad del sistema, en esta tabla todos los registros que encontremos pertenecerán siempre a la misma entidad como por ejemplo todos los productos, pero solo productos.

En la imagen ponemos un ejemplo de una tabla XREF por entidad, lo primero que vemos es que se llama PRODUCTS aunque el nombre no es relevante, lo segundo es que tenemos una columna llamada ERP, esta columna nos indica el ID del producto en nuestro ERP, la columna PARTNER nos indica el ID del mismo producto pero para nuestro PARTNER.  Para obtener el ID de nuestro partner solo tendremos que lanzar un query muy simple: SELECT PARTNER FROM PRODUCTS WHERE ERP =’XYZ’.

Este modelo tiene el inconveniente de que necesitaremos una tabla por cada entidad que necesitemos mapear, aunque por otro lado nos permite dar privilegios a las aplicaciones solo para las tablas requeridas.

XREF General:

La segunda manera es crear una tabla general en la cual tengamos todas las entidades con una columna especial que nos indica de qué tipo de entidad se trata el registro. De esta manera todas las entidades que se manejen estarán aquí, por ejemplo productos, proveedores, clientes, etc.

En esta tabla podemos ver que se agrega la columna ENTITY, la cual indica de qué tipo de objeto es el registro. Esta tabla funciona de forma muy similar a la XREF por entidad, solo que en esta tendríamos que añadir en la búsqueda el tipo de entidad que estamos buscando, por ejemplo: SELECT PARTNER FROM XREF WHERE ENTITY = ‘PRODUCT’ AND ERP = ‘XYZ’, este query buscara el ID de nuestro partner pero filtrando solo los registros de productos.

XREF para varios partners

Una de las características de las XREF es que nos permiten agregar más de un solo partner, por ejemplo, ¿qué pasaría si un mismo producto no lo puede surtir más de un proveedor?, agregar una tabla XREF por proveedor sería algo muy incómodo e impráctico, por esta razón, a las tablas XREF se les pues agregar una nueva columna por cada partner con el que tenemos comunicación.

En la imagen podemos apreciar que un mismo productos puede estar mapeado contra 3 partner distintos, lo que nos permite en cualquier momento obtener el ID del productos para cualquier de ellos. Es este caso el query cambia un poco según al partner al que nos estemos comunicando, por ejemplo: SELECT PARTNER1 FROM PRODUCTS WHERE ERP = ‘XYZ’, otra variante seria tener una tabla XREF general, en la cual solo agregamos la Entidad que estamos buscando.

Sincronización de las XREF

Otro de los puntos fundamentales para que una tabla XREF funcione, es tener la tabla actualizada, es decir que cada nuevo producto nuevo sea sincronizado, esto se puedo hacer de dos formas, automatizada o manual. Cuando es manual, no hay mucho que decir, pues se requiere de una persona o personas que estén constantemente actualizando los catálogos para que la información cuadre. Este escenario lo dejaremos de lado, ya que lo que nos interesa es automatizar el proceso.

En el escenario que explicamos anteriormente es mucho más complejo automatizar el proceso, pues la creación de los productos no está en nuestro control, y no es posible determinar qué productos es cual en nuestro aplicación, por este motivo expondremos un segundo escenario en el cual la creación de entidades si este bajo nuestro control.

Imaginemos que dentro de nuestra arquitectura tenemos una aplicación CRM desde la cual ofrecemos los productos a nuestros clientes y otra aplicación que se encarga de la facturación, del lado del CRM se crean los productos y se personalizan y desde el lado del facturador se asignan los precios y se generan las facturas mensuales a los clientes. Ambos sistemas comparten los mismos productos pero estos tienen sus propias copias en su base de datos. Cuando el CRM le vende productos a un cliente, este le envía al facturador los productos vendidos, luego el facturador le envía al CRM el detalle de la factura con los productos facturados.

En este punto es más que evidente que cada aplicación tiene su propia copia local del producto, por lo tanto cada uno maneja ID distintos, por otra lado, los productos son creados por el CRM aunque también podrían ser creados por el facturador. La pregunta es ¿Cómo podemos sincronizar los productos?, para resolver esta pregunta veamos la siguiente imagen:

La sincronización se da de la siguiente manera:

1. Un producto es creado en el CRM
2. El CRM ejecuta una integración para replicar el producto a los demás sistemas
3. La integración crea el mismo objeto en el facturador y espera hasta que le regresa el ID generado.
4. El ID del CRM que fue enviado y el ID generado por el facturador son insertados en la tabla XREF.
5. De igual forma, si el facturador crea un nuevo producto este es replicado con la misma técnica.

Si un nuevo sistema es agregado y requiere de la sincronización de productos es simplemente es agregado en el proceso de sincronización y se agrega una columna extra a la tabla para poder guardar el ID generado para este nuevo sistema.

Conclusiones:

Cabe mencionar que esta técnica es implementada por lo fabricantes de Middleware más importantes y en muchos de los casos este tipo de integraciones son vendidas como paquetes para conectar los principales ERP, CRM, etc.  En el caso de Oracle, este los vende como Process Integration Packs o PIP’s que son parte de un paquete llamado AIA o Application Integration Architecture.

Mi recomendación es investigar si nuestros productos ya tienen integraciones previamente desarrolladas que nos permitan ahorrarnos un gran esfuerzo antes de decidir desarrollar nuestras propias integraciones.

The post Integración de aplicaciones con Cross Reference appeared first on Oscar Blancarte - Software Architecture.

La siguiente imagen muestra la estructura del patrón de diseño:

En la imagen podemos apreciar los siguientes elementos:

ICommand: Esta es la pieza más importante del patrón, ya que cada comando deberá implementar esta interface y deberá implementar el método execute, el cual, de forma polimórfica realizara la operación que deseamos. Este componente generalmente es una interface o una clase abstract.

Concrete Command: Para este componente hablaremos en plural, ya que cada Concrete Command que tengamos implementado se convertirá en un comando en nuestro patrón. Este componente tiene que implementar ICommand de forma directa o indirecta y deberá implementar el método execute, en el cual se realizara la operación que deseamos que realice el comando.

Command Manager: Este componente nos servirá para administrar los comandos que tenemos disponibles en tiempo de ejecución, desde aquí podemos ejecutar un Comando o registrar nuevos comandos para que estén disponibles en tiempo de ejecución. Esta clase es importante, ya que de nada sirve tener un conjunto de Concrete Command que implementan ICommand regados por nuestro proyecto si no tenemos un componente que los administre y nos permite ejecutarlos.

Invoker: El invoker representa a la acción que dispara alguno de los comandos, un invoker podría ser un usuario, una aplicación o algún evento generado por nuestra aplicación.

Ya que conocemos los componentes es hora de hablar un poco más del Patrón de diseño, Al comienzo comentamos que nos sirve para realizar operaciones sin conocer realmente que hace la operación. Para lo cual utilizaremos un ejemplo y veremos de qué forma este patrón lo resuelve.

A estas alturas me imagino que todos ya hemos utilizado alguna vez la consola de Windows o Unix. Si observamos la consola, veremos que ella response a base de comandos, estos comandos pueden o no necesitar parámetros para funcionar, lo asombroso aquí es que la consola tiene la característica de saber siempre que operación va a realizar sin tener que decirle que clase o que software utilice para realizar la tarea, ya que la consola es capaz de determinar el comando utilizado y ejecutar el componente o software que realizar la operación deseada.

Otro punto importante es que la consola tiene la característica de agregarle comandos a medida que instalamos nuevo software como es el caso de Java, si intentamos ejecutar el comando java –version, con una computadora la cual no tiene instalado Java veras que te arrojara un mensaje de comando no encontrado, sin embargo si tu ejecutas de nuevo el comando una vez instalado java, entonces obtener un mensaje como el siguiente java version “1.7.0_51″….., En el patrón Command podemos registrar nuevos comandos mediante el componente CommandManager lo cual lo veremos más a delante.

Para analizar mejor este Patrón de diseño analizaremos el ejemplo de la consola y desarrollaremos una mediante el Patrón Command. Para iniciar el ejemplo tendremos que pensar primero en la funcionalidad que le daremos a nuestra consola, en este ejemplo desarrollaremos comandos muy simples pero útiles que ayuden a demostrar la utilidad del patrón, para lo cual les dejo la siguiente imagen:

Podemos identificar a los comandos de forma muy simple ya que son todos aquellos que implementan ICommand de forma directa o indirecta, cada comandos tiene un nombre diferente el cual lo utilizaremos para ejecutarlos desde nuestra consola. La explicación de los comandos está a continuación.

Exit: finaliza la consola y termina con nuestro programa.

Memory: Nos muestra en pantalla la cantidad de memoria total disponible, utilizada y máxima que podemos utilizar.

Batch: Comando que ejecuta en lote un conjunto de comandos definidos en un archivo plano.

Echo: Comando que nos imprime en pantalla lo que escribimos en la consola.

Date: Comando que nos imprime en pantalla la hora y la fecha en el formato que queramos.

File: Comando que nos permite interactuar con archivos, como crear, borrar, escribir, etc.

Dir: Nos permite realizar operaciones con directorios, ya sea crearlos o borrarlos.

WaitHello: Comando que nos permite demostrar la ejecución en segundo plano, este comando al ejecutarse escribe “Hello!” Después de un tiempo determinado.

A demás de los comandos tenemos los Abstract Command, los cuales están representados en el diagrama de color azul, estos comandos no hacen una funcionalidad como tal, sin embargo ayudan a crear otros comandos más complejos, los Abstract Command que tenemos aquí hace lo siguiente:

BaseCommand: Comando que agrega únicamente el método write el cual nos ayuda a escribir en pantalla los eventos generados por nuestros comandos, además de que nos permite tener un método estándar de escritura que podría ser modificado para afectar a todos los comandos, ahorrándonos el problema de modificar cada comando para que escriba de forma distinta.

AsyncCommand: Este comando tiene como finalidad demostrar que también se pueden crear comandos que se ejecuten en segundo plano, este comando tiene la característica que ejecuta la acción en un hilo independiente por lo que podemos seguir trabajando con la consola sin que el comando haya terminado de ejecutarse. Otro punto importante es que implementa el método execute, pero agrega el método abstracto executeOnBackground, en el cual deberemos implementar la función que queremos que realice en segundo plano.

Implementación:

Una vez platicado el escenario podemos pasar a la implementación de la consola.

Clase ICommand: Interface que tiene como propósito definir la estructura mínima de un comando, Esta interface define dos métodos, getCommandName el cual regresa el nombre del comando para uso informativo, También tiene el método execute el cual es implementado por los comandos para realizar la operación deseada, el método recibe un arreglo de String que corresponde a los parámetros del comando y un OutputStream el cual utilizaremos para ir notificando al usuario todas las cosas relevantes como un mensaje o un error.

package javamex.patronesdiseño.command;

import java.io.OutputStream;

public interface ICommand {

    public String getCommandName();

    public void execute(String[] args, OutputStream out);
}

Clase CommanManager: Esta clase es utilizada para gestionar los comandos disponibles en nuestra aplicación, desde esta clase podremos registrar nuevos comandos y recuperar los comandos solicitados por el usuario, La clase contiene los siguientes métodos:

• getCommand: Este método recibe como parámetro un String el cual corresponde al nombre del comando solicitado, El comando es buscado y retornado, pero si un comando no es encontrado se regresa un comando de error el cual explicaremos más a delante.
• registCommand: Método utilizado para registrar los commandos que tendremos disponibles en tiempo de ejecución, para que un comando esté disponible en la aplicación primero tendrá que ser registrado.
• getIntance: Método que nos permite obtener una instancia de la clase CommanManager ya que la esta clase sigue el patrón de diseño Singleton(Hablare de el en otra entrada).

Un punto importante a resaltar el constructor de la clase, en el cual registramos todos los comandos disponibles de forma predefinida para que estén disponibles en tiempo de ejecución, por defecto, cualquier comandos que creemos y que no se encuentre registrados no podrá ser reconocido.

package javamex.patronesdiseño.command;

import java.util.HashMap;
import javamex.patronesdiseño.command.impl.*;

public class CommandManager {

    private static CommandManager commandManager;

    private static final HashMap<String, Class<? extends ICommand>> COMMANDS =
            new HashMap<String, Class<? extends ICommand>>();

    private CommandManager() {
        registCommand(EchoCommand.COMMAN_NAME, EchoCommand.class);
        registCommand(DirCommand.COMMAND_NAME, DirCommand.class);
        registCommand(DateTimeCommand.COMMAND_NAME, DateTimeCommand.class);
        registCommand(MemoryCommand.COMMAN_NAME, MemoryCommand.class);
        registCommand(FileCommand.COMMAND_NAME, FileCommand.class);
        registCommand(ExitCommand.COMMAND_NAME, ExitCommand.class);
        registCommand(BatchCommand.COMMAND_NAME, BatchCommand.class);
        registCommand(WaitAndSayHello.COMMAND_NAME, WaitAndSayHello.class);
    }

    public static synchronized CommandManager getIntance() {
        if (commandManager == null) {
            commandManager = new CommandManager();
        }
        return commandManager;
    }

    public ICommand getCommand(String commandName) {
        if (COMMANDS.containsKey(commandName.toUpperCase())) {
            try {
                return COMMANDS.get(commandName.toUpperCase()).newInstance();
            } catch (Exception e) {
                e.printStackTrace();
                return new ErrorCommand();
            }
        } else {
            return new NotFoundCommand();
        }
    }

    public void registCommand(String commandName, 
            Class<? extends ICommand> command) {
        COMMANDS.put(commandName.toUpperCase(), command);
    }
}

Commandos: Las siguientes clases representan las implementaciones de los comandos que tendremos disponibles en la aplicación, los cuales fueron registrados en el constructor de CommandManager. Las clases siguientes representan los comandos que analizamos en la figura 2.

Clase ExitCommand: Comandos que termina con la aplicación. Este comando implementa ICommand por lo que representa unos de los comandos más simples de la aplicación.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;
import javamex.patronesdiseño.command.ICommand;

public class ExitCommand implements ICommand {

    public static final String COMMAND_NAME = "exit";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        System.exit(0);
    }
}

Clase BaseCommand: Esta clase implementa ICommand, sin embargo no es como tal un comando ya que es una Clase Abstracta, Esta clase fue diseñado como ejemplo para servir como una base para los demás comandos que imprimen un mensaje en pantalla, esta clase únicamente agrega el método write, El cual es utilizados para que todos los comandos impriman en pantalla los mensajes de una forma controlada, ya que si decidimos cambiar la forma que se escribe solo tendremos que cambiar este método y todas las clases que la heredan serán afectadas.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;
import javamex.patronesdiseño.command.ICommand;

public abstract class BaseCommand implements ICommand {

    @Override
    public abstract String getCommandName();

    @Override
    public abstract void execute(String[] args, OutputStream out);

    public void write(OutputStream out, String message) {
        try {
            out.write(message.getBytes());
            out.flush();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Clase DirCommand: Comando que nos permite crear o borrar una carpeta de nuestro FileSytem, el comando recibe como parámetro la operación a realizar (crear o borrar {-N|-D}) más la ruta de la carpeta.

package javamex.patronesdiseño.command.impl;

import java.io.File;

import java.io.OutputStream;

import java.nio.channels.WritableByteChannel;

public class DirCommand extends BaseCommand {

    public static final String COMMAND_NAME = "dir";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        if (args == null || args.length < 2) {
            write(out, COMMAND_NAME + " argumentos insuficientes");
        }
        String operation = args[0];
        if ("-D".equals(operation.toUpperCase())) {
            write(out, deleteDir(args[1]));
        } else if ("-N".equals(operation.toUpperCase())) {
            write(out, newDir(args[1]));
        } else {
            write(out, "Se esperaba una operación correcta -d | -n");
        }
    }

    private String deleteDir(String url) {
        try {
            File file = new File(url);
            if (!file.exists()) {
                return "El archivo no existe";
            }
            if (!file.canWrite()) {
                return "Privilegios insuficientes";
            }
            file.delete();
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }

    private String newDir(String url) {
        try {
            File file = new File(url);
            if (file.exists()) {
                return "El archivo ya existe";
            }
            file.mkdirs();
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }
}

FileCommand: Comando que nos permitirá realizar operaciones con archivos, las operaciones son las siguientes:

• WRITE_APPEND = -WA: Permite escribir en un archivo conservando el contenido existente previamente. Recibe dos parámetros, el primero corresponde al path del archivo y el segundo el contenido a escribir
  
• WRITE_OVERRIDE = -WO: Permite escribir en un archive sobrescribiendo su contenido. Recibe dos parámetros, el primero corresponde al path del archivo y el segundo el contenido a escribir.
  
• WRITE_NEW = -WN: Permite crear un archive y luego escribir en él. Recibe dos parámetros, el primero corresponde al path del archivo y el segundo el contenido a escribir.
  
• RENAME_FILE = -R: Permite renombrar un archive existente. Recibe dos parámetros, el primero corresponde al path del archivo y el segundo corresponde al nuevo nombre.
  
• DELETE_FILE = -D: Permite borrar un archive. Recibe únicamente el path del archivo a eliminar.
  

package javamex.patronesdiseño.command.impl;

import java.io.File;
import java.io.FileOutputStream;
import java.io.FileWriter;
import java.io.OutputStream;
import java.util.Arrays;

public class FileCommand extends BaseCommand {

    public static final String COMMAND_NAME = "file";
    private static final String WRITE_APPEND = "-WA";
    private static final String WRITE_OVERRIDE = "-WO";
    private static final String WRITE_NEW = "-WN";
    private static final String RENAME_FILE = "-R";
    private static final String DELETE_FILE = "-D";

    @Override
    public void execute(String[] args, OutputStream out) {
        if (args.length < 2) {
            write(out, "Parametros insuficientes");
            return;
        }
        String operation = args[0].toUpperCase();
        String[] reduce = Arrays.copyOfRange(args, 1, args.length);
        if (WRITE_APPEND.equals(operation)) {
            write(out, writeAppend(reduce));
        } else if (WRITE_NEW.equals(operation)) {
            write(out, writeNew(reduce));
        } else if (WRITE_OVERRIDE.equals(operation)) {
            write(out, writeOverride(reduce));
        } else if (RENAME_FILE.equals(operation)) {
            write(out, renameFile(reduce));
        } else if (DELETE_FILE.equals(operation)) {
            write(out, deleteFile(reduce));
        } else {
            write(out, "No se encontro la operacion {" + WRITE_APPEND + "|" + WRITE_NEW + "|" + WRITE_OVERRIDE + "|" + RENAME_FILE + "|DELETE_FILE}");
        }
    }

    private String renameFile(String[] args) {
        String filePath = args[0];
        String newFileName = args[1];
        try {
            File file = new File(filePath);
            file.renameTo(new File(newFileName));
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }

    private String writeOverride(String[] args) {
        String filePath = args[0];
        String fileContent = args[1];
        try {
            File file = new File(filePath);
            if (!file.exists()) {
                if (!file.createNewFile()) {
                    return "ERROR: Error al crear el archivo";
                }
            }
            FileWriter fileW = new FileWriter(file);
            fileW.write(fileContent.toCharArray());
            fileW.flush();
            fileW.close();
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }

    private String writeAppend(String[] args) {
        String filePath = args[0];
        String fileContent = args[1];
        try {
            File file = new File(filePath);
            if (!file.exists()) {
                return "ERRRO: El archivo no existe";
            }
            FileWriter fileW = new FileWriter(file, true);
            fileW.append(fileContent);
            fileW.flush();
            fileW.close();
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }

    private String writeNew(String[] args) {
        String filePath = args[0];
        String fileContent = args[1];
        try {
            File file = new File(filePath);
            if (file.exists()) {
                return "ERRRO: El archivo ya existe";
            }
            if (!file.createNewFile()) {
                return "ERROR: No fué posible crear el archivo";
            }
            FileWriter fileW = new FileWriter(file);
            fileW.write(fileContent.toCharArray());
            fileW.flush();
            fileW.close();
            return "";
        } catch (Exception e) {
            return "ERROR: " + e.getMessage();
        }
    }

    private String deleteFile(String[] args) {
        String filePath = args[0];
        File file = new File(filePath);
        if (!file.delete()) {
            return "No fué posible eliminar el archivo";
        }
        return "";
    }

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }
}

EchoCommand: Comando que únicamente imprime en pantalla lo que se escribe. Como un Eco.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;
import java.util.Arrays;

public class EchoCommand extends BaseCommand {

    public static final String COMMAN_NAME = "echo";

    @Override
    public void execute(String[] args, OutputStream out) {
        String message = getCommandName() + " " + Arrays.toString(args);
        write(out, message);
    }

    @Override
    public String getCommandName() {
        return COMMAN_NAME;
    }
}

DateCommand: Comando que nos permite conocer la fecha y hora del sistema en el formato que deseemos. El comando únicamente recibe como entrada el formato en el que queremos ver la fecha y hora.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;
import java.text.SimpleDateFormat;
import java.util.Date;

public class DateTimeCommand extends BaseCommand {

    public static final String COMMAND_NAME = "date";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        SimpleDateFormat dateFormater = null;
        if (args == null) {
            dateFormater = new SimpleDateFormat("dd/MM/yyyy hh:mm:ss");
        } else {
            try {
                dateFormater = new SimpleDateFormat(args[0]);
            } catch (Exception e) {
                write(out, "formato invalido");
                return;
            }
        }
        String date = dateFormater.format(new Date());
        write(out, date);
    }
}

MemoryCommand: Comando sin parámetros que nos arroja la información de la memoria que utiliza nuestra aplicación.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;

public class MemoryCommand extends BaseCommand {

    public static final String COMMAN_NAME = "memory";

    @Override
    public String getCommandName() {
        return COMMAN_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        double heap = Runtime.getRuntime().totalMemory() / 1000000d;
        double heapMax = Runtime.getRuntime().maxMemory() / 1000000d;
        double heapFree = Runtime.getRuntime().freeMemory() / 1000000d;
        String salida = "Heap: " + heap + "nMax Heap: " 
                + heapMax + "nFree Heap: " + heapFree;
        write(out, salida);
    }
}

BatchCommand: Commando complejo que nos permite abrir un archivo de comandos, este archivo es parecido a los archivos en batch ya que podemos escribir un conjunto de comandos que serán ejecutados en el orden en el que se encuentran en el archivo(Se asume que cada línea es un comando). El comando únicamente recibe como parámetro el Path del archivo a ejecutar.

package javamex.patronesdiseño.command.impl;

import java.io.File;
import java.io.FileInputStream;
import java.io.OutputStream;
import java.util.Arrays;
import javamex.patronesdiseño.command.CommandManager;
import javamex.patronesdiseño.command.CommandUtil;
import javamex.patronesdiseño.command.ICommand;

public class BatchCommand extends BaseCommand {

    public static final String COMMAND_NAME = "batch";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        if (args == null || args.length < 1) {
            write(out, "Número de parametros invalido");
            return;
        }
        CommandManager manager = CommandManager.getIntance();
        String[] lines = readLinesFromFile(args[0]);
        for (String line : lines) {
            String[] argsCommand = CommandUtil.tokenizerArgs(line);
            ICommand command = manager.getCommand(argsCommand[0]);
            String[] reduce = Arrays.copyOfRange(argsCommand, 1, argsCommand.length);
            command.execute(reduce, out);
            write(out, "n");
        }
        write(out, "Batch executado");
    }

    private String[] readLinesFromFile(String filePath) throws RuntimeException {
        File file = new File(filePath);
        FileInputStream stream = null;
        try {
            if (!file.exists()) {
                throw new RuntimeException("Archivo no encotrado");
            }
            stream = new FileInputStream(file);
            byte[] byteArray = new byte[stream.available()];
            stream.read(byteArray);
            String commands = new String(byteArray);
            String[] lines = commands.split("n");
            return lines;
        } catch (Exception e) {
            throw new RuntimeException(e.getMessage());
        } finally {
            try {
                stream.close();
            } catch (Exception e2) {}
        }
    }
}

AsyncCommand: Esta clase al igual que BaseCommand no es como tal un comando ya que es una Clase Abstract, esta clase tiene como propósito demostrar que podemos implementar comandos que se ejecuten en segundo plano o de forma asíncrona.

Esta clase agrega el método executeOnBackground en el cual deberemos implementar la funcionalidad que deseamos que realice el comando. Ya que el método original execute es sobre escritor para ejecutar el método executeOnBackground en un hilo independiente.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;

public abstract class AsyncCommand extends BaseCommand {

    public void execute(final String[] args, final OutputStream out) {
        new Thread(new Runnable() {
            public void run() {
                executeOnBackground(args, out);
            }
        }).start();
    }

    public abstract void executeOnBackground(String[] args, OutputStream out);
}

Clase WaitAndSeyHello: Comando que extiende de AsyncCommand, lo cual lo convierte automáticamente en un comando que se ejecuta en segundo plano. Ha este comando únicamente se le envía un tiempo en milisegundos, el cual lo utilizara para esperar este tiempo antes de decir Hello! .

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;

public class WaitAndSayHello extends AsyncCommand {

    public static final String COMMAND_NAME = "waithello";

    @Override
    public void executeOnBackground(String[] args, OutputStream out) {
        if (args == null || args.length < 1) {
            write(out, "Parametros insuficientes");
            return;
        }
        Long time = null;
        try {
            time = Long.parseLong(args[0]);
        } catch (Exception e) {
            write(out, "Tiempo inválido");
            return;
        }

        try {
            Thread.sleep(time.longValue());
            write(out, "Hello!!");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }
}

Clase ErrorCommand: Este comando no esté definido en nuestro diagrama y es utilizado por el CommandManager únicamente para regresar un Error al intentar instanciar un comando. Este comando no puede ser ejecutado por el cliente ya que no es un comando registrado, sin embargo CommandManager lo maneja como un comando propio del sistema para representa un error.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;

import java.nio.channels.WritableByteChannel;

public class ErrorCommand extends BaseCommand {

    private static final String COMMAND_NAME = "ERROR";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        String message = "Error al invokar el comando";
        write(out, message);
    }
}

Clase NotFoundCommand: Comando parecido a ErrorCommand pero este es regresado cuando un comando no es encontrado.

package javamex.patronesdiseño.command.impl;

import java.io.OutputStream;

public class NotFoundCommand extends BaseCommand {

    private static final String COMMAND_NAME = "NOT FOUND";

    @Override
    public String getCommandName() {
        return COMMAND_NAME;
    }

    @Override
    public void execute(String[] args, OutputStream out) {
        write(out, "Commando no encontrado");
    }
}

Otra clase que se utiliza es CommandUtil, la cual la utilizamos únicamente para procesar los datos tecleados por el usuario y dividir las instrucciones en tokens, los tokes pueden ser el nombre del comando y los parámetros. La regla que se sigue para dividir los comandos es la siguiente.

Cada palabra separada por un espacio es considera como un token a excepción que se encuentre en medio de comillas dobles, ejemplo “Hola Mundo”, en este caso toda la oración es considera un único token.

package javamex.patronesdiseño.command;

import java.util.ArrayList;

import java.util.Arrays;

import java.util.List;

public class CommandUtil {

    public static String[] tokenizerArgs(String args) {
        List<String> tokens = new ArrayList<String>();
        char[] charArray = args.toCharArray();
        String contact = "";
        boolean inText = false;
        for (char c : charArray) {
            if (c == ' ' && !inText) {
                if (contact.length() != 0) {
                    tokens.add(contact);
                    contact = "";
                }
            } else if (c == '"') {
                if (inText) {
                    tokens.add(contact);
                    contact = "";
                    inText = false;
                } else {
                    inText = true;
                }
            } else {
                contact += c;
            }
        }
        if (contact.trim().length() != 0) {
            tokens.add(contact.trim());
        }
        String[] argsArray = new String[tokens.size()];
        argsArray = tokens.toArray(argsArray);
        return argsArray;

    }
}

Hasta este momento ya tenemos definidos el CommandaManager y todos los comandos que utilizaremos, sin embargo no tenemos un mecanismo que nos ayude interactuar con los comandos, para eso tenemos la clase CommandMain, la cual servirá de invoker, Esta clase se cicla para solicitar al usuario comandos desde la consola.

package javamex.patronesdiseño.command;

import java.util.Arrays;
import java.util.Scanner;

public class CommandMain {

    public static void main(String[] args) {
        System.out.println("Command Line is Start");
        CommandManager manager = CommandManager.getIntance();
        Scanner in = new Scanner(System.in);
        while (true) {
            String line = in.nextLine();
            if ("EXIT".equals(line.toUpperCase())) {
                System.exit(0);
            }
            if (line.trim().length() == 0) {
                continue;
            }
            String[] commands = CommandUtil.tokenizerArgs(line);
            String commandName = commands[0];
            String[] commandArgs = null;
            if (commands.length > 1) {
                commandArgs = Arrays.copyOfRange(commands, 1, commands.length);
            }
            ICommand command = manager.getCommand(commandName);
            command.execute(commandArgs, System.out);
            System.out.println("");
        }
    }
}

Ejecución:

Finalmente, ya tenemos listo todo, por lo que comenzaremos ejecutando la aplicación y tendremos como resultado lo siguiente:

Iniciaremos ejecutando el comando date y le pediremos que nos arroje la fecha en el formato “DD/MM/YYYY”, seguido le pediremos la hora en el formato “HH:MM:SS” y finalmente le pediremos fecha y hora el formato “DDMMYYYY HHMMSS” para lo cual utilizaremos la nomenclatura estándar de java para la fecha y hora la cual podremos apreciar en la siguiente pagina https://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html.

Para el siguiente ejemplo, utilizaremos el comando Dir para crear un nuevo directorio y luego lo borraremos.

Para el siguiente ejemplo utilizaremos el comando echo para decir “Hola Mundo”.

Para el siguiente ejemplo utilizaremos el comando File para crear un nuevo archivo de texto y escribir en el “Hola Mundo”

El siguiente comando a utilizar es Memory, El cual nos dará datos acerca de la memoria de la aplicación.

Utilizaremos nuevamente el comando File para renombrar el archivo dummy.txt a helloword.txt

Hasta aquí, solamente hemos ejecutado comandos síncronos, pero en este ejemplo ejecutaremos el comando WaitAndSeyHello, el cual lo ejecutaremos y le diremos que espere 10 segundos antes de decir Hello!.

Después de esperar 10 segundos tenemos el siguiente resultado.

En el siguiente ejemplo ejecutaremos el comando Batch el cual lee un archivo de texto y ejecuta todos los comandos que tenemos en el, para este ejemplo ejecutaremos el comando y le diremos que lea un archivo en la ruta c:/dummy/batch.txt el cual tendrá el siguiente contenido:

date dd/MM/yyyy hh:mm:ss
dir -n "c:/dummy/dummy2"
echo "Se creo el archivo dummy2"
file -wn "c:/dummy/dummy2/dummy.txt" "Hola mundo con el comando file"
memory
file -r "c:/dummy/dummy2/dummy.txt" "c:/dummy/dummy2/dummy2.txt"
date dd/MM/yyyy hh:mm:ss

Lo que esperemos que realice el comando es lo siguiente: imprime la fecha y hora, cree el directorio c:/dummy/dummy2, escriba en pantalla Se creó el archivo dummy2″, cree un archivo en “c:/dummy/dummy2/dummy.txt” con el contenido “Hola mundo con el comando file”, imprima en pantalla los datos de la memoria, renombre el archivo que acabamos de crear y le ponga de nombre dummy2.txt y finalmente imprima nuevamente la fecha y hora.

Otra cosa que podemos intentar es ejecutar un comando que no existe, por ejemplo “java”, el cual nos indicara que no fue encontrado.

Finalmente ejecutamos el comando Exit, el cual terminara con la aplicación.

Hasta este punto ya habremos creado una consola que es capaz de ejecutar comandos, los cuales serán ejecutados sin saber realmente que clase está realizando el trabajo, sin embargo en la vida real no nos interés saber cómo es atendido un comando siempre y cuando realice la tarea que esperamos que realice. Y como ya vimos con el patrón de diseño Command esto es posible.

Ya con esta base tú podrás crear nuevos comandos y registrarlos al CommandManager para que los puedes utilizar en tu consola, también podrías crear un comando que se encargue de registrar nuevos comandos desde algún Jar para que esté disponible desde la consola. O podrías modificar la forma en la carga los comandos al inicio para que lea algún archivo de configuración.

Acabamos de ver uno de los muchos aplicativos que tiene el Patrón de diseño Command, Si tú tienes alguna experiencia con este patrón por favor coméntala.

Ya está a la venta mi nuevo libro “Introducción a los patrones de diseño“, en donde expongo los 25 patrones de diseño más utilizados y explicados desde un enfoque del mundo real, con ejemplos que pueden ser aplicados en tus proyectos. Sin duda es unos de los libros más completos de patrones de diseño en español.

The post Patrón de diseño Command appeared first on Oscar Blancarte - Software Architecture.