VA UNA CANCIÓN PARA ANIMARSE - SHERYL CROW - MAS ACTUAL QUE NUNCA

 

PROGRAMACIÓN ORIENTADA A ASPECTOS CON SPRING BOOT - PARTE III

AOP de Spring

A continuación, se describen una serie de puntos claves del Framework de trabajo AOP de Spring:

1.- Todos los consejos que se crean en Spring se escriben en una clase estándar de Java. Los puntos de corte que definen dónde se aplica el consejo pueden especificarse con anotaciones o en XML en el archivo de configuración de Spring.

2.- Spring aconseja los objetos en tiempo de ejecución.

3.- Los aspectos de Spring se implementan como proxy que empaquetan el objeto de destino. El proxy gestiona las invocaciones de métodos, aplica lógica de aspectos adicional y, después, invoca el método de destino.

4.- Spring solo admite puntos de cruce de método. Es una diferencia con respecto a otros Framework de trabajo AOP, que proporcionan puntos de cruce de constructor y de campo además de los de método.

Definir puntos de corte

En la siguiente lista se indican los diferentes designadores que se pueden usar en AOP de Spring para definir puntos de corte:

args()

Limita las coincidencias del punto de cruce a la ejecución de aquellos métodos cuyos argumentos son instancias de los tipos dados.

@args()

Limita las coincidencias del punto de cruce a la ejecución de aquellos métodos cuyos argumentos sed anotan con los tipos de anotación proporcionados.

execution()

Hacer coincidir los puntos de cruce que son ejecuciones de métodos.

this()

Limita las coincidencias de puntos de cruce a aquellas en las que la referencia de bean del proxy AOP es de un tipo determinado.

@target()

Limita las coincidencias de puntos de cruce cuando la clase de un objeto en ejecución cuenta con una anotación del tipo dado.

within()

Limita la coincidencia a los puntos de cruce de ciertos tipos.

@within

Limita la coincidencia a los puntos de cruce dentro de ciertos tipos que cuenten con la anotación dada.

@annotation

Limita las coincidencias de puntos de cruce a aquellos en los que el asunto del punto de cruce cuenta con la anotación dada.

DEFINIR UN ASPECTO

Para definir un aspecto se debe declarar una clase y anotarla con @Aspect. Dentro de la clase, los métodos se anotan con anotaciones de consejo para indicar cuándo deben invocarse.

A continuación, se indican las diferentes anotaciones para definir aspectos:

@After

El método de consejo se invoca después de que el método aconsejado devuelva o genere una excepción.

@AfterReturning

El método de consejo se invoca después de que el método aconsejado devuelva un resultado.

@AfterThrowing

El método de consejo se invoca después de que el método aconsejado genere una excepción.

@Around

El método de consejo encapsula al método aconsejado.

@Before

El método de consejo se invoca antes de ejecutarse el método aconsejado

Ejemplo

Para ilustrar el uso de aspectos en Spring, se necesita un elemento que sea el sujeto de los puntos de corte del aspecto.

Para ello, se va a definir la clase Estudiante:

package com.sergio.memoria;

public class Estudiante {

    public void realizarExamen() {

        System.out.println(“Realizar examen.”);

    }

}

Por otro lado, se va a definir la clase PadreEstudiante como aspecto que se aplica al estudiante.

package com.sergio.memoria;

import org.aspectj.lang.annotation.AfterReturning;

import org.aspectj.lang.annotation.AfterThrowing;

import org.aspectj.lang.annotation.Aspect;

import org.aspectj.lang.annotation.Before;

@Aspect

public class PadreEstudiante {

    @Before(“execution(* com.sergio.memoria.Estudiante.realizarExamen(..))”)

    public void apuntarAcademia() {

        System.out.println(“Apuntar al hijo a una academia que lo prepare.”);

    }

    @AfterReturning(“execution(*           com.sergio.memoria.Estudiante.realizarExamen(..))””)

public void falicitarHijo() {

    Sysment.out.println(“Felicitar al hijo por la calificación obtenida.”);

}

@AfterThrowing(“execution(* com.sergio.memoria.Estudiante.realizarExamen(..))”)

public void pedirHijoMayorEsfuerzo() {

    System.out.println(“Pedir al hijo mayor esfuerzo para el siguiente examen.”);

}

}

PadreEstudiante dispone de tres métodos que describen acciones que los padres de un estudiante pueden realizar a la hora de que sus hijos hagan un examen.

Antes del examen, el padre apunta al hijo a una academia que lo prepare para el mismo. Si en el examen se consigue una buena calificación, el padre al hijo por su resultado. Pero si no es así, el padre le debe pedir al hijo que se esfuerce más en el siguiente examen.

PROGRAMACIÓN ORIENTADA A ASPECTOS PARTE II

PROGRAMACIÓN ORIENTADA A ASPECTOS

En el desarrollo de software, las funciones que abarcan varios puntos dentro de una aplicación se denominan preocupaciones transversales. Por lo general, estas preocupaciones se encuentran conceptualmente separadas de la lógica de negocio de la aplicación.

La Programación orientada a aspectos (AOP) entra en acción a la hora de separar estas preocupaciones transversales de la lógica de negocio.

¿Qué es la Programación orientada a aspectos?

Como se ha indicado con anterioridad, una preocupación transversal puede definirse como cualquier funcionalidad que afecta a varios puntos de una aplicación. Por ejemplo, la seguridad es una preocupación transversal, ya que varios métodos de una aplicación pueden contar con normas de seguridad aplicados a estos.

La AOP permite definir la funcionalidad común en una ubicación y cómo y dónde se va a aplicar, de forma declarativa, sin necesidad de modificar la clase a la que se ve a aplicar esta nueva característica.

Las preocupaciones transversales pueden modularizarse en clases especiales llamadas aspectos. Esto ofrece dos ventajas:

1.- La lógica de cada preocupación se encuentra ahora en una única ubicación, en lugar de encontrarse repartida por todo el código.

2.- Los módulos de servicio son más claros, ya que solo van a contener el código de su preocupación principal, mientras que las transversales se han transferido a los aspectos.

Terminología AOP

Los aspectos suelen definirse en términos de consejo, puntos de corte y puntos de cruce.

Consejo

Los aspectos tienen un propósito, es decir, un trabajo para el que se han creado. En términos de AOP, al propósito de un aspecto se le denomina consejo.

Los consejos definen tanto el qué como el cuándo de un aspecto. Además de describir el trabajo que un aspecto debe llevar a cabo, los consejos deben responder a la pregunta de cuándo deben llevarlo a cabo.

1.- Antes: La funcionalidad del consejo tiene lugar antes de que el método se invoque.

2.- Después: La funcionalidad del consejo tiene lugar después de que finalice el método, con independencia del resultado.

3.- Después de la devolución. La funcionalidad del consejo tiene lugar después de que el método se complete con éxito.

4.- Después de la generación: La funcionalidad del consejo tiene lugar después de que el método genere un error.

5.- Alrededor: El consejo encapsula el método, lo que proporciona cierta funcionalidad antes y después del método invocado.

Puntos de cruce

Un punto de cruce es aquel punto de la ejecución de la aplicación al que puede conectarse un aspecto.

Son los puntos en los que el código de los aspectos puede insertarse en el flujo normal de la aplicación para añadir un nuevo comportamiento.

Puntos de corte

Un aspecto no tiene que aconsejar a todos los puntos de cruce de una aplicación. Los puntos de corte ayudan a reducir los puntos de cruce aconsejados por un aspecto.

Si el consejo define el qué y el cuándo de los aspectos, los puntos de corte definen el dónde.

Un aspecto combina los consejos y los puntos de corte. De forma conjunto, definen todo lo que lo que debe hacerse sobre un aspecto: qué hacer, dónde hacerlo y cuándo debe hacerse.

 

PROGRAMACIÓN ORIENTADA A ASPECTOS (AOP) I PARTE

Programación orientada a aspectos

En el desarrollo de software, las funciones que abarcan varios puntos dentro de una aplicación se denominan preocupaciones transversales. Por lo general, estas preocupaciones se encuentran conceptualmente separadas de la lógica de negocio de la aplicación (aunque suelen encontrarse incluidas de forma directa en ésta). Una de estas preocupaciones, presentes en la gran mayoría de las aplicaciones, sería la seguridad.

Separar estas preocupaciones transversales de la lógica de negocio es donde la programación orientada a aspectos (AOP) entra en acción. Se puede pensar en los aspectos como mantas que cubren varios componentes de una aplicación. En su núcleo, una aplicación está formada por módulos que implementan funcionalidades de negocio. Con la AOP se puede cubrir la aplicación principal con capas de funcionalidad. Estas capas pueden aplicarse de forma declarativa a lo largo de una aplicación de forma flexible, sin que el núcleo de la aplicación ni siquiera sepa que existen.

Mientras que la DI ayuda a desacoplar los objetos de una aplicación entre sí, la AOP ayuda a desacoplar las preocupaciones transversales de los objetos a los que afectan.

MESH MICROSERVICES - MALLA DE MICROSERVICIOS (entrada en desarrollo)

NOS HACEMOS VIEJOS Y CONTRA ESO NO SE PUEDE LUCHAR - PERO DE ALGUNA FORMA LO CONSEGUIMOS

 

Tecnología BLOCKCHAIN

El BLOCKCHAIN cambiará el mundo de forma similar o mayor a cómo lo ha hecho el Internet a cómo lo ha hecho el Internet en estos últimos 20 años.

¿Qué es él blockchain?

Blockchain es una invención de una persona o grupo de personas conocido por el seudónimo, Satoshi Nakamoto. Pero desde entonces, se ha convertido en algo más mencionado en referencia al bitcoin. Al permitir que esta información digital se distribuya pero no se copie, la tecnología blockchain creó la columna vertebral de un nuevo tipo de Internet. Originalmente ideado para la moneda digital, Bitcoin, la comunidad tecnología. Wipro, Infosys, Microsoft e IBM ofrecen soluciones basadas en blockchain para una amplia variedad de propósitos. Ethereum es una plataforma basada en blockchain desplegada públicamente con soporte para contratos inteligentes. En lugar de utilizar una cadena de bloques para transacciones de criptomonedas, piense en ella como una cadena de bloques para ejecutar cualquier tipo de aplicación.

Blockchain como una base de datos distribuida

Imagínate una hoja de cálculo que se duplica miles de veces en una red de ordenadores. Luego imagina que esta red está diseñada para actualizar regularmente esta hoja de cálculo y tienes una comprensión básica de blockchain. La información contenida en una cadena de bloques existe como una base de datos compartida y continuamente reconciliada. Esta es una forma de usar la red que tiene beneficios obvios. La base de datos blockchain no se almacena en ninguna ubicación única, lo que significa que los registros que guarda son realmente públicos y fácilmente verificables. No existe una versión centralizada de esta información par que un hacker corrompa. Alojado por millones de ordenadores simultáneamente, sus datos son accesibles para cualquier persona en Internet. Es como un registro financiero compartido donde más datos pueden ser agregados.

Imagínate el número de documentos legales que deben usarse de esa manera. En lugar de pasárselos, perder el rastro de las versiones y no estar sincronizado con la última versión. ¿por qué no compartir todo el documento comercial en lugar de transferirse de un lado a otro? Tantos tipos de contratos legales serían ideales para ese tipo de flujo de trabajo. No necesitas una cadena de bloques para compartir documentos, pero la analogía de documentos compartidos es poderosa.

Características del blockchain:

La tecnología Blockchain es como Internet, ya que tiene una robustez incorporada. Al almacenar bloques de información que son idénticos en toda su red, el blockchain.

1.- No puede ser controlado por cualquier entidad única. No pertenece a ningún banco mundial, un banco puede restringir el retiro de dinero diario, congelar fondos, o restringir cuentas bancarias, no así con criptomonedas en la tecnología blockchain, como el bitcoin.

2.- No tiene un solo punto de falla, una transacción de blockchain no puede ser hackeada, por lo que es mucho más seguro que una transacción de una tarjeta de crédito.

3.- Es transparente e incorruptible. La red blockchain vive en un estado de consenso, uno que se comprueba automáticamente cada diez minutos. Una especie de ecosistema de auto auditoría de un valor digital.

4.- Es descentralizado. Todo lo que sucede en él es una función de la red como un todo. Algunas implicaciones importantes se derivan de esto. Al crear una nueva forma de verificar transacciones, los aspectos del comercio tradicional podrían volverse innecesarios. Los intercambios bursátiles se convierten casi simultáneamente en la cadena de bloques, por ejemplo, o podría hacer que los tipos de mantenimiento de registros, como un registro de la propiedad, sean completamente públicos. Y la descentralización ya es una realidad.

Usos del blockchain:

La cadena de bloques ofrece a los usuarios de Internet la capacidad de crear valor y autenticar la información digital, que darán lugar a las nuevas aplicaciones comerciales.

1.- Contratos Inteligentes (Smart Contract) En el nivel actual de desarrollo de la tecnología, los contratos inteligentes pueden programarse para realizar funciones simples. Por ejemplo, un derivado podría pagarse cuando un instrumento financiero cumpla con ciertos puntos de referencia, con el uso de la tecnología blockchain, lo que permite que el pago se automatice.

En 2015, el Depository Trust & Clearing Corp. (DTCC) utilizó un registro blockchain para procesar más de $1.5 billones de valores, lo que representa 345 millones de transacciones.

2.- La economía compartida. Con empresas como Uber (prohibida en muchas ciudades de España) y AirBnB floreciendo, la economía compartida ya es un éxito comprobado. Actualmente, sin embargo, los usuarios que desean llamar a un servicio de uso compartido deben confiar en un intermediario como Uber. Al permitir los pagos de igual a igual, la cadena de bloques abre la puerta a la interacción directa entre las partes, se obtiene una economía de intercambio verdaderamente descentralizada. Un ejemplo temprano, OpenBazzar usa blockchain para crear un eBay peer-to-peer. Descargue la aplicación en su dispositivo informático y puede realizar transacciones con proveedores de OpenBazzar sin pagar tarifas de transacción.

3.- Crowdfunding. Las iniciativas de Crowdfunding como Kickstarter y Gofundme están haciendo un trabajo avanzado para la economía emergente de igual a igual. La popularidad de estos sitios siguiere que las personas quieren  tener una opinión directa en el desarrollo de productos. Blockchain lleva este interés al siguiente nivel, creando potencialmente fondos de capital de riesgo de origen multitudinario.

4.- En los gobiernos: Al hacer que los resultados sean totalmente transparentes y accesibles al público, la tecnología de base de datos distribuida podría brindar transparencia total a las elecciones o cualquier otro tipo de encuesta. Los contratos inteligentes basados en Ethereum ayudan a automatizar el proceso. En la práctica, esto significa que la gobernabilidad de la compañía se vuelve completamente transparente y verificable al administrar activos digitales, capital o información.

5.- Auditoría de la cadena de suministro. Los consumidores desean cada vez más saber que las afirmaciones éticas que hacen las empresas sobre sus productos son reales. Los libros de contabilidad distribuidos proporcionan una manera fácil de certificar que el récord de las cosas que compramos son genuinas. La transparencia viene con una marca de fecha basada en blockchain de una fecha y una ubicación, por ejemplo, en diamantes éticos, que corresponde a un número de serie. Provenance, con sede en el Reino Unido, ofrece auditorías de la cadena de suministro para una amplia gama de bienes de consumo.

Haciendo uso de Ethereum blockchain, un proyecto piloto de Provenance asegura que los pescados vendidos en los restaurantes de shushi en Japón hayan sido cosechados de manera sostenible por sus proveedores en Indonesia.

6.- Logística: Un programa piloto exitoso entregado por la empresa de tecnología de logística Marine Transport International (MTI) ha demostrado que la industria de la logística verá mejor conectividad, eficiencia y seguridad gracias a blockchain.

Cualquier tipo de negocio de la cadena de suministro, sea marino, aéreo o terrestre, puede aprovechar este sistema, los ahorros de costos que prevemos son tal elevados como el 90%, como el resultado de procesos sustancialmente simplificados.

7.- Sector bancario: Más de $ 200 mil millones se pierden cada año por los bancos debido al fraude, según un informe de Forbes. Para los bancos, el aspecto más atractivo de Blockchain es la seguridad que les brinda a ellos y a sus clientes. En el caso de las compañías bancarias que usan tecnología blockchain, cada cliente tendría un número de identificación único en lugar de su nombre. Además, solo tendrían la clave primaria, impidiendo el acceso a sus fondos incluso por el propio banco. Estas medidas de seguridad han hecho que Bitcoin y otras criptomonedas sean seguras, y también pueden hacer que los depósitos de los banqueros sean seguros.

8.- Energia Solar: Siemens recientemente presentó una micro red en Brooklyn, Nueva York. Puedes tomar ese “micro” de forma bastante literal: la cuadrícula consta de cinco casas en un lado de la calle y cinco casas en el otro. Los vecinos podrán intercambiar electricidad directamente entre ellos a través de una blockchain. No es la primera iniciativa de blockchain en energía: a principios de este año, SolarCoin, una moneda digital para energía renovable basada en tecnología blockchain, anunció una integración similar. Estamos en los primeros tiempos de una interrupción completa de la red eléctrica, que es una buena noticia para la energía renovable y distribuida. Y blockchain lo está haciendo todo posible.

9.- Bienes raíces: Las oficinas de registro de condado y las compañías de seguro de títulos mantienen varias bases de datos de registros de propiedad de propiedad (estoy flipando). Esta información incluye la dirección, los propietarios anteriores y actuales, y diversos gravámenes como las hipotecas. Antes de Internet, el gobierno y las compañías de títulos eran necesarios para verificar y registrar los datos de propiedad. ¿Cómo puede Blockchain reemplazar a estos intermediarios?

Blockchain permitirá que todas las propiedades, en todas partes, tengan una dirección digital correspondiente que contenga ocupación, finanzas, desempeño legal, construcción y atributos físicos que transmita perpetuamente y mantenga todas las transacciones históricas.

Además, los datos estarán disponibles de forma inmediata en línea y se pueden correlacionar en todas las propiedades. La velocidad de transacción se acortará de días / semanas / meses a minutos o segundos.

Fuente: Daniel Praniuk

Pues yo personalmente todo esto por ahora no lo veo y creo que la información es del 2020, y estamos en 2022.

Pronto código

Paciencia pronto subo código, estoy buscando un formateador de código para que se pueda ver claro... 

Un saludo...

Melena de unos años antes de marzo del 2020, me parece a mi que esa melena ya no vuelve, voy rapado al 0.5 como en la "chaqueta metálica", al menos parecer ser que sigo vivo, después de ya 2 años y medio de pandemia y cosas varias que mejor no entrar a comentar... Un saludo a todos. Cuando tenga montado el microservicio os subiré configuración y código...

Ejemplo de visión monolítica vs visión microservicio

Accedemos a una página web de una tienda para realizar compras.

Hay un servidor que está ejecutando el código de la aplicación y de vez en cuando se conecta a una base de datos para recuperar información. Cuando un usuario compra un producto vía web, se mostrarán los productos disponibles. La aplicación responderá según haya sigo programada y mostrará el inventario, pagos o envíos. Esta información se empaqueta en un único archivo ejecutable. De ahí el nombrarlo arquitectura monolítica.

Si se realiza un cambio en cualquiera de los módulos, se tendrá que subir a producción un código nuevo, aunque los otros módulos no hayan sido modificados. Si la aplicación no es compleja, la subida será sencilla ya que en este caso tenemos un solo archivo ejecutable.

En el caso de microservicios, en vez de tener un único ejecutable, cada componente del sistema es un único servicio que se comunicará con los otros a través de llamadas.

Contamos con una interfaz web en la que interactúan los usuarios y por debajo los servicios de pagos, inventario y envíos.

Con respecto a la visión monolítica tenemos:

1.- Los microservicios pueden desplegarse de manera independiente: si realizamos un cambio en uno de los módulos, no se verán afectados los otros módulos y solo tendremos que subir ese módulo.

2.- Es fácil de entender y dividir, pues las secciones del negocio están bien separadas.

3.- Cada microservicio es multifuncional: tiene una parte de base de datos, de Back-end y es independiente de los demás.

Comparación de SOA con Microservicios

 Comparación de SOA con Microservicios

Primero surgió la arquitectura orientada a objetos y más adelante la orientada a componentes. Pero no fue hasta 1996 cuando se desarrolló por primera vez SOA. Con ésta se desarrollaban todos los servicios necesarios y se empaquetaban en un archivo WAR para poder desplegarse en un servidor de aplicaciones, como por ejemplo Tomcat, que se encontraba dentro de una máquina. Esto puede verse en la Figura 2.3.

Todos estos servicios tenían que estar implementados en el mismo lenguaje y no se les podía asignar más recursos a cada uno de ellos. Era asignado a todo el conjunto, dividiendo el archivo WAR en varias máquinas o réplicas de esta. Para ello se necesitaba un balanceador de carga que determinaba que máquina iba a atender la petición.

Todo esto será suficiente para las empresas. A día de hoy cuando una aplicación monolítica (SOA) crece demasiado es difícil mantenerla y añadir nuevas funcionalidades, ya que cada línea modificada implica redesplegar toda la aplicación, lo que puede llevar mucho tiempo pues en los despliegues están involucrados varios departamentos de la empresa que impide al equipo seguir desarrollando. También es complicado encontrar el origen de algún error en el código.

La necesidad por resolver todos estos problemas desembocó en la arquitectura de microservicios. La primera vez que se mencionó la palabra “microservicios” fue en 2011 en una conferencia sobre computación en la nube, donde el Dr. Peter Rogers se refirió a ello para describir la arquitectura que estaban usando grandes empresas como Netflix, Facebook, Amazon o Paypal.

Los microservicios gestionan la complejidad dividiéndose funcionalmente en un conjunto de servicios pequeños e independientes. Con esto se consigue que el equipo de desarrollo sea capaz de implementar varias funcionalidades a la vez, sin toar el código de otra funcionalidad y desplegar cada módulo por separado, donde cada microservicio está separado del resto y pueden o no tener una base de datos común.

El cambio más notable respecto a SOA es que los equipos de desarrollo tienen una mayor responsabilidad, lo que se traduce en una gran facilidad, ya que manejan todo lo siguiente: proceso de desarrollo, despliegues en distintos entornos, gestión de contendores como Kubernetes, etc. Todo esto antes se tenía que realizar en otros departamentos de la empresa aumentando tiempos de producción. La arquitectura de microservicios resuelve todos los problemas que presenta SOA y cada vez es más popular, pero aún está en su base de inicio, y aún le queda mucho por mejorar y evolucionar.

Rajest RV en su libro “Spring Microservices” nos muestra que se observa cómo es más rápido y ágil el desarrollo de aplicaciones con microservicios frente a aplicaciones tradicionales. Menciona que, “Los microservicios prometen más agilidad, velocidad de entrega y escala. En comparación con las aplicaciones monolíticas tradicionales”.

Un aspecto que mejorar es la seguridad, ya que cuando se descompone una aplicación en cientos de microservicios aparecen dificultades en la depuración, monitoreo, auditoría y análisis de toda la aplicación. Los atacantes podrían aprovechar esta complejidad para atacar.

Lo que sí es seguro es que han surgido para quedarse y cada vez más empresas están empezando a utilizar los microservicios.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TDD Purista o NO Purista

Profesor Luis Fernández en Escuela IT

PATRONES DE ARQUITECTURA

 Patrones de arquitectura

Por otra parte, también existen los patrones arquitectónicos o arquetipos, los cuales tienen un nivel superior de abstracción, es decir, no especifican cómo escribir el código, pero sí cómo debe estar organizado y que elementos son importantes en la aplicación. Estos al igual que los patrones de diseño, solucionan problemas recurrentes de una forma reutilizable.

 Los patrones de arquitectura más usados son: 

1.- Programación por capas: Utilizada para estructurar programas que pueden descomponerse en subtareas. Normalmente cuenta con tres capas, en una de ellas se implementa la lógica de negocio, en otra los datos y en otra la presentación de los datos ya tratados. Es uno de los arquetipos más usados hoy en día.

2.- Cliente-Servidor: Este patrón consta de dos partes: un servidor y múltiples clientes, el servidor será el que dé servicio a diversos componentes del cliente y los clientes solicitarán servicio al servidor. En esta arquitectura se separan las capas en varias máquinas físicas, normalmente se utiliza 2 o 3 niveles. Si utilizáramos dos niveles tendríamos la capa de presentación en una máquina del cliente y el tratado de lo datos con la base de datos en otra máquina. En la de 3 niveles se pondría cada capa en un servidor diferente con la mejora de la escalabilidad.

3.- Arquitectura orientada a servicios (SOA): Es la que da soporte a los requerimientos del negocio mediante la creación de servicios. Un servicio corresponde a un requerimiento funcional del negocio, por ejemplo: Un cliente necesita saber el stock de un determinado producto, por lo que se crea un servicio que consulte en la base de datos la cantidad de producto disponible.

4.- Arquitectura de microservicios: Utilizada para crear aplicaciones usando un conjunto de pequeños servicios, los cuales se comunican entre sí, pero se ejecutan de forma individual.

5.- Pipeline: Utilizado para organizar sistemas que procesan una sucesión de datos. Estos datos pasan a través de tuberías (que son una combinación de comandos que se ejecutan de forma simultánea, donde el resultado de la primera se envía de entrada para el siguiente). Las tuberías se usan para almacenar datos en un buffer o para la sincronización de estos.

6.- Arquitectura en pizarra: Se utiliza para la resolución de problemas de los cuales se desconoce su estrategia. Está formado por tres componentes:

1.- Pizarra: memoria que contiene todos los objetos.

2.- Fuente de conocimiento: son módulos especializados.

3.- Componente de control: encargado de seleccionar y ejecutar los módulos.

7.- Arquitectura dirigida por eventos: Maneja principalmente los eventos y está formado por cuatro componentes que son: fuente de evento, escucha de evento, canal y bus de evento.

8.- Peer-to-peer: Se llama pares a las componentes individuales y estos pueden funcionar como servidor, dando servicio a otros pares, o como cliente, pidiendo servicio a otros países.

9.- Modelo Vista Controlador: Divide un programa interactivo en tres partes:

1.- Modelo: está formado por los datos básicos y contiene la funcionalidad del programa.

2.- Vista: maneja la visualización de la información.

3.- Controlador: encargado de controlar la entrada (teclado y ratón) del usuario e informar al modelo y la vista de los cambios de acuerdo a los requerimientos.

Permite desacoplar los componentes y reutilizar el código más eficientemente. Siempre que se desarrolla un servicio web es necesario establecer un protocolo de comunicación con la aplicación, las dos más importantes son SOAP y REST. SOAP es un protocolo que establece que el intercambio de mensajes se va a realizar por medio de XML. REST es un protocolo basado en HTTP que para el intercambio de mensajería utiliza JSON o XML, aunque es más habitual con JSON ya que es más rápido.

NACI LIBRE

 

ES CASI SÁBADO POR LA NOCHE...

 

MÁS ARQUITECTURA HEXAGONAL

 Frameworks (marcos) y Drivers (controladores).

La capa más externa generalmente se compone de marcos y herramientas como la Base de datos, el Framework, etc. Generalmente, no se escribe mucho código en esta capa que no sea el código de cola que se comunica con el siguiente círculo hacia adentro.

Esta capa es donde van todos los detalles. La web es un detalle. La base de datos es un detalle. Mantenemos estas cosas en el exterior donde pueden hacer poco daño.

¿Sólo cuatro círculos?

No, los círculos son esquemáticos. Puedes encontrar que necesitas más que estos cuatro. No hay una regla que diga que siempre debe tener solo estos cuatro. Sin embargo, la regla de dependencia siempre se aplica. Las dependencias del código fuente siempre apuntan hacia adentro. A medida que avanzas, el nivel de abstracción aumenta. El círculo más exterior es el detalle de hormigón de bajo nivel. A medida que avanza hacia el interior, el software se vuelve más abstracto y encapsula políticas de nivel superior. El círculo más interno es el más general.

Cruzando las fronteras

En la parte inferior derecha del diagrama hay un ejemplo de cómo cruzamos los límites del círculo. Muestra a los Controladores y Presentadores que se comunican con los Casos de Uso en la siguiente capa. Tenga en cuenta el flujo de control. Comienza en el controlador, se mueve a través del caso de uso y luego termina ejecutándose en el presentador. Tenga en cuenta también las dependencias del código fuente. Cada uno de ellos apunta hacia adentro hacia los casos de uso.

Normalmente resolvemos esta aparente contradicción usando el principio de inversión de dependencia. En un lenguaje como Java, por ejemplo, organizaríamos interfaces y relaciones de herencia de modo que las dependencias del código fuente se opongan al flujo de control en los puntos correctos a lo largo del límite.

Por ejemplo, considere que el caso de uso debe llamar al presentador. Sin embargo, esta llamada no debe ser directa porque eso violaría la Regla de dependencia: ningún hombre en un círculo exterior puede ser mencionado por un círculo interno. Así que tenemos el caso de uso, llamar a una interfaz (que se muestra aquí como Puerto de salida del caso de uso) en el círculo interno, y hacer que el presentador en el círculo externo lo implemente.

La misma técnica se utiliza para cruzar todos los límites en las arquitecturas. Aprovechamos el polimorfismo dinámico para crear dependencias de código fuente que se oponen al flujo de control para que podamos cumplir con la Regla de dependencia, sin importar en qué dirección vaya el flujo de control.

Fuentes: Libro gratuito Internet.

ARQUITECTURA HEXAGONAL - Adaptadores de interfaz

Adaptadores de interfaz

El software en esta capa es un conjunto de adaptadores que convierten los datos desde el formato más conveniente para los casos de uso y las entidades, al formato más conveniente para algún agente externo, como la Base de Datos o la Web. Es esta capa, por ejemplo, la que contendrá por completo la arquitectura MVC de una GUI. Los presentadores, vistas y controladores pertenecen todos a esta capa. Es probable que los modelos sean sólo estructuras de datos que pasan de los controladores a los casos de uso y luego regresan de los casos de uso a los presentadores y las vistas.

De manera similar, los datos se convierten, en esta capa, desde la forma más conveniente para las entidades y los casos de uso, a la forma más conveniente para cualquier estructura de persistencia que se esté utilizando, es decir, la base de datos. Ningún código hacia el interior de este círculo debe saber nada sobre la base de datos. Si la base de datos es una base de datos SQL debe estar restringido a esta capa, y en particular a las partes de esta capa que tienen que ver con la base de datos.

También en esta capa se encuentra cualquier otro adaptador necesario para convertir datos de algún formato externo, como un servicio externo, al formulario interno utilizado por los casos de uso y las entidades. 

Fuente: libro de la red, gratuito.

ARQUITECTURA HEXAGONAL un par de conceptos

Principio de inversión de dependencia (DIP)

En el siguiente ejemplo, el DIP se aplicó al desacoplar nuestros casos de uso de los repositorios. Recordemos el DIP y luego navegaremos a través de un ejemplo:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de las abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Veamos cómo apliqué este principio en el siguiente ejemplo:

En el lado izquierdo encontramos en rojo una aplicación en capas en la que DepositUseCase depende de la implementación de AccountSQLRepository. Es una forma acoplada de escribir código. En el lado derecho, en azul, al agregar un IAccountRepository y aplicar DIP, el AccountSQLRepository tiene su dependencia apuntando hacia dentro.

El DepositUseCase es el módulo de alto nivel que no depende de los detalles de la base de datos, sino que depende de la abstracción de IAccountRepository.

IAccountRepository es la abstracción que no depende de los detalles de la base de datos.

El AccountSQLRepository es el módulo de bajo nivel que depende de la abstracción IAccountRepository.

Esa es la idea principal detrás de la Arquitectura Hexagonal, siempre que nuestra aplicación requiera un servicio externo, usamos el puerto (una interfaz simple) e implementamos el Adaptador detrás de la abstracción.

Separación de preocupaciones (SoC)

Nuestra aplicación requiere algunas capacidades externas, pero a la aplicación no le preocupan los detalles de su implementación, solo sus abstracciones son visibles para la capa de la aplicación. Aplicamos SoC creando límites alrededor de los adaptadores y permitiendo que se desarrollen y prueben de forma aislada. Es una buena práctica tener paquetes diferentes para cada implementación de Adaptador.

Podríamos tener un Adaptador específico para una base de datos SQL y un Adaptador específico para el Almacenamiento de Azure, ambos podrían reemplazarse con poco esfuerzo. Esa es la idea detrás de la arquitectura hexagonal, mantener las opciones abiertas el mayor tiempo posible y la capacidad de retroceder si es necesario.

Todas las arquitecturas tienen el mismo objetivo común, que es la “separación de intereses”, para dar como resultado sistemas que son:

1.- Independientes de frameworks: no nos atamos a ninguna librería de software ni al soporte de los proveedores.

2.- Testeables: las reglas de negocio se pueden probar sin la interfaz de usuario, BD, servidor web u otro elemento externo.

3.- Independiente de la interfaz de usuario: podría cambiarse fácilmente.

4.- Independiente de la Base de Datos: las reglas de negocio no están vinculadas a la tecnología de Base de Datos utilizada.

5.- Independiente de cualquier agente externo: de hecho, las reglas de negocio no conocen nada sobre el mundo exterior.

Fuente: libro gratuito de Internet.

(Creo que fácil de entender)

ARQUITECTURA HEXAGONAL - CRÍTICA

 

Fuente: Escuela IT, Profesor Luis Fernández

2h 30m crítica sobre Arquitecturas Agiles

(espero que tenga permiso)

veo desde el 2018 más o menos como una moda radical sobre el tema ágil, metodologías, arquitecturas etc. Pero no he visto ninguna crítica constructiva hacia ese tipo de orientar un proyecto o aplicación informática, aquí el profesor Luis Fernández, docente también de Escuela IT lo desgrana todo en 2h 30m de contenido, creo bajo mi humilde opinión como desarrollador o programador de toda la vida, que después de 30 años de profesión, en el mundo hispano han tardado en llegar este tipo de arquitecturas como por ejemplo la de microservicios y que encima como siempre se están aplicando diríamos que bastante mal.

En eXtreming Programming por ejemplo de Kent Beck la jerarquía es horizontal y no vertical, con lo cual lo típico de echarle la culpa y las horas extras sin pagar es siempre del junior o del senior recién llegado a un proyecto, cuando la culpa no es de nadie en la base, será en todo caso de la organización.

¿Qué opináis sobre esta reflexión?

Spring Cloud Netflix Eureka

¿Cómo funciona Spring Cloud Netflix Eureka?

Eureka es un servicio REST que permite al resto de microservicios registrarse en su directorio. Esto es muy importante, puesto que no es Eureka quien registra los microservicios, sino los microservicios los que solicitan registrarse a Eureka.

Cuando un microservicio registrado en Eureka arranca, envía mensaje a Eureka indicándole que está disponible. El servidor Eureka almacenará la información de todos los microservicios registrados así como su estado. La comunicación entre cada microservicio y el servidor Eureka se realiza mediante heratbeats cada X segundos. Si Eureka no recibe un heartbeat de un tipo determinado pasados 3 intervalos, el microservicio será eliminado del registro. Además de llevar el registro de los microservicios activos, Eureka también ofrece al resto de microservicios la posibilidad de “descubrir” y acceder al resto de microservicios registrados. Por ello Eureka es considerado un servicio de registro y descubrimiento de microservicios.

Una vez entendido su funcionamiento vamos a pasar a la implementación y configuración de un Servicio Spring Cloud Eureka que permita registrar y monitorizar el resto de microservicios desplegados.

Fuente: Miguel Doctor Yuste

Beneficios y desventajas de microservicios

Ventajas

Divide los componentes de una aplicación en varios servicios independientemente, teniendo diferentes servicios independientemente, teniendo diferentes servicios como parte de la aplicación.

Los componentes de servicio se pueden implementar en diferentes máquinas virtuales en función a su carga de trabajo.

Más expectativas para los servicios subyacentes, con respecto al lenguaje de programación, dado que cada servicio es una entidad separada, cada servicio puede estar escrito en un lenguaje diferente.

Los servicios pueden ser fácilmente reemplazados o actualizados, entrega continua.

Desventajas

Mayor complejidad, el desarrollo puede ser riesgoso cuando la funcionalidad es muy compleja para ser fragmentada en servicios.

Mayor gestión, se debe asegurar que todos los desarrolladores conozcan cada uno de los servicios, esto implica un alto nivel de comunicación del equipo.

Mayor complicación en relación a infraestructura, el uso de memoria puede ser alta y requerir el uso de Gateway o contenedores.

Pruebas más confusas, al estar la funcionalidad fragmentada puede llevar a que las pruebas no sean tan claras o simples como en una aplicación monolítica.

MALDITA CANCION

 

CIBERSEGURIDAD PARTE I

El ciberespacio se reconoce como un nuevo dominio de las operaciones, al lado de los de tierra, mar, aire y espacio”.

La historia de los conflictos bélicos nace con dos dominios: tierra y agua. Cuando aparecen los primeros aviones, se abre un nuevo escenario en los cielos y comienza el temido espacio aéreo como una herramienta de combate que desestabilizaba cualquier batalla. Estos tres dominios fueron los dominantes hasta muy pasada la segunda guerra mundial.

Recordemos que luego de esta última, comienza lo que todos conocimos como “guerra fría”. Esta etapa histórica es muy importante para lo que trataremos más adelante, pues este tipo de guerra se definía por una “capacidad potencial” que tenía un determinado país, y sobre esa base podía disuadir más o menos a sus oponentes. La escalada nuclear llevó a una nueva doctrina denominada “Destrucción Mutua Organizada”, o también “Mutua Destrucción Asegurada”. Como su nombre lo indica con total claridad, este nuevo escenario nos lleva a un conflicto en el cual su nivel de escalada ocasionaría un nivel de destrucción que afectaría al planeta en su totalidad. Cabe mencionar que esta doctrina está aún vigente y continuamos viendo a diario cómo diferentes países siguen avanzando en esta línea, ignorando que es un camino de autodestrucción asegurado…

Estos nuevos misiles, comenzaron a elevar sus alturas de vuelo, llegando a lo que conocemos como espacio. Un hito muy significativo sucedió hace pocos años cuando el gobierno chino tuvo la brillante ocurrencia de derribar con un misil un satélite de su propio país. Con ello demostró que estaba en capacidad de hacerlo con cualquier otro. A caballo de estos hechos, se acuerda en definir un nuevo dominio de conflicto: el espacio.

Hoy en día, todos sabemos que ese mismo satélite chino, podría haber sido igualmente dejado fuera de combate si comprometemos sus sistemas informáticos o de telecomunicaciones. Esta realidad aplica también a los sistemas de un barco, avión, sistema antiaéreo, de comunicaciones, sistemas (Comando Control Comunicaciones e Informática), un misil, un tanque, etc.

Volviendo a nuestro texto, con el dominio del espacio, se presentaban cuatro escenarios de conflicto. Como acabamos de desarrollar, en la actualidad es posible dejar fuera de combate por medio de un “Ciberataque” las más sofisticadas maquinarias bélicas, entonces es natural lo que se ha decido en Varsovia y reconozcamos como un nuevo dominio el “Ciberespacio”, con lo cual podemos concluir que los dominios para el arte de la guerra son:

1.- Tierra

2.- Mar

3.- Aire

4.- Espacio

5.- Ciberespacio

En los tiempos de la guerra fría, el avance nuclear iba determinando la capacidad de “tierra arrasada”. Es decir, un país que tuviera suficiente fuerza nuclear podía arrasar un territorio al completo, este fue un el hecho desencadenante de la rendición de Japón luego de Hiroshima y Nagasaki. Por otro lado, si su rival también posee un nivel semejante, llegamos nuevamente a la “Mutua Destrucción Asegurada”. Ante esta realidad los países conscientes de ello, poco a poco fueron adoptando medidas para tranquilizar a la población mundial e intentar demostrar que no tienen de in siquiera “aproximarse” a esta situación, aunque continuamos viendo ciertos estados al límite de la demencia que no lo ven así.

Sea cual fuere el enfoque, cuando aún se consideraban “cuatro dominios” e Internet no entraba en juego, el tema era radicalmente distinto por las siguientes razones:

1.- Identificación del enemigo o agresor

2.- Hipótesis de conflicto

3.- Mutua Destrucción Asegurada

4.- Capacidad bélica

5.- Tipo de respuesta

6.- Por último, el gran interrogante:

El ciberespacio ¿Es un dominio militar?

Metaverso I. "La visión de Stephenson sobre el metaverso el autor de Snow Crash novela de Ciencia Ficción"

Snow Crash proporciona un caso único sobre el uso del metaverso, enseñando cómo podría ser puesto en práctica, cómo podría ser utilizado, cómo podría interconectarse con el mundo real y complementarlo…

También tiene la importancia de la anticipación, ya que fue escrito antes de que se pudiera poner en práctica en el ciberespacio, y entonces mucho de lo que Stephenson propone, puede ser visto como una profunda descripción de los requisitos necesarios para concretar un metaverso, y ello se está volviendo muy relevante, ya que las implementaciones modernas están empezando a afrontar los problemas que en la novela se describían.

En la obra de Neal Stephenson, el Metaverso se presenta a sus usuarios como un entorno urbano, desarrollado en torno a una única carretera de 100 metros de ancho denominada la Calle (Street) que recorre totalmente la circunferencia de 65536 km (216 km) de una esfera perfecta de color negro, carente de detalle. El estado virtual pertenece a la "Global Multimedia Protocol Group", que es la parte ficticia de la "Association for Computing Machinery", y está disponible para ser comprado, para después allí construir edificios. Al ser una realidad virtual que no tiene porque obedecer a las leyes de la Física, el tamaño y la forma de los edificiosestá sujeto sólo a la voluntad de quienes lo levantan (y al espacio que puedan comprar, obviamente), pudiendo contratar arquitectos para que los diseñen, o diseñándolos ellos mismo si no disponen del dinero necesario o tienen el ánimo para hacerlo.

Los usuarios del Metaverso acceden a él a través de terminales personales que proyectan una imagen de realidad virtual de gran calidad en unas gafas que utiliza el usuario, o a través de terminales públicas en cabinas, que ofrecen una imagen de baja calidad, en blanco y negro y granulada. stephenson también describe una subcultura de gente que prefiere estar continuamente conectada a terminales portables, llevando gafas y otros equipamientos. Este tipo de personas son llamados "gárgolas", debido a su apariencia grotesca. Los usuarios viven su experiencia en primera persona.

Dentro del metaverso, los usuarios individuales aparecen como iconos (avatares) de cualquier forma, con la única restricción de la altura, "para evitar por ejemplo que la gente tenga una altura de una milla". El transporte en el metaverso está limitado a los existentes en la realidad, a pie, o en vehículo (por ejemplo el monorail, que recorre toda la Calle parando en 256 paradas express —Express Ports—, localizadas en intervalos de 256 km, o en paradas locales —Local Ports—, situadas a un kilómetro una de otra); quienes tengan conocimientos de programación pueden crearse vehículos propios (motocicletas por ejemplo) capaces de alcanzan velocidades enormes debido a que no están afectados por las leyes de la física o la termodinámica del mundo real.

Fuente: un libro bajado de la red gratuito no tiene autor.

Principios del Software Libre - entrada muy corta

“El software libre es una cuestión de la libertad de los usuarios de ejecutar, copiar, distribuir, estudiar,

cambiar y mejorar el software. Más precisamente, significa que los usuarios de programas tienen las cuatro

libertades esenciales.

• La libertad de ejecutar el programa, para cualquier propósito (libertad 0).

• La libertad de estudiar cómo trabaja el programa, y cambiarlo para que haga lo que usted quiera

(libertad 1). El acceso al código fuente es una condición necesaria para ello.

• La libertad de redistribuir copias para que pueda ayudar al prójimo (libertad 2).

• La libertad de distribuir copias de sus versiones modificadas a terceros (la 3ª libertad). Si lo hace, puede dar a toda la comunidad una oportunidad de beneficiarse de sus cambios. El acceso al código fuente es una condición necesaria para ello.” 

Este empieza a contar desde 0 como en un arreglo en un lenguaje como Java o C#

Fuente: lo he encontrado en un libro gratuito que me baje