Un breve estudio acerca de los

conceptos de arquitectura de software

y la arquitectura orientada a servicios
A Brief Survey of Software Architecture
Concepts and Service Oriented
Architecture
Mohammad Hadi Valipour, Bavar Amirzafari, Khashayar Niki Maleki and Negin Daneshpour
Department of Electrical and Computer Engineering
Shahid Rajaee University
Tehran 1678815811, Iran
Email: {m.h.valipour, b.amirzafari, kh.niki}@sru.ac.ir, ​daneshpour@aut.ac.ir

Conference Paper · September 2009

DOI: 10.1109/ICCSIT.2009.5235004 · Source: IEEE Xplor

Resumen —Una cuestión crítica en el diseño y construcción de cualquier sistema complejo

de software es su arquitectura. La arquitectura de software como una importante columna
de proceso de desarrollo de software tiene varios métodos y hojas de ruta de los cuales
todos ellos tienen algunos principios comunes e inicios. Los enfoques basados ​en la
arquitectura. han sido promovidos como un medio para controlar la complejidad de la
construcción y evolución de sistemas. En este trabajo intentamos describir los conceptos
básicos y principales de la arquitectura de software con una visión conceptual de este
problema. Primero, son presentadas las definiciones de arquitectura. Finalmente la
arquitectura orientada a servicios (SOA) como una de las opciones útiles para la
arquitectura de software para desarrollar software web. y los sistemas se glosan en una
encuesta. Términos de índice : arquitectura de software, architecture, servicios web.

SOA es un diseño para vincular en demanda recursos de negocios y computacionales

(principalmente organizaciones, aplicaciones y datos) para lograr los resultados deseados
para los consumidores de servicios. (que pueden ser usuarios finales u otros servicios).
OASIS (The Organization for the Advancement of Structured Information Standards) [16]
define SOA como:

Un paradigma para la organizar y utilizar capacidades distribuidas que

pueden estar bajo el control de diferentes dominios de propiedad.
Proporciona un medio uniforme para ofrecer, descubrir, interactuar con y
 utilizar capacidades para producir efectos deseados consistentes con las
expectativas y pre-condiciones medibles.

La arquitectura orientada a servicios (SOA) es una evolución de la arquitectura basada en

componentes (Una arquitectura basada en componentes es el modelo de separar
funcionalidad dentro de objetos individuales independientes que pueden trabajar juntos) el
Diseño Basado en Interfaces (Interface Based Design IBD) y los sistemas distribuidos de la
década de los 1990, tales como DCOM [17], CORBA [18] (CORBA is the Object
Management Group (OMG) Component Object Reference Broker Architecture. IT is a
vendor-neutral, component-based architecture) , J2EE [19] (Sun Microsystems Java 2
Platform, Enterprise Edition (J2EE) defines the standard for developing component-based,
multi-tier, enterprise applications) y la Internet en general. SOA no significa necesariamente
servicios web (Web Services) tales como .NET , J2EE , CORBA o ebXML . Estos son, en
cambio, implementaciones especializadas de SOA que incorporan los aspectos centrales.
del enfoque orientado a servicios. Cada una de s esas implementaciones extiende el
modelo de referencia básico de SOA.

Mientras que los servicios web proveen soporte para muchos de los conceptos de SOA, no
los implementan todos. Ellos no soportan actualmente la noción de contrato de
arrendamiento. También, ninguna especificación oficial proporciona niveles de QoS para un
servicio. Una organización no puede implementar una arquitectura orientada a servicios
completa dadas estas limitaciones con los Web Services. Además, los consumidores de
servicios pueden ejecutar servicios web directamente si conocen la dirección del servicio y
su contrato (interface). Ellos no tienen que acudir al registro (registry) para obtener esta
información. Hoy, de hecho, la mayoría de las organizaciones implementan servicios web
sin un registro. En consecuencia, la medida en que una organización implementa SOA con
servicios web varía mucho.

Los beneficios de la arquitectura orientada a

servicios
Los principales impulsores de las arquitecturas basadas en SOA son el facilitar el
crecimiento manejable de los sistemas empresariales de gran escala, facilitar el
aprovisionamiento a escala de Internet y el uso de servicios y reducir los costos en la
cooperación organización a organización. El valor de SOA es que proporciona un
paradigma simple y escalable. para organizar grandes redes de sistemas que requieren
interoperabilidad para aprovechar el valor inherente en los componentes individuales. En
efecto, SOA es escalable porque hace menor número posibles de supuestos sobre la red y
reduce al mínimo cualquier suposición de confianza que a menudo se hacen implícitamente
en sistemas de menor escala. Un arquitecto que usa los principios de SOA está mejor
equipados, por lo tanto, para desarrollar sistemas que sean escalables, evolucionables y
manejables. Debería ser más fácil decidir cómo integrar la funcionalidad a través de los
límites de propiedad (los diferentes dominios del negocio). por ejemplo, una gran empresa
que adquiere una empresa más pequeña debe determinar cómo integrar la infraestructura
de TI adquirida. en su cartera global de TI. A través de esta capacidad inherente de escalar
y evolucionar SOA permite una cartera de TI que es adaptable a las variadas necesidades
del dominio del problema específico o la arquitectura del proceso. La infraestructura que
SOA fomenta es también es más ágil y sensible que una construida sobre un número
exponencial de interfaces pareadas. Por lo tanto, SOA también puede proporcionar una
base sólida para la agilidad y adaptabilidad.

Detalles de SOA
Antes de analizar los detalles de SOA, es importante primero explorar el concepto de
arquitectura de software, que consiste en las estructuras de grano grueso del software. La
arquitectura de software describe los componentes del sistema y la forma en que
interactúan en un alto nivel Estos componentes no son necesariamente beans de entidad o
objetos distribuidos. Son módulos abstractos de software desplegados como una unidad en
un servidor con otros componentes. Las interacciones entre componentes se denominan
conectores. los configuración de componentes y conectores describe la forma en que un
sistema está estructurado y se comporta, como se muestra en la figura 2

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

tiene varias características únicas. Es importante para los diseñadores de servicios y
desarrolladores entender la conceptos de SOA, de manera tal que puedan hacer el uso más
efectivo de los Servicios Web en su entorno. SOA es un término relativamente nuevo, pero
el término "servicio" se relaciona con un servicio software ha existido por lo menos desde
principios de la década de 1990, cuando se usó en Tuxedo para describir "servicios" y
"procesos de servicio" [20]. Recientemente ha habido más interés en la comunidad de
desarrollo de software sobre los conceptos detrás de SOA La figura 3 muestra que otras
tecnologías pueden ser usadas para Implementar arquitectura orientada a servicios.
Los Servicios Web son simplemente un conjunto de tecnologías que pueden ser usadas
para ​implementar con éxito SOA.
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
soporta un formato de solicitud particular o contrato. Ellos no están preocupados con el
cómo funciona el servicio para ejecutar sus solicitudes; ellos solo esperan el resultado.

Características SOA
La arquitectura del software de cada sistema refleja los diferentes principios y conjuntos de
compromisos utilizados por los diseñadores. La arquitectura de software orientada a
Servicios tiene estas características [21]:

Visible y enlazado dinámicamente:

SOA soporta el concepto de descubrimiento de servicios. Un consumidor de servicios que
necesita un servicio descubre qué servicio usar basado en un conjunto de criterios en
tiempo de ejecución. El consumidor le consulta a un registro por el servicio que cubra su
necesidad.
Autocontenido y modular
Los servicios son auto-contenidos y modulares. Uno de los aspectos más importantes de
SOA es el concepto de modularidad. Un servicio soporta un conjunto. de interfaces. Estas
interfaces deben ser cohesivas, es decir, que todas deben relacionarse entre sí en el
contexto de una módulo. Los principios de modularidad deben ser respetados en el diseño
de los servicios que soportan una aplicación para que los servicios se pueden agregar
fácilmente en una aplicación con una pocas bien conocidas dependencias . Dado que esto
es un concepto importante al crear servicios, explicaremos algunos de las principios de
modularidad y, en particular, cómo se aplican a la creación de servicios. Bertrand Meyer [22]
esbozó los cinco criterios siguientes para determinar si un componente es suficientemente
modular. Estos criterios se aplican igualmente bien cuando determinamos si un servicio es
suficientemente modular.
Descomposición Modular : La descomposición modular de un servicio se refiere a la
división de una aplicación en módulos más pequeños. Cada módulo es responsable de una
sola y única función dentro de una aplicación. Esto es a veces conocido como "diseño de
arriba hacia abajo" (top-down), en el que los problemas más grandes se descomponen
iterativamente en problemas más pequeños. El principal objetivo de la descomposición es la
reutilización. La meta para el diseño de servicios es “identificar” la unidad más pequeña de
software que puede ser reutilizada en diferentes contextos.
Composición Modular : La composición modular de un servicio se refiere a la
producción de servicios de software que pueden ser libremente combinados en conjunto
con otros servicios para producir nuevos sistemas. Los diseñadores de servicios deberían
crear servicios suficientemente independientes para utilizarlos en aplicaciones totalmente
diferentes. a las que originalmente fueron destinados. Esto a veces se conoce como diseño
de abajo hacia arriba (bottom-up)
- Comprensibilidad modular: La comprensión 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 recae en el cliente utilizar un
servicio separado de depósito; Esto le restaría comprensibilidad al servicio
- Continuidad modular: La continuidad modular de un servicio. se refiere al impacto
de un cambio en un servicio que requiere una cambio en otros servicios o en los
consumidores del servicio. Una interfaz que no oculta lo suficiente los detalles de
implementación del servicio crea un efecto dominó cuando los cambios son necesarios.
Requerirá cambios a otros servicios y aplicaciones. que utilizan el servicio cuando la
implementación interna del servicio cambia Cada servicio debe ocultar información sobre su
diseño interno. Un servicio que expone esta información limitará su continuidad modular,
debido a que un una decisión de diseño interno está 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 hace que dicha condición vaya en cascada a otros
servicios o consumidores. Por ejemplo, si un error en el servicio de cuenta corriente hace
que datos no válidos sean almacenados en la base de datos, esto podría afectar el
funcionamiento de otros servicios que utilizan 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 de lo contrario rompe el contrato con los consumidores del
servicio

Interoperabilidad
La arquitectura orientada a servicios extrema la interoperabilidad, la capacidad de los
sistemas que utilizan diferentes plataformas. y lenguajes para comunicarse entre sí. Cada
servicio proporciona una interfaz que puede ser invocada a través de algún tipo de conector.
Un conector interoperable consiste en un protocolo y un formato de datos que cada uno de
los potenciales clientes del servicio. entiende La interoperabilidad se logra apoyando los
protocolos y formatos de datos de los clientes actuales y potenciales.Las técnicas para
soportar protocolos y datos estándar consisten en mapear cada característica y lenguaje a
una especificación intermedia. La especificación intermedia mapea entre los formatos de
datos interoperable a los formatos de datos específicos de la plataforma. Algunas veces
esto requiere la asignación de conjuntos de caracteres como de ASCII a EBCDIC así como
mapeo de tipos de datos. Por ejemplo, un servicio web es una especificación mediadora
para la comunicación entre sistemas. JAX-RPC y JAXM asignan tipos de datos de Java a
SOAP. Otro plataformas que soportan servicios web median entre sus las especificaciones
de servicios web y sus propias especificaciones internas para conjuntos de caracteres y
tipos de datos.

Bajo Acoplamiento
El acoplamiento se refiere al número de dependencias entre módulos. Hay dos tipos de
acoplamiento: bajo/ébil y alto/fuerte. Los módulos débilmente acoplados tienen algunos
dependencias bien conocidas. Los módulos fuertemente acoplados tienen muchas
dependencias desconocidas. Cada arquitectura de software se esfuerza en lograr un
acoplamiento débil entre módulos. SOA promueve el bajo acoplamiento entre los
consumidores de servicios y los proveedores de servicios y la idea de unas pocas
dependencias conocidos entre consumidores y proveedores.

Transparencia de la ubicación
La transparencia de la ubicación es una característica clave de la arquitectura orientada a
servicios. Los consumidores de un servicio no conocen la ubicación de un servicio hasta
que lo localizan. en el registro. La búsqueda y el enlace dinámico a un servicio en tiempo de
ejecución permite que la implementación del servicio se mueva. de lugar en lugar sin el
conocimiento del cliente. La capacidad de mover servicios mejora la disponibilidad del
servicio y su desempeño. Empleando un equilibrador de carga que reenvía solicitudes de
servicio a múltiples instancias de servicio sin el servicio conocimiento del cliente podemos
lograr una mayor disponibilidad y performance.
Composibilidad / Capacidad de composición
La composibilidad de un servicio está relacionada con su estructura modular. La estructura
modular le permite a los servicios ser ensamblados en aplicaciones de las que el
desarrollador no tenía noción a la hora de diseñar el servicio. Usando servicios
preexistentes y probados se mejora en gran medida la calidad de un sistema y mejora su
retorno.de inversión debido a la facilidad de la reutilización. Un servicio puede componerse
de tres formas: composición de la aplicación, federación de servicios, y orquestación de
servicios.
- Una aplicación: es típicamente un conjunto de servicios, componentes, y la lógica
de la aplicación que une estas funciones para un propósito específico.
- Federación de servicios: son colecciones de servicios gestionados juntos en un
dominio de servicio más grande. Por ejemplo, una servicio de comprobación de cuenta,
servicio de cuenta de ahorros y servicio al cliente. puede ser compuestos dentro de un
servicio más grande de gestión de cuentas bancarias.
- Orquestación de servicios: es la ejecución de una sola transacción. que impacta
uno o más servicios en una organización. Es a veces llamado proceso de negocio. Se
compone de múltiples pasos, cada uno de los cuales es una invocación de servicio. Si
alguna de los las invocaciones de servicio falla, la transacción completa debe ser revertida
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 propios métodos del servicio debe ser subtransaccionales. Es decir, no
deben realizar commits de datos.

Autocuración:
Con el tamaño y la complejidad de las modernas aplicaciones distribuidas, la capacidad de
un sistema para recuperarse de el 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
humano durante la ejecución.

Confiabilidad
La confiabilidad mide realmente el desempeño de un sistema bajo al presencia de
disturbios. En arquitectura orientada al servicio, los servicios estarán funcionando o caídos
de vez en cuando. Esto es especialmente cierto para aplicaciones ensambladas a partir de
servicios de múltiples organizaciones a través de Internet. La medida en la que un sistema
se autocure depende de varios factores. La confiabilidad depende de la capacidad del
hardware para recuperarse de un fallo. La red también debe permitir la conexión dinámica a
diferentes sistemas en tiempo de ejecución. Los protocolos de internetworking actuales
proporcionan inherentemente esta capacidad.
Implementaciones conocidas
Si bien la naturaleza de los servicios en sí puede variar, una norma común para declarar un
servicio es deseable cuando se está construyendo una infraestructura. Dos de tales
estándares existen hoy: Los lenguaje de descripción de servicios web (WSDL) del W3C y el
protocolo de colaboración ebXML. La versión 2.0 de WSDL es impresionante en su
integridad y facilidad de implementación; sin embargo, solo cubre lo aspectos básicos de la
descripción de un servicio. ebXML es una iniciativa conjunta de SOA entre UN/CEFACT 5
[23] y OASIS [16]. Además de proporcionar componentes técnicos, el Protocolo de
Colaboración. fue desarrollado para satisfacer las necesidades específicas de los negocios
electrónicos que involucran interacciones orientadas al servicio entre Empresas.

Conclusión
La arquitectura del software está emergiendo como disciplina los últimos diez años [7]. La
arquitectura de software describe sus estructuras y propiedades a un alto nivel. Mientras la
tecnología cuide estas estructuras y propiedades, la tecnología puede ser utilizada para la
implementación de la arquitectura. Por ejemplo, Jini es una tecnología que es compatible
con la 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
para tomar plena ventaja de ello. SOA es implementada por servicios web y otras
tecnologías, pero los términos y los conceptos han ganado popularidad recientemente como
resultado de los Servicios Web. Por ejemplo, en la industria informática ha sido el término
utilizado durante dos décadas para describir varias plataformas. Algunos características de
SOA son soportadas mejor por una que otra tecnología.

Referencias
1] O. J. Dahl, E. W. Dijkstra, and C. A. Hoare, Structured Programming.
Academic Press, 1972.
[2] F. P. Brooks, The Mythical Man-Month: Essays On Software Engineering, Anniversary
Edition. Addison-Wesley, 1995.
[3] P. J. Denning and P. A. Dargan, “A discipline of software architecture,”
interactions, vol. 1, no. 1, pp. 55–65, 1994.
[4] M. Shaw and D. Garlan, Software Architecture: Perspectives on an
Emerging Discipline. Prentice- Hall, 1996.
[5] P. Brown, Implementing soa: total architecture in practice. AddisonWesley Professional,
2008.
[6] D. E. Perry and A. L. Wolf, “Foundations for the study of software
architecture,” ACM SIGSOFT SOFTWARE ENGINEERING NOTES,
vol. 17, no. 4, October 1992.
[7] D. Garlan, “Software architecture: a roadmap,” in ICSE ’00: Proceedings
of the Conference on The Future of Software Engineering. New York,
NY, USA: ACM, 2000, pp. 91–101.
[8] R. Allen and D. Garlan, “Formalizing architectural connection,” in ICSE
’94: Proceedings of the 16th International Conference on Software
Engineering, Sorrento, Italy, May 1994, pp. 71–80.
[9] D. C. Luckham, L. M. Augustin, J. J. Kenny, J. Veera, D. Bryan,
and W. Mann, “Specification and analysis of system architecture using
rapide,” IEEE Transactions on Software Engineering, vol. 21, no. 4, pp.
336–355, April 1995.
[10] G. Abowd, R. Allen, and D. Garlan, “Using style to understand descriptions of software
architecture,” in SIGSOFT ’93: Proceedings of the
1st ACM SIGSOFT symposium on Foundations of software engineering.
New York, NY, USA: ACM, 1993, pp. 9–20.
[11] P. Clements, L. Bass, R. Kazman, and G. Abowd, “Predicting software
quality by architecture-level evaluation,” in Proceedings of the Fifth
International Conference on Software Quality, Austin, Texas, October
1995
[12] J. A. Stafford, D. J. Richardson, and A. L. Wolf, “Aladdin: A tool
for architecture-level dependence analysis of software,” University of
Colorado at Boulder, Technical Report CU-CS-858-98, April 1998.
[13] L. Coglianese and R. Szymanski, “Dssa-adage: An environment for
architecture-based avionics development,” in AGARD’93, 1993.
[14] B. Boehm, P. Bose, E. Horowitz, and M. J. Lee, “Software requirements
negotiation and renegotiation aids: A theory-w based spiral approach,” in
ICSE ’95: Proceedings of the 17th international conference on Software
engineering. New York, NY, USA: ACM, 1995, pp. 243–253.
[15] L. Northrop, “Software architecture and product quality,” Presentation
for the Boston SPIN, Software Engineering Institute, Carnegie Mellon
University, May 2003.
[16] Organization for the advancement of structured information standards.
[Online]. Available: http://www.oasis-open.org
[17] Distributed component object model. [Online]. Available:
www.microsoft.com/com
[18] Corba basics frequently asked questions. [Online]. Available:
www.omg.org/gettingstarted/corbafaq.htm
[19] Java EE at a glance. [Online]. Available: http://java.sun.com/j2ee
[20] P. Herzum, “Web services and service-oriented architectures,” Cutter
Distributed Enterprise Architecture Advisory Service, Executive Report,
2002.
[21] G. Bieber and J. Carpenter, “Introduction to service-oriented programming,” Online
whitepaper: www.openwings.org/download/specs, 2001.
[22] B. Meyer, Object Oriented Software Construction, 2nd ed., ser. International Series in
Computer Science. Prentice-Hall, 1997.
[23] United nations centre for trade facilitation and electronic business.
[Online]. Available: http://www.unece.org/cefact