Una breve visión general de conceptos de arquitectura de software

y arquitectura orientada a servicios

Un tema crítico en el diseño y construcción de cualquier sistema de software complejo es su

arquitectura.
La arquitectura de software como una columna importante del proceso de desarrollo de
software tiene varios métodos y planes de trabajo que tienen principios comunes.
Se han promovido enfoques basados en la arquitectura como un medio para controlar la
complejidad de la construcción y evolución de los sistemas.
Se han propuesto varios enfoques para abordar la complejidad, en diferentes niveles, como
la "programación estructurada" y la idea de Fred Brooks de "integridad conceptual".
Integridad conceptual: En 1975, FredBrooks dijo: Sostendré que la integridad conceptual es
la consideración más importante en el diseño del sistema. Es mejor tener un sistema que
omita ciertas características y mejoras anómalas, pero que refleje un conjunto de ideas de
diseño, que tener una que contenga muchas ideas buenas pero independientes y
descoordinadas. En 1995, Brooks aún no ha cambiado de opinión: estoy más convencido que
nunca. La integridad conceptual es fundamental para la calidad del producto. Tener un
arquitecto de sistemas es el paso más importante hacia la integridad conceptual ... después
de enseñar un laboratorio de ingeniería de software más de 20 veces, llegué a insistir
en que los equipos de estudiantes de hasta cuatro personas elijan un gerente y un arquitecto
independiente.
La fase de diseño del ciclo de vida del software a menudo se ha dividido en diseño de alto
nivel y diseño detallado. Muchos conceptos en el curso ordinario (construcción) señalaron
que la arquitectura será útil para describir el software, lo que dio origen al término
"arquitectura de software".
El concepto de arquitectura de software ha surgido como el diseño una solución a un alto
nivel de los problemas de complejidad.
Hacia el final de 1994, Denning y Dargan propusieron la "arquitectura de software" para una
nueva disciplina de software, sin embargo, la descripción era similar a un método de
desarrollo, no a una definición. El consenso sobre el término no se hizo hasta la primera
mitad de los años noventa. Garlan y Shaw dijeron en 1996 que "la atención explícita a la
arquitectura como un nivel separado de diseño de software es relativamente reciente" y, en
consecuencia, su libro está subtitulado "perspectivas sobre una disciplina emergente"
La arquitectura orientada a servicios (SOA) es una arquitectura que modulariza los servicios.
Puede entonces coordinar la recopilación de estos servicios para los procesos de negocio a
la vida. En una SOA exitosa, puede recombinar estos servicios en diversas formas para la
implementación de procesos comerciales nuevos o mejorados.
SOA es un descendiente de la evolución lógica de las técnicas de modularización de software
que se remontan a más de 50 años con la introducción de la programación estructurada.
La novedad de SOA es que le brinda más flexibilidad al elegir la implementación de
tecnologías y ubicaciones para proveedores de servicios y consumidores.
Las interfaces de servicio abstracto también permiten a los proveedores y consumidores
evolucionar de forma independiente siempre que las interfaces permanezcan estables.
Los beneficios de SOA provienen principalmente de una característica única: la estabilidad
del servicio de interfaz. Esta estabilidad, en comparación con el porcentaje total de cambio
de sistemas, aísla el servicio a los consumidores en el desarrollo de los servicios de
implementación. Tomar muchas más ventajas si puede reutilizar los servicios tal como son.
La reutilización evita el costo de la re implementación o modificación de la funcionalidad
encapsulada en el servicio

Arquitectura de Software
La arquitectura del software es un "primer corte" en el diseño del sistema y la solución del
problema o la adaptación a la necesidad.
En realidad, es un activo de los planes que guían la selección, construcción, modificación y
uso perfecto de la infraestructura de información empresarial para permitir el estado
comercial futuro deseado.
Usamos el término "arquitectura", en contraste con "diseño", para evocar nociones de:

 codificación
 Abstracción
 Estándares
 capacitación formal (de arquitectos de software)
 estilo.
La arquitectura se ocupa de la selección de elementos arquitectónicos, sus interacciones y
las restricciones sobre esos elementos y sus interacciones
san ad hoc box-and-line drawing: está destinado a resolver problemas. Las casillas (boxes)
definen los elementos o "partes" del sistema. Las líneas (lines) definen las interacciones o
entre las partes.
El diseño se ocupa de la modularización y las interfaces detalladas de los elementos de
diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para soportar la
arquitectura y satisfacer los requisitos.
Entre sus valores podemos decir:

 Visión actual y futura del negocio

 Toma de decisiones de calidad, incluidas las opciones de inversión
 Uso de software de una manera rentable alineada con las operaciones de uso
 Reducir la redundancia
 Reutilizar información y componentes de software
 Aproveche las nuevas soluciones tecnológicas
 Compartir sistemas y datos
 Integración en toda la empresa
 Estándares comunes
 Reducción del número de interfaces de aplicaciones
 Identificación y planificación de datos faltantes

Roles
El centro de todas las definiciones de Arquitectura de software está la noción de que la
arquitectura de un sistema describe su estructura bruta. Esta estructura ilumina las
decisiones de diseño de nivel superior, incluidas cosas como la forma en que el sistema se
compone de partes que interactúan, dónde están las principales vías de interacción y cuáles
son las propiedades clave de las partes.
Además, una descripción arquitectónica incluye información suficiente para permitir el
análisis de alto nivel y la evaluación crítica
La arquitectura de software puede jugar un papel importante en al menos seis aspectos del
desarrollo de software
- Entendimiento: la arquitectura de software simplifica nuestra capacidad de
comprender sistemas grandes presentándolos en un nivel de abstracción en el que
el diseño de alto nivel de un sistema puede ser fácilmente comprendido.
- Reutilización: las descripciones arquitectónicas admiten la reutilización en múltiples
niveles. El trabajo actual de reutilización generalmente se enfoca en bibliotecas de
componentes. El diseño arquitectónico admite, además, la reutilización de
componentes grandes y también los marcos en los que se pueden integrar los
componentes.
- Construcción: una descripción arquitectónica proporciona un modelo parcial para el
desarrollo al indicar los principales componentes y dependencias entre ellos.
- Evolución: la arquitectura de software puede exponer las dimensiones a lo largo de
las cuales se espera que evolucione un sistema. Al hacer explícitos los "muros de
 carga" de un sistema, los mantenedores del sistema pueden comprender mejor las
ramificaciones de los cambios y, por lo tanto, estimar con mayor precisión los costos
de las modificaciones.
- Análisis: las descripciones arquitectónicas ofrecen nuevas oportunidades para el
análisis, incluida la comprobación de coherencia del sistema, la conformidad con las
restricciones impuestas por un estilo arquitectónico, la conformidad con los atributos
de calidad, el análisis de dependencia y el análisis específico del dominio para
arquitecturas construidas en estilos específicos.
- Gestión: la experiencia ha demostrado que los proyectos exitosos consideran el logro
de la arquitectura de software viable como un hito clave en un proceso de desarrollo
de software industrial. La evaluación crítica de la arquitectura generalmente conduce
a una comprensión mucho más clara de los requisitos, las estrategias de
implementación y los riesgos potenciales.
Impedimentos comunes para lograr el éxito arquitectónico: Entre los diversos factores que
pueden conducir a arquitecturas fallidas, está la falta de aptitud y / o experiencia
arquitectónica suficiente, el tiempo adecuado dedicado al diseño y análisis arquitectónico,
la incapacidad de documentar y comunicar la arquitectura de manera apropiada y darse
cuenta de que "los estándares no son un sustitúyase por una arquitectura de software "para
comprender completamente la relación directa entre la arquitectura y la implementación,
para actualizar la documentación a medida que la arquitectura evoluciona y etc

Arquitectura orientada a servicios

SOA es un diseño para vincular recursos comerciales y computacionales (principalmente
organizaciones, aplicaciones y datos) a pedido para lograr los resultados deseados para los
consumidores del servicio.
OASIS1 (Organización para el avance de estándares de información estructurados) define
SOA como el siguiente:
Un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el
control de diferentes dominios de propiedad. Proporciona un medio uniforme para ofrecer,
descubrir, interactuar y usar capacidades para producir efectos deseados consistentes con las
precondiciones y expectativas medibles.
Service Oriented Architecture (SOA) es una evolución de la arquitectura basada en
componentes2, el diseño basado en interfaz (orientado a objetos) y los sistemas distribuidos
de la década de 1990, como DCOM [17], CORBA3 [18], J2EE4 [19] e Internet en general. SOA
no significa necesariamente servicios web como .NET, J2EE, CORBA o ebXML. Estos son en
cambio especializados
Limitaciones de servicios web respecto a SOA: Si bien los servicios web brindan soporte para
muchos de los conceptos de SOA, no los implementan todos. Actualmente no respaldan la
idea de un contrato de arrendamiento. Además, ninguna especificación oficial proporciona
niveles de QoS (Calidad de servicio) para un servicio
Beneficios de SOA:
- Los principales impulsores (main drivers) de SOA son facilitar el crecimiento
manejable de los sistemas empresariales a gran escala, facilitar el aprovisionamiento
y el uso de servicios a escala de Internet y reducir los costos en la cooperación entre
organizaciones.
- Proporciona un paradigma escalable simple para organizar grandes redes de sistemas
que requieren interoperabilidad para obtener el valor inherente a los componentes
individuales.
- Es escalable porque hace la menor cantidad posible de suposiciones sobre la red y
también minimiza cualquier tipo de confianza supuestos que a menudo se hacen
implícitamente en sistemas de menor escala.
- Un arquitecto que usa principios SOA está mejor equipado, por lo tanto, para
desarrollar sistemas que sean escalables, evolutivos y manejables.
- La infraestructura que fomenta SOA también es más ágil y receptiva que una basada
en un número exponencial de interfaces de pares. Por lo tanto, SOA también puede
proporcionar una base sólida para la agilidad y adaptabilidad del negocio.

Detalles de SOA
Estructuras de grano grueso del software. La arquitectura del software describe los
componentes del sistema y la forma en que interactúan a un alto nivel. Estos componentes
no son necesariamente beans de entidad u objetos distribuidos. Son módulos abstractos de
software implementados como una unidad en un servidor con otros componentes.

La arquitectura orientada a servicios es un tipo especial de arquitectura de software que

tiene varias características únicas.
Los servicios web son simplemente un conjunto de tecnologías que pueden utilizarse para
implementarlo con éxito. El aspecto más importante de la arquitectura orientada a servicios
es que separa la implementación del servicio de su interfaz. En otras palabras, separa el "qué"
del "cómo". Los consumidores de servicios ven un servicio simplemente como un punto final
que admite un formato o contrato de solicitud en particular. No les preocupa la forma en
que el servicio ejecuta sus solicitudes; solo esperan el resultado.
un servicio web es una especificación mediadora de comunicación entre sistemas. JAX-RPC
y JAXM asignan tipos de datos java a SOAP (SIMPLE OBJECT ACCESS PROTOCOL) es
un protocolo estándar que define cómo dos objetos en diferentes procesos pueden
comunicarse por medio de intercambio de datos XML. otras plataformas que admiten
servicios web median entre la especificación de servicios web y su propia especificación
interna para conjuntos de caracteres y tipos de datos.
Jini es una arquitectura orientada a servicios que define un modelo de programación que
explota y extiende la tecnología Java.
Características de SOA:
1) Visible y vinculado dinámicamente: SOA admite el concepto de descubrimiento de
servicio. Un consumidor de servicios que necesita un servicio descubre qué servicio
usar según un conjunto de criterios en tiempo de ejecución. El consumidor del
servicio le pide a un registro un servicio que satisfaga sus necesidades.
2) Autónomo y modular: Uno de los aspectos más importantes de SOA es el concepto
de modularidad. Un servicio admite un conjunto de interfaces, estas deben ser
cohesivas, lo que significa que todas deben relacionarse entre sí en el contexto de un
módulo. Los principios de modularidad deben ser respetados al diseñar los servicios
que soportan una aplicación para que los servicios puedan agregarse fácilmente a
 una aplicación con algunas dependencias bien conocidas. Bertrand Meyer describió
los siguientes cinco criterios para determinar si un componente es suficientemente
modular:
- Decomposibilidad modular: la capacidad de descomposición modular de un servicio
se refiere a la ruptura de una aplicación en muchos módulos más pequeños. Cada
módulo es responsable de una función única y distinta dentro de una aplicación. Esto
a veces se denomina "diseño descendente", en el que los problemas más grandes se
descomponen de manera iterativa en problemas más pequeños. El objetivo principal
de descomposición es la reutilización. El objetivo del diseño del servicio es identificar
la unidad de software más pequeña que se puede reutilizar en diferentes contextos.
- Componibilidad modular: la capacidad de compilación modular de un servicio se
refiere a la producción de servicios de software que se pueden combinar libremente
en conjunto con otros servicios para producir sistemas nuevos. Los diseñadores de
servicios deberían crear servicios suficientemente independientes para reutilizarlos
en aplicaciones completamente diferentes de las que originalmente estaban
destinadas. Esto a veces se conoce como diseño de abajo hacia arriba.
- Comprensibilidad modular: la comprensibilidad modular de un servicio es la
capacidad de una persona para comprender la función del servicio sin tener
conocimiento de otros servicios. Por ejemplo, si una aplicación bancaria implementa
un servicio de cuenta corriente que no implementa una función de depósito sino que
confía en que el cliente use un servicio de depósito por separado; esto reduciría la
comprensibilidad modular del servicio.
- Continuidad modular: la continuidad modular de un servicio se refiere al impacto de
un cambio en un servicio que requiere un cambio en otros servicios o en los
consumidores del servicio. Una interfaz que no oculta suficientemente los detalles de
implementación del servicio crea un efecto dominó cuando se necesitan cambios.
Exigirá cambios a otros servicios y aplicaciones que usan el servicio cuando cambia la
implementación interna del servicio. Todos los servicios deben ocultar información
sobre su diseño interno. Un servicio que expone esta información limitará su
continuidad modular, porque una decisión de diseño interno queda expuesta a través
de la interfaz.
- Protección modular: la protección modular de un servicio es suficiente si una
condición anormal en el servicio no se conecta en cascada con otros servicios o
consumidores. Por ejemplo, si un error en el servicio de la cuenta de cheques hace
que se almacenen datos no válidos en una base de datos, esto podría afectar el
funcionamiento de otros servicios que usan las mismas tablas para sus datos. Las
fallas en la operación de un servicio no deben afectar la operación de un cliente u
otro servicio o el estado de sus datos internos o romper el contrato con los
consumidores del servicio.
3) Interoperabilidad: capacidad de los sistemas que utilizan diferentes plataformas y
lenguajes para comunicarse entre sí. Cada servicio proporciona una interfaz que se
puede invocar a través de un tipo de conector. Un conector interoperable consiste
en un protocolo y un formato de datos que cada uno de los clientes potenciales del
servicio entiende. La interoperabilidad se logra al admitir el protocolo y los formatos
de datos de los clientes actuales y potenciales del servicio. Las técnicas para soportar
formatos estándar de protocolo y datos consisten en mapear las características y el
lenguaje de cada plataforma a una especificación mediadora. La especificación
mediadora mapea entre los formatos del formato de datos interoperable a los
formatos de datos específicos de la plataforma. A veces, esto requiere asignar
conjuntos de caracteres como ASCII a EBCDIC, así como mapear tipos de datos.
4) Acoplamiento flojo: el acoplamiento se refiere a la cantidad de dependencias entre
módulos. Hay dos tipos de acoplamiento: flojo y apretado. Los módulos débilmente
acoplados tienen algunas dependencias bien conocidas. Los módulos fuertemente
acoplados tienen muchas dependencias desconocidas. Cada arquitectura de
software se esfuerza por lograr un acoplamiento flexible entre los módulos. La
arquitectura orientada al servicio promueve un acoplamiento flexible entre los
consumidores de servicios y los proveedores de servicios y la idea de unas pocas
dependencias bien conocidas entre consumidores y proveedores.
5) Transparencia de ubicación: los consumidores de un servicio no conocen la ubicación
de un servicio hasta que lo ubiquen en el registro. La búsqueda y vinculación dinámica
a un servicio en tiempo de ejecución permite que la implementación del servicio se
mueva de una ubicación a otra sin el conocimiento del cliente. La capacidad de mover
servicios mejora la disponibilidad y el rendimiento del servicio. Al emplear un
equilibrador de carga que envía solicitudes a múltiples instancias de servicio sin el
conocimiento del cliente de servicio, podemos lograr una mayor disponibilidad y
rendimiento.
6) Composición: la capacidad de compilación de un servicio está relacionada con su
estructura modular. La estructura modular permite que los servicios se ensamblen
en aplicaciones que el desarrollador no tenía en cuenta al diseñar el servicio. El uso
de servicios preexistentes y probados mejora en gran medida la calidad de un sistema
y mejora el retorno de la inversión debido a la facilidad de reutilización. Un servicio
puede estar compuesto de tres maneras: composición de la aplicación, federaciones
de servicios y orquestación de servicios.
- Una aplicación: suele ser un conjunto de servicios, componentes y lógica de
aplicación que une estas funciones para un propósito específico.
- Federaciones de servicios: son colecciones de servicios gestionados conjuntamente
en un dominio de servicio más amplio. Por ejemplo, un servicio de cuenta de cheques,
de cuenta de ahorros y de atención al cliente puede formar parte de un servicio de
cuenta bancaria más grande.
 - Orquestación de servicios: es la ejecución de una sola transacción que impacta uno o
más servicios en una organización. A veces se llama un proceso comercial. Consiste
en varios pasos, cada uno de los cuales es una invocación al servicio. Si alguna de las
invocaciones al servicio falla, toda la transacción debe retrotraerse al estado que
existía antes de la ejecución de la transacción.
Para que un servicio se componga en una aplicación transaccional, federación u
orquestación, los métodos de servicio en sí mismos deben ser subtransaccionales.
7) Autocuración: con el tamaño y la complejidad de las aplicaciones distribuidas
modernas, la capacidad de un sistema para recuperarse de un error es cada vez más
importante. Un sistema de autocuración es uno que tiene la capacidad de
recuperarse de errores sin intervención humana durante la ejecución.

Confiabilidad
La confiabilidad en realidad mide qué tan bien funciona un sistema en presencia de
perturbaciones. En arquitectura orientada al servicio, los servicios subirán y bajarán de vez
en cuando. Esto es especialmente cierto para aplicaciones ensambladas a partir de servicios
de múltiples organizaciones en Internet. El grado en que un sistema sea auto curable
depende de varios factores. La confiabilidad depende de la capacidad del hardware para
recuperarse de una falla. La red también debe permitir la conexión dinámica a diferentes
sistemas en tiempo de ejecución. Los protocolos modernos de red de Internet proporcionan
inherentemente esta capacidad.
Implementaciones conocidas
Si bien la naturaleza de los servicios mismos puede variar, un estándar común para declarar
un servicio es deseable cuando se construye una infraestructura. Existen dos estándares de
este tipo: el lenguaje de descripción de servicios web (WSDL) del W3C y el perfil de protocolo
de colaboración de ebXML. La versión 2.0 de WSDL es impresionante en su integridad y
facilidad de implementación; sin embargo, solo cubre los aspectos básicos de la descripción
del servicio. ebXML es una iniciativa conjunta de SOA entre UN / CEFACT5 y OASIS . Además
de proporcionar componentes técnicos, el perfil de protocolo de colaboración se desarrolló
para satisfacer las necesidades específicas de los negocios electrónicos que implican
interacciones orientadas a los servicios entre las empresas legales.

La arquitectura del software está surgiendo como una disciplina en los últimos diez años. La
arquitectura del software del sistema describe sus estructuras y propiedades de grano
grueso en un nivel alto. Siempre que la tecnología cumpla con estas estructuras y
propiedades, la tecnología se puede usar para la implementación de la arquitectura. Por
ejemplo, Jini es una tecnología que admite arquitectura orientada a servicios, porque las
propiedades de SOA. Es importante para la aplicación de los conceptos de arquitectura de
software de una nueva tecnología aprovecharla al máximo. La arquitectura orientada a
servicios es implementada por servicios web y otras tecnologías, pero los términos y
conceptos han ganado popularidad recientemente como resultado de los servicios web. Por
ejemplo, la industria de la informática es el término utilizado durante dos décadas para
describir diversas plataformas. Algunas características de SOA son compatibles con algunas
mejores que otras tecnologías