Mg. Ing.

José Alberto Gómez Avila

(PARTE I):
SOLUCIONES WEB Y APLICACIONES DISTRIBUIDAS
Mg. Ing. José Alberto Gómez Avila

Tabla de contenido
SPRING – BOOT ............................................................................................................................. 3
Objetivos del Spring Boot:......................................................................................................... 3
Spring Boot CLI .......................................................................................................................... 3
Requerimientos: ........................................................................................................................ 3
Esquema de Funcionamiento de Spring MVC: .......................................................................... 4
Esquema de Funcionamiento de Spring MVC ........................................................................... 4
SPRING SECURITY ......................................................................................................................... 4
ANGULAR ...................................................................................................................................... 5
Implementación Genérica de Angular ...................................................................................... 6
Arquitectura Angular ................................................................................................................. 6
Librerías de Angular .................................................................................................................. 7
Root Module ............................................................................................................................. 7
Servicios Web ............................................................................................................................... 8
SOAP – REST .................................................................................................................................. 9
SOAP .......................................................................................................................................... 9
Arquitectura SOAP .................................................................................................................. 10
Modo de Funcionamiento: ...................................................................................................... 10
REST ......................................................................................................................................... 10
ARQUITECTURA SOA .................................................................................................................. 12
FUNDAMENTOS DE SOA.......................................................................................................... 12
CARACTERISTICAS DEL SOA ..................................................................................................... 14
SOA desde el punto de vista de la tecnología: ........................................................................ 15
SOA desde el punto de vista de la tecnología ......................................................................... 17
Agilidad en el negocio articulada por SOA .............................................................................. 17
Estrategias de Adopción de SOA ............................................................................................. 18
Enfoques de Adopción de SOA ................................................................................................ 18
Cómo y por qué están implementando SOA las organizaciones actuales .............................. 19
Facilitadores tecnológicos clave de SOA ................................................................................. 20
Mg. Ing. José Alberto Gómez Avila

SPRING – BOOT

Spring Boot simplifica la creación de aplicaciones de aplicaciones y servicios Spring

extendiendo el concepto de Runtime configurando por debajo el AppServer, Contextos
de Spring, monitorización, etc., todo basado en una aproximación Convention-Over-
Configuration.

Spring Boot apunta a facilitar la creación de aplicaciones que usan Spring,

proporcionando un conjunto de configuraciones por defecto para cada módulo a usar,
de esta manera el desarrollador java tiene que introducir cambios sólo cuando no desea
obtener configuraciones por defecto.

Spring Boot permite crear aplicaciones standalone o despliegues WAR.

Objetivos del Spring Boot:

Los objetivos de Spring Boot son:

 Proveer una forma muy sencilla de arrancar desarrollos Spring.
 Ofrecer funcionalidad “out-of-the-box” (características implementadas por
defecto), pero se permite incorporar las peculiaridades personalizadas del
proyecto.
 No necesita desplegar archivos WAR, sin compilación previa.
 Proporciona una serie de características no funcionales comunes a los proyectos
(por ejemplo, anotaciones, servidores embebidos, seguridad, indicadores,
configuración externalizada).
 Spring Boot también ofrece una línea de commandos que ejecute los scripts
Groovy (Spring Boot CLI).

Spring Boot CLI

Herramienta de línea de comandos que se utiliza para desarrollar rápidamente con

Spring. Permite ejecutar scripts Groovy. Los scripts Groovy son similares al código java
sin ningún código repetitivo. Spring CLI ayuda a iniciar un nuevo proyecto o escribir un
comando personalizado para él.

Requerimientos:

 Entorno de desarrollo: Eclipse / IntelliJ IDEA y similares

Mg. Ing. José Alberto Gómez Avila

 Java 1.8 JDK

 Motor de Base de Datos según el requerimiento. Por defecto se puede utilizar

h2.

Esquema de Funcionamiento de Spring MVC:

Esquema de Funcionamiento de Spring MVC

SPRING SECURITY
Mg. Ing. José Alberto Gómez Avila

Spring Security es un marco de trabajo y personalización de autenticación y control de

acceso. Es el estándar de seguridad del framework Spring.

Spring Security se brinda la facilidad con la que se puede ampliar para cumplir con los
requisitos personalizados de autenticación es decir es integrable con librerías externas
como captcha, etc.

ANGULAR
Angular es un framework que se basa en el patrón MVC, brindando la vinculación de
datos e inyección de dependencias.

AngularJS nos permite crear aplicaciones de una sola página, o sea podemos cargar
diferentes partes de la aplicación sin tener que recargar todo el contenido en el
navegador. Este comportamiento es acompañado por un motor de plantillas que genera
contenido dinámico con un sistema de expresiones evaluadas en tiempo real.

Vinculación de datos
Desde que el DOM pudo ser modificado después de haberse cargado por completo,
librerías como jQuery hicieron que la web fuera más amigable. Permitiendo de esta
manera que en respuesta a las acciones del usuario el contenido de la página puede ser
modificado sin necesidad de recargar el navegador.

Esta posibilidad de modificar el DOM en cualquier momento es una de las grandes

ventajas que utiliza AngularJS para vincular datos con la vista.

Directivas
AngularJS tiene una gran cantidad de directivas que permiten que las plantillas sean
fáciles de leer y brinda la posibilidad de crear nuestras propias directivas para extender
el HTML y hacer que nuestra aplicación funcione de forma modular.
Mg. Ing. José Alberto Gómez Avila

Implementación Genérica de Angular

Arquitectura Angular

Podemos identificar los 8 bloques principales de una app con Angular:

Módulo Data Binding
Componente Directiva
Template Servicio
Metadatos Dependency Injection

Las apps de Angular son modulares, gracias a su propio sistema de módulos

llamado Angular Modules ( o NgModules). Por otro lado, al desarrollar Angular en
TypeScript utilizas los módulos de ES6 (para gestionar librerías de JS).
Mg. Ing. José Alberto Gómez Avila

Librerías de Angular

Angular está empaquetado como una colección de librerías Javascript vinculadas a

distintos paquetes npm. Así solo tienes que importar lo que realmente necesitas y
consigues una web más ligera.

Las librerías principales de Angular (siempre comienzan por @angular) son:

@angular/core
@angular/platform-browser
@angular/router
@angular/forms
@angular/http

Root Module

Es el módulo principal de Angular. Por convenio se le llama AppModule y se encuentra

en el archivo app.module.ts.

La clase AppModule sirve para cargar la aplicación e indicar todas sus dependencias.
Como el resto de módulos, se declara con el decorador NgModule, y un ejemplo sería:
Mg. Ing. José Alberto Gómez Avila

Servicios Web
Son conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la
Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de
ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos
remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de
la Web.

Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes

aplicaciones, que interactúan entre sí para presentar información dinámica al usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al
mismo tiempo sea posible su combinación para realizar operaciones complejas, es
necesaria una arquitectura de referencia estándar.
Mg. Ing. José Alberto Gómez Avila

SOAP – REST
Las principales diferencias en el funcionamiento de ambos son:
SOAP es un estilo de arquitectura orientado a RPC, mientras que para REST
solamente existen los métodos de HTTP y está orientado a recursos.

REST no permite el uso estricto de “sesión” puesto que por definición es sin
estado, mientras que para SOAP, al ser orientado a RPC, los servicios Web crean
sesiones para invocar a los métodos remotos.

SOAP utiliza HTTP como un túnel por el que pasa sus mensajes, se vale de XML
para encapsular datos y funciones en los mensajes. Si dibujásemos una pila de
protocolos, SOAP iría justo encima de HTTP, mientras que REST propone HTTP
como nivel de aplicación.

SOAP
Especificación para el intercambio de información estructurada en servicios web, a
través de redes de ordenadores.

Se basa en tres componentes principales:

WSDL: lenguaje de descripción del servicio

HTTP/SMTP: protocolo de comunicación

XML: lenguaje de especificación de peticiones y respuestas

SOAP es independiente porque puede usarse sobre servicios escritos en cualquier

lenguaje y Neutral porque puede usarse sobre cualquier protocolo de transporte.
Mg. Ing. José Alberto Gómez Avila

Arquitectura SOAP

Modo de Funcionamiento:

REST

REST enfatiza:
 Escalabilidad de los componentes de interacción.

 Generalidad de las interfaces.

 Independencia en el desarrollo de componentes.

Mg. Ing. José Alberto Gómez Avila

 Sistemas intermedios para reducir el tiempo de interacción, mejorar la

seguridad, y encapsular los sistemas de herencia.

REST consigue esos objetivos aplicando cuatro constantes:

Identificación de recursos

Manipulación de recursos a través de sus representaciones.

Mensajes auto-descriptivos

Hipermedios como el motor del estado de la aplicación

La identificación de recursos siempre se hace por medio de URI. HTTP es un protocolo

centrado en URI. Los recursos son los objetos lógicos a los que les mandamos mensajes.
Los recursos no pueden ser directamente accedidos ni modificados. En vez de eso,
trabajamos con representaciones de ellos.

Cuando usamos el método HTTP PUT para enviar información, se toma como una
representación del estado en el que nos gustaría que estuviese el recurso. Internamente
el estado del recurso puede ser cualquier cosa desde una base de datos relacional hasta
un simple texto plano. REST obliga a que los mensajes HTTP sean tan auto-descriptivos
como sea posible.

Permite que los sistemas intermedios puedan interpretar los mensajes y mejoren el
comportamiento con los usuarios. Uno de los modos con los que HTTP realiza esto es
estandarizar los métodos, las cabeceras y los mecanismos de direccionamiento. Por
ejemplo, los servidores caché conocen que por defecto GET es “cacheable” (porque no
puede tener efectos colaterales al solicitar una representación de un recurso).

Por el contrario, POST es no-cacheable por defecto. HTTP es un protocolo sin estado, y
si se usa correctamente, es posible interpretar cada mensaje sin conocer los mensajes
que existieron anteriormente, ni los que le seguirán. Por ejemplo, en vez de usar “loggin
in” de la manera que lo hace FTP, HTTP envía la información nombre/contraseña en cada
mensaje.

Finalmente. REST describe un mundo en el que cada hipermedio es el motor del estado
de la aplicación. Esto significa que el estado actual de una aplicación Web particular
debe estar capturado en uno o más documentos de hipertexto, residiendo en el cliente
o en el servidor.
Mg. Ing. José Alberto Gómez Avila

El servidor conoce el estado de sus recursos, pero no va almacenando los pasos de cada
“sesión” de un cliente. Es el cliente quien conoce la misión que se necesita completar.
Es responsabilidad del cliente ir navegando de recurso en recurso, recopilando la
información que necesita y cambiando el estado cuando lo necesita.

ARQUITECTURA SOA
La arquitectura orientada a Servicios (SOA) fue definido por la organización para el
Fomento de Estándares de Información Estructurada (OASIS).

SOA y la orientación a servicios son paradigmas de implementación agnóstica que

pueden ser llevados a cabo con cualquier plataforma tecnológica adecuada.

En la actualidad se usan los servicios web para tratar de llevar a cabo la orientación a
servicios, pero en algún momento los servicios web sean sustituidos por otra plataforma
superior que se acerque a una orientación a servicios más pura.

FUNDAMENTOS DE SOA

Encapsulación de la lógica en servicios

Para conservar su independencia, los servicios encapsulan su lógica dentro de un
contexto bien definido. Cada servicio puede encapsular una tarea llevada a cabo en un
único paso, o una tarea compuesta por varios pasos.

Los servicios compuestos a partir de varios servicios más básicos.

Relación entre servicios

Dentro de SOA, los servicios pueden ser usados por otros servicios u otros programas.
Para poder interactuar unos con otros, los servicios deben tener presente la existencia
del resto de servicios y se consigue a través del uso de descriptores de servicio.

Un descriptor de servicio es un formato básico que establece el nombre del servicio y

los datos esperados y devueltos por el mismo. La forma en la cual los servicios usan estos
descriptores que resulta en una relación clasificada como ‘acoplo débil’.

Los servicios necesitan intercambiar información para interactuar y llevar a cabo algo
útil. Es por tanto necesario un Framework de comunicaciones capaz de mantener esta
relación de acoplo débil.
Mg. Ing. José Alberto Gómez Avila

Comunicación entre servicios

Un servicio envía un mensaje, y si éste pierde el control de lo que le pase a ese mensaje.
Entonces es por ello, que es necesario que los mensajes existan como ‘unidades de
comunicación independientes’. Los servicios, deben ser autónomos.

Para alcanzar este objetivo los mensajes pueden ser equipados con la suficiente
inteligencia para autogobernar sus partes de la lógica de proceso.

Los servicios que ofrecen descriptores de servicio y que se comunican vía mensaje. Por
ello es una forma de arquitectura básica, la cual parece similar a las antiguas
arquitecturas distribuidas que soportaban mensajería y una separación de la interfaz del
procesamiento lógico. Sin embargo, lo que distingue a SOA es el cómo estos tres
componentes principales (servicios, descriptores y mensajes) son diseñados.

Diseño de los servicios

La orientación a servicios se ha convertido en un enfoque de diseño definido que
introduce principios comúnmente aceptados que rigen la colocación y el diseño de los
componentes de la arquitectura.

Los aspectos claves de los principios de la orientación a servicios son:

 Acoplo débil: Los servicios mantienen una relación que minimiza dependencias
y únicamente se necesita que tengan en cuenta la existencia de los otros
servicios.

 Contrato de servicio: Los servicios se adhieren a un acuerdo de comunicaciones,

definido colectivamente por uno o más descriptores de servicio.

 Autonomía: Los servicios tienen control sobre la lógica que encapsulan.

 Abstracción: Es la descripción en el contrato del servicio, los servicios ocultan del

mundo exterior la lógica que implementan.

 Reutilización: La lógica es dividida en servicios con la intención de promover la

reutilización de los mismos.

 Componibilidad: Colecciones de servicios pueden ser coordinadas y

ensambladas para formar servicios compuestos.

 Ausencia de estado: Los servicios minimizan la información retenida específica a

una actividad.
Mg. Ing. José Alberto Gómez Avila

 Detectabilidad: Los servicios son diseñados para ser en apariencia descriptivos,

de forma que puedan ser encontrados y evaluados vía mecanismos de
descubrimiento de disponibilidad.

Con el conocimiento de los componentes que conforman la arquitectura básica y un

conjunto de principios de diseño (patrones) pueden ser usados para dar forma y
estandarizar estos componentes, todo lo que falta es una plataforma de
implementación que permita unir todas estas piezas para construir soluciones
orientadas a servicio.

CARACTERISTICAS DEL SOA

Incrementa la calidad de servicio (QoS)

- La capacidad de que las tareas sean llevadas a cabo de una manera segura,
protegiendo el contenido de los mensajes.

- Permitir a las tareas ser llevadas a cabo de una manera fiable para que el envío
del mensaje o de la notificación de fallo de envío esté garantizado.
- Requisitos de rendimiento para asegurar que los gastos asociados al uso de
mensajes SOAP y procesado de XML no impidan la ejecución de una tarea.

- Capacidades transaccionales que protejan la integridad de tareas específicas de

negocio y que garanticen que si una tarea falla se ejecuta una lógica de
excepción.

Es esencialmente autónoma

El principio de autonomía de la orientación a servicios requiere que los servicios

individuales sean tan independientes y autocontenidos como sea posible con respecto
al control que tienen sobre su lógica.

SOA se basa en este principio y lo expande fomentando el concepto de autonomía hacia

cotas mayores. Por ejemplo, aplicaciones compuestas por servicios autónomos pueden
ser vistas como servicios compuestos y autosuficientes que ejercitan su propio
autogobierno dentro del entorno de la integración orientada a servicios.

Basada en estándares abiertos

Mg. Ing. José Alberto Gómez Avila

El intercambio de información está gobernado por estándares abiertos. Tras ser enviado
el mensaje desde un servicio web a otro, viaja a través de un conjunto de protocolos
globalmente aceptados y estandarizados.

Además, el propio mensaje está estandarizado tanto en formato como en cómo

representa su carga. El uso de SOAP, XML, WSDL y XML Schema permite a los mensajes
ser completamente autocontenidos y soportar el acuerdo de comunicación de forma
que los servicios solo necesitan el conocimiento de los otros descriptores del servicio.

El uso de un modelo de mensajes estandarizado y abierto elimina la necesidad de una

lógica de servicio subyacente para compartir tipos de sistemas y soporta el paradigma
del acoplo débil.

Una arquitectura orientada a servicios limita el rol de la tecnología propietaria a la

implementación y alojamiento de la lógica de aplicación encapsulada por el servicio.
Soporta diversidad en cuanto a proveedores.

El uso de un Framework de comunicaciones abierto y estandarizado permite a los

organizadores elegir el mejor entorno posible para una aplicación específica. Por
ejemplo, sin tener en cuenta cuánto de propietario es un entorno de desarrollo, siempre
que permita la creación de servicios web estándar, puede ser usada para crear una capa
de interfaz de servicios no propietaria estableciéndose oportunidades de
interoperabilidad con otras aplicaciones.

SOA desde el punto de vista de la tecnología:

Favorece la reutilización y la reducción del “time to market”:

- Aumenta el grado de reutilización al desacoplar las capas de una aplicación.
- Permite reutilizar las aplicaciones existentes mediante la encapsulación en
servicios.
- Permite la utilización de servicios de terceros.
- Permite reutilizar las plataformas existentes

Aumenta la flexibilidad:
- Simplifica la adaptación de los sistemas existentes.
- Evita el desarrollo de interfaces punto a punto entre los sistemas.
- Aumenta la interoperabilidad entre sistemas, permitiendo tanto la
externalización como la prestación de servicios.

Mejora la productividad de los procesos:

Mg. Ing. José Alberto Gómez Avila

- Aumenta el nivel de automatización de los procesos, reduciendo el número de

actividades manuales.
- Permite monitorizar la actividad del negocio (cuadros de mando).
- Permite realizar un análisis estadístico de los flujos de negocio reales en base a
indicadores clave de negocio, permitiendo la identificación de puntos de mejora
a optimizar.
- Permite evaluar el impacto y beneficio de variantes en los procesos mediante
simulación.

Mejora el proceso de construcción de software:

- Favorece la industrialización.
- Mejora la especificación de los requerimientos de negocio.
- Proporciona una filosofía de desarrollo común a todos los negocios y canales.
- Mejora la calidad.
- Desacopla el desarrollo de servicios y de procesos.
- Mejora el mantenimiento (procesos autodocumentados).

Mejora la usabilidad de las aplicaciones:

- Permite presentar al usuario la información dispersa en distintos sistemas y de
forma integrada.
- Permite alcanzar un mayor nivel de automatismo en las aplicaciones en procesos
complejos de workflow.
- Permite utilizar tecnologías de presentación avanzadas como Web 2.0.
Mg. Ing. José Alberto Gómez Avila

SOA desde el punto de vista de la tecnología

Agilidad en el negocio articulada por SOA

Mg. Ing. José Alberto Gómez Avila

Estrategias de Adopción de SOA

Enfoques de Adopción de SOA

Mg. Ing. José Alberto Gómez Avila

Cómo y por qué están implementando SOA las organizaciones actuales

Mg. Ing. José Alberto Gómez Avila

Facilitadores tecnológicos clave de SOA