Diseno-de-una-arquitectura-soa-aplicada-en-un-sistema-de-consultorio-medico-virtual

•

Engenharias

Ingeniería Fácil

14/7/2022

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Ingeniería

49.169 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

UNIVERSIDAD NACIONAL
AUTÓNOMA DE MÉXICO
FACULTAD DE INGENIERÍA
DISEÑO DE UNA ARQUITECTURA SOA
APLICADA EN UN
SISTEMA DE CONSULTORIO MÉDICO VIRTUAL
TESIS
QUE PARA OBTENER EL TÍTULO DE
INGENIERO EN COMPUTACIÓN

PRESENTA:
EDUARDO GRANADOS CHAVARRÍA
DIRECTOR DE TESIS:
M. C. ALEJANDRO VELÁZQUEZ MENA
Ciudad Universitaria , México, D.F., Junio 2014.

UNAM – Dirección General de Bibliotecas
Tesis Digitales
Restricciones de uso

DERECHOS RESERVADOS ©
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL

Todo el material contenido en esta tesis esta protegido por la Ley Federal
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México).
El uso de imágenes, fragmentos de videos, y demás material que sea
objeto de protección de los derechos de autor, será exclusivamente para
fines educativos e informativos y deberá citar la fuente donde la obtuvo
mencionando el autor o autores. Cualquier uso distinto como el lucro,
reproducción, edición o modificación, será perseguido y sancionado por el
respectivo titular de los Derechos de Autor.

Para mis padres Ángel José Granados y Ma. Rosa Chavarría.
Hermanos Iván y Emmanuel.
A mis abuelitos:
José Granados QDEP – Amalia Palomo.
Prisciliano Chavarría – Juana Castañeda.

A mi Alma mater la Universidad Nacional Autónoma de México, Facultad de Ingeniería.

Un agradecimiento muy especial a Roció Arzate y Elizabeth Machuca.

Un saludo muy caluroso a mis amigos:
- Jaqueline Torres
- Gisela Pineda
- Ireri Raya
- Lucely Mata
- Haydeé Gómez
- César Vélez
- Yesica Hernández
- Fabiola Zarate
- Andrés Hernández

Colegas y amigos de Think and code:
- Eduardo Villegas
- Luis Nava
- Alejandro Hernández

INDICE
INTRODUCCIÓN ................................................................................................................................ 1
CAPÍTULO 1. MARCO TEÓRICO ...................................................................................................... 3
1.1 Arquitectura de Software ..................................................................................................... 3
1.2 Factores que guían el desarrollo de la arquitectura ............................................................ 4
1.2.1 Atributos de calidad en la arquitectura ........................................................................ 5
1.2.2 Recomendaciones para el desarrollo de la arquitectura ............................................. 7
1.2.3 Patrón de arquitectura ................................................................................................. 8
1.2.4 Estilo de arquitectura ................................................................................................... 9
1.2.5 Modelo de referencia ................................................................................................... 9
1.2.6 Arquitectura de referencia ........................................................................................... 9
1.3 Arquitectura Orientada a Servicios, SOA ............................................................................ 9
1.4 Principios de diseño de servicios ...................................................................................... 10
1.4.1 Los servicios son reusables ...................................................................................... 11
1.4.2 Los servicios comparten un contrato formal ............................................................. 12
1.4.3 Los servicios están débilmente acoplados ................................................................ 15
1.4.4 Los servicios son compuestos .................................................................................. 16
1.4.5 Los servicios son autónomos .................................................................................... 17
1.4.6 Los servicios guardan estado.................................................................................... 19
1.4.7 Los servicios deben poder ser descubiertos ............................................................. 20
1.4.8 Los servicios deben ser abstractos ........................................................................... 21
CAPÍTULO 2. MSOAM, UNA METODOLOGÍA GENÉRICA PARA SOA ......................................... 23
2.1 Modelo de servicios ........................................................................................................... 24
2.1.1 Servicios de entidad .................................................................................................. 25
2.1.2 Servicios de tarea ...................................................................................................... 25
2.1.3 Servicios de utilidad .................................................................................................. 26
2.2 Estrategia Top - down ....................................................................................................... 27

CAPÍTULO 3. ANÁLISIS ORIENTADO A SERVICIOS, PASO 3 ..................................................... 31
3.1 Modelado de servicios ....................................................................................................... 34
CAPÍTULO 4. DISEÑO ORIENTADO A SERVICIOS, PASO 4 ........................................................ 37
4.1 Paso 4.1: Compose SOA. ................................................................................................. 38
4.2 Paso 4.2: Diseño de servicios de entidad ......................................................................... 41
4.3 Paso 4.3: Diseño de servicios de aplicación ..................................................................... 43
4.4 Paso 4.4: Diseño de servicios de negocio o de tarea ....................................................... 44
4.5 Paso 4.5: Diseño de servicios de proceso de negocio ..................................................... 45
CAPÍTULO 5. ESPECIFICACIONES DEL SCMV. ........................................................................... 47
5.1 Alcance y requerimientos del sistema. .............................................................................. 47
5.2 Diseño de la arquitectura del sistema ............................................................................... 48
CAPÍTULO 6. ANÁLISIS ORIENTADO A SERVICIOS, PASO 3 ..................................................... 50
6.1.1 Paso 3.3. Modelado de servicios candidatos ........................................................... 50
CAPÍTULO 7. DISEÑO DEL SISTEMA, PASO 4 ............................................................................. 68
7.1 Paso 4.1: Compose SOA .................................................................................................. 68
7.2 Paso 4.2: Diseño de servicios de entidad ......................................................................... 69
7.3 Paso 4.3: Diseño de servicios de aplicación ..................................................................... 76
7.4 Paso 4.4: Diseño de servicios de negocio o de tarea ....................................................... 83
CAPÍTULO 8. DESARROLLO DEL SISTEMA. ................................................................................. 99
8.1 Tecnologías utilizadas. .................................................................................................... 100
8.2 Implementación ............................................................................................................... 103
8.3 Sistema Consultorio Médico Virtual, SCMV. ................................................................... 115
RESULTADOS Y CONCLUSIONES ............................................................................................... 124
GLOSARIO ......................................................................................................................................126
REFERENCIAS ............................................................................................................................... 128
ANEXO A. SERVICIO DE MENSAJERÍA Y DE DOCUMENTOS .................................................. 129
Servicio de documentos .............................................................................................................. 129
Servicio de mensajería ................................................................................................................ 134

Servicio de mensajes SMS ..................................................................................................... 139
ANEXO B. ENTIDADES .................................................................................................................. 141
ANEXO C. SERVICIOS DE ENTIDAD ............................................................................................ 149
ANEXO D. CONVENCIONES PARA ELECCIÓN DE NOMBRES ................................................. 163

INDICE DE TABLAS
Tabla 1-1 Factores de intereses. ........................................................................................................ 4
Tabla 1-2 Petición de CURP. ............................................................................................................ 14
Tabla 1-3 Claves de entidades federativas ....................................................................................... 15
Tabla 6-1Servicios candidatos. ......................................................................................................... 61
Tabla 6-2 Servicios candidatos refinados. ........................................................................................ 63
Tabla 7-1 Servicio entidad tipo estudio. ............................................................................................ 74
Tabla 7-2 Servicio entidad consulta. ................................................................................................. 75
Tabla 7-3 SERVICIO DE MENSAJERÍA. .......................................................................................... 79
Tabla 7-4 SERVICIO DE DOCUMENTOS. ....................................................................................... 81
Tabla 7-5 Servicios de aplicación. .................................................................................................... 82
Tabla 7-6 SERVICIOS DE ADMINISTRACIÓN DE CITAS. ............................................................. 87
Tabla 7-7 SERVICIO DE ADMINISTRACIÓN DE CONSULTORIOS. ............................................. 89
Tabla 7-8 SERVICIO DE ADMINISTRACIÓN DE EXPEDIENTE. ................................................... 92
Tabla 7-9 SERVICIO DE ADMINISTRACIÓN DE CATALOGOS ..................................................... 97
Tabla 8-1 Vistas en JSF. ................................................................................................................. 104
Tabla 8-2 Paquete de clases de control de las vistas. .................................................................... 105
Tabla 8-3 Servicios de tarea o de negocio. .................................................................................... 106
Tabla 8-4 Servicios de aplicación. .................................................................................................. 106
Tabla 8-5 Servicios de entidad. ....................................................................................................... 107
Tabla 8-6 Proceso Batch ................................................................................................................. 107
Tabla B-1 Entidad Auxiliar. .............................................................................................................. 141
Tabla B-2 Entidad Catálogo enfermedad. ....................................................................................... 141
Tabla B-3 Entidad catálogo medicamento. ..................................................................................... 141
Tabla B-4 Entidad catálogo tipo de estudio. ................................................................................... 142
Tabla B-5 Entidad catálogo tipo sangre. ......................................................................................... 142
Tabla B-6 Entidad Cita. ................................................................................................................... 142

Tabla B-7 Entidad Consulta. ........................................................................................................... 143
Tabla B-8 Entidad Consultorio. ....................................................................................................... 143
Tabla B-9 Entidad Datos de contacto. ............................................................................................ 144
Tabla B-10 Entidad Dirección. ........................................................................................................ 144
Tabla B-11 Entidad Expediente. ..................................................................................................... 145
Tabla B-12 Entidad Médico. ............................................................................................................ 145
Tabla B-13 Entidad Paciente. ......................................................................................................... 145
Tabla B-14 Entidad Prescripción. .................................................................................................... 145
Tabla B-15 Entidad Prescripción Pk. .............................................................................................. 146
Tabla B-16 Entidad Rol. .................................................................................................................. 146
Tabla B-17 Entidad Relación solicitud estudios. ............................................................................. 146
Tabla B-18 Entidad Relación solicitud estudios Pk. ........................................................................ 146
Tabla B-19 Entidad Solicitud estudio. ............................................................................................. 147
Tabla B-20 Entidad Usuario app. .................................................................................................... 147
Tabla B-21 Entidad Usuario Rol. ..................................................................................................... 148
Tabla B-22 Entidad Usuario rol Pk. ................................................................................................. 148
Tabla C-1 Servicio entidad usuario app. ......................................................................................... 149
Tabla C-2 Servicio entidad relación usuario y rol. .......................................................................... 150
Tabla C-3 Servicio Entidad Auxiliar. ................................................................................................ 151
Tabla C-4 Servicio entidad catálogo enfermedad. .......................................................................... 151
Tabla C-5 Servicio entidad catálogo medicamento. ....................................................................... 152
Tabla C-6 Servicio entidad catálogo tipo sangre. ........................................................................... 153
Tabla C-7 Servicio entidad Cita. ..................................................................................................... 155
Tabla C-8 Servicio entidad consultorio. .......................................................................................... 156
Tabla C-9 Servicio entidad datos de contacto. ............................................................................... 156
Tabla C-10 Servicio entidaddirección. ........................................................................................... 157
Tabla C-11 Servicio entidad expediente. ........................................................................................ 158
Tabla C-12 Servicio entidad médico. .............................................................................................. 159

III

Tabla C-13 Servicio entidad paciente. ............................................................................................ 160
Tabla C-14 Servicio entidad prescripción. ...................................................................................... 160
Tabla C-15 Servicio entidad rol. ...................................................................................................... 161
Tabla C-16 Servicio entidad relación solicitud de estudios............................................................. 161
Tabla C-17 Servicio entidad solicitud estudios. .............................................................................. 162

INDICE DE ILUSTRACIONES
Ilustración 1-1 Influencias de la arquitectura. ..................................................................................... 5
Ilustración 1-2 Representación de un servicio .................................................................................. 10
Ilustración 1-3 Principio de reusabilidad. .......................................................................................... 12
Ilustración 1-4 Principio de contrato formal ....................................................................................... 13
Ilustración 1-5 Principio de bajo acoplamiento. ................................................................................ 16
Ilustración 1-6 Principio de composición. .......................................................................................... 17
Ilustración 1-7 Principio de autonomía. ............................................................................................. 18
Ilustración 1-8 Principio de no guardar estado. ................................................................................ 20
Ilustración 1-9 Principio de servicios descubiertos. .......................................................................... 21
Ilustración 1-10 Los servicios deben ser abstractos. ........................................................................ 22
Ilustración 2-1 Metodología MSOAM. ............................................................................................... 23
Ilustración 2-2 Modelo de servicios. .................................................................................................. 24
Ilustración 2-3 Servicio de entidad. ................................................................................................... 25
Ilustración 2-4 Servicio de tarea. ....................................................................................................... 26
Ilustración 2-5 Servicio de utilidad. ................................................................................................... 27
Ilustración 2-6 Estrategia top – down. ............................................................................................... 27
Ilustración 3-1 Proceso de análisis de servicios. .............................................................................. 32
Ilustración 3-2 Pasos del modelado de servicios. ............................................................................. 33
Ilustración 4-1 Proceso de diseño de servicios. ................................................................................ 38
Ilustración 4-2 Compose SOA. .......................................................................................................... 39
Ilustración 4-3 Capas de servicios. ................................................................................................... 40
Ilustración 4-4 Diseño de servicios de proceso de negocio. ............................................................. 45
Ilustración 6-1 Servicios del SCMV. .................................................................................................. 63
Ilustración 6-2 Composición del servicio administración de usuarios. .............................................. 64
Ilustración 6-3 Composición del batch. ............................................................................................. 65
Ilustración 6-4 Composición del servicio administración de citas. .................................................... 66
Ilustración 7-1 Diagrama SCMV. ....................................................................................................... 69

Ilustración 7-2 Diagrama de entidades del SCMV parte 1. ............................................................... 71
Ilustración 7-3 Diagrama de entidades del SCMV parte 2. ............................................................... 72
Ilustración 7-4 Enviar prescripción médica ....................................................................................... 84
Ilustración 8-1 Diagrama de bloques del SCMV. .............................................................................. 99
Ilustración 8-2 Servicio de negocio, administración de citas. ......................................................... 108
Ilustración 8-3 Servicio de negocio, administración de consultorios. ............................................. 109
Ilustración 8-4 Servicio de negocio, administración de usuarios y expediéntenle. ......................... 110
Ilustración 8-5 Servicio de negocio, administración de catálogos. ................................................. 111
Ilustración 8-6 Composición de servicio, administración de consultorios. ...................................... 112
Ilustración 8-7 Composición de servicio, administración de usuarios. ........................................... 112
Ilustración 8-8 Composición de servicio, administración de citas. .................................................. 113
Ilustración 8-9 Composición de servicio, administración de expediente. ....................................... 113
Ilustración 8-10 Composición de servicio, administración de catálogos. ........................................ 114
Ilustración 8-11 Pantalla de presentación. ...................................................................................... 115
Ilustración 8-12 Registrar consultorio. ............................................................................................. 115
Ilustración 8-13 Listado de consultorios. ......................................................................................... 116
Ilustración 8-14 Registrar médico. .................................................................................................. 116
Ilustración 8-15 Listado de médicos. ............................................................................................... 117
Ilustración 8-16 Registrar paciente. ................................................................................................ 117
Ilustración 8-17 Listado de pacientes. ............................................................................................. 118
Ilustración 8-18 Crear consulta. ...................................................................................................... 118
Ilustración 8-19 Registrar cita de paciente registrado. .................................................................... 119
Ilustración 8-20 Registrar cita de paciente no registrado. ............................................................... 119
Ilustración 8-21 Listado de consultas del paciente. ........................................................................ 120
Ilustración 8-22 Correo electrónico de notificación de registro. ......................................................120
Ilustración 8-23 Mensaje de Twitter de notificación de registro. ..................................................... 121
Ilustración 8-24 Notificación de Twitter de cita agendada. ............................................................. 121
Ilustración 8-25 Recordatorio de cita vía Twitter. ............................................................................ 122

Ilustración 8-26 Envió de consulta médica por medio de correo electrónico.................................. 123
Ilustración A-1 Diagrama de bloques de servicio de documentos. ................................................. 129
Ilustración A-2 Diagrama de bloques de servicio de mensajería. ................................................... 134

Introducción.

INTRODUCCIÓN

En más de una ocasión me he encontrado con líderes de proyecto o arquitectos de software que
cometen el error de decir que una arquitectura SOA forzosamente se trata de desarrollar servicios
web y/o utilizar ciertas herramientas disponibles en el mercado, sin comprender su naturaleza de
servicio. Es por eso que decidí realizar el presente trabajo de tesis, que tiene como objetivo ilustrar
fácilmente qué y cuáles son las características de este tipo de arquitectura, sin requerir el uso de
herramientas sofisticadas. Adicionalmente, se identifican las ventajas de ésta y su ámbito de
aplicación, dejando de lado los argumentos sobre el uso forzoso de ciertas tecnologías o
productos. Posteriormente se implementa la metodología para realizar el análisis, diseño y
construcción de un sistema de administración de consultorios médicos, llamado “Sistema de
Consultorio Médico Virtual” (SCMV).

Este trabajo se divide en cuatro grandes partes:

Parte 1: Consta del Capítulo 1 donde se explica qué es arquitectura de software y se identifican
buenas prácticas aplicables en su formulación. Se define el concepto de Arquitectura Orientada a
Servicios (SOA, por sus siglas en inglés), explicándose los principios en los que se sustentan los
servicios asociados.

Parte 2: Abarca los Capítulos 2, 3 y 4. En el Capítulo 2 se explica una metodología genérica para
SOA llamada MSOAM, Mainstream SOA Methodology, que puede ser adaptada a las necesidades
específicas de un proyecto dado. En el Capítulo 3 se abarca un paso de la metodología llamado
“Análisis Orientado a Servicios”. En el Capítulo 4 se habla del paso “Diseño Orientado a Servicios”.

Parte 3: Comprende de los capítulos 5, 6 y 7. En el Capítulo 5 se menciona el alcance y
requerimientos que debe tener el SCMV. Tanto el Análisis Orientado a Servicios, como el Diseño
Orientado a Servicios se ponen en práctica en el ciclo de desarrollo del SCMV en los capítulos 6 y
7 respectivamente.

Introducción.

Parte 4: En el Capítulo 8 se explica cómo fue construido el SCMV siguiendo la metodología
MSOAM. Se detallan las tecnologías utilizadas en el desarrollo, seleccionadas siguiendo criterios
de robustez y simplicidad.
Capítulo 1. Marco teórico.

CAPÍTULO 1. MARCO TEÓRICO
Por Arquitectura de software, se conoce al diseño de más alto nivel de una aplicación, la palabra
“arquitectura” viene del griego αρχ que significa “jefe(a), quien tiene el mando”, y de τεκτων que
significa constructor o carpintero, dicho de otra manera, el arquitecto de software es quien dirige el
desarrollo del software.
En los siguientes subcapítulos se desarrollará el concepto, analizando los factores que intervienen
en esta actividad y apuntando a las buenas prácticas que la acompañan.

1.1 Arquitectura de Software
Existen varias definiciones del término Arquitectura de Software, aunque se enfocan en distintos
aspectos de la actividad, puede considerarse que se orientan en la misma dirección, y por lo tanto,
son complementarias.

“La arquitectura de software de un programa o sistema de cómputo es una representación del
mismo que ayuda a la comprensión de su comportamiento.
La arquitectura de software sirve como modelo para el sistema y el desarrollo del proyecto, define
las asignaciones de trabajo que deben ser llevadas a cabo por los equipos de diseño e
implementación. La arquitectura es el portador primario de las cualidades del sistema, tales como
rendimiento, mantenimiento, y seguridad, ninguna de las cuales se puede lograr sin una visión
arquitectónica unificadora. La arquitectura como artefacto facilita el análisis temprano, buscando
que un paradigma de solución se concrete en un sistema que cumpla con los requerimientos
establecidos. Cuando definida correctamente, la arquitectura permite identificar riesgos de diseño y
por lo tanto tomar acciones para mitigarlos en etapas tempranas del proceso de desarrollo” [5].

La arquitectura comienza por comprender las especificaciones del sistema con base en el QUÉ es
lo que se desea desarrollar. Posteriormente da una solución al CÓMO lograrlo, dictando las tareas
que realizarán los equipos de trabajo, así como las estructuras físicas y lógicas del sistema.
Además establece las especificaciones de diseño y las de construcción del sistema. Por lo que la
arquitectura es determinante para lograr un sistema funcional.
La arquitectura establece también la especificación de los elementos internos, su comportamiento
y forma de comunicación. Asimismo, en caso de interactuar con entidades externas, define la
manera en que estas interacciones ocurrirán.
Capítulo 1. Marco teórico.

1.2 Factores que guían el desarrollo de la arquitectura
Durante el desarrollo arquitectónico intervienen muchos factores, algunos de ellos son: los grupos
de interés, las necesidades de negocio, las limitaciones técnicas, la experiencia del equipo de
trabajo (en especial del arquitecto), etc. Estos factores establecen restricciones a la solución
arquitectónica, al mismo tiempo que definen cualidades requeridas en el sistema, tales como:
modificabilidad, eficiencia, mantenibilidad, interoperabilidad, confiabilidad, reusabilidad, facilidad de
ejecución de pruebas, etc.

Factores de intereses
Grupo de interés Interés
Cliente Bajo costo, entrega oportuna
Usuario final Rendimiento, seguridad, usabilidad, redituable
Mantenimiento Modificable
Líderes de proyecto Entregas oportunas
Hardware Capacidad de procesamiento, interfaces
Sistemas externos/legados Interfaces establecidas
Tabla 1-1 Factores de intereses.

La arquitectura puede recibir retroalimentación de los mismos grupos de interés, además de
ayudar a reforzar la experiencia del arquitecto, es posible que se reconsideren decisiones previas
en busca de posibles debilidades y, por ende, agregar nueva infraestructura, también pueden
identificarse elementos reutilizables.
En algunos casos los usuarios del sistema pueden realizar recomendaciones para que éste sea
más fácil y eficiente sin descuidar los requerimientos ya establecidos.

Capítulo 1. Marco teórico.

Ilustración 1-1 Influencias de la arquitectura.

1.2.1 Atributos de calidad en la arquitectura
Para poder decir que el diseño de la arquitectura es adecuado para el sistema, cubriendo en la
medida de lo posible todas las necesidades, se debe realizar una evaluación de sus atributos de
calidad, que son requerimientos adicionales a los funcionales. Estos atributos están fuertemente
entrelazados y trabajan en conjunto, generalmente no es posible cumplir con todos al 100% o
beneficiar a uno sin afectar a otro. La arquitectura debe alcanzar un punto en el que se cumplan
todos los atributos de manera aceptable.
Los atributos de calidad son clasificados en:
 Requisitos funcionales
 Requisitos no funcionales

1.2.1.1 Requisitos funcionales
Estos atributos se ven reflejados en tiempo de ejecución del sistema
 Rendimiento
Es la capacidad de respuesta para ejecutar una acción enun determinado tiempo, por
ejemplo, la cantidad de información o transacciones que pueden ser procesadas. Aquí se
ven involucrados los algoritmos implementados, la capacidad de la red para sistemas
distribuidos.
 Seguridad interna
Se refiere a la capacidad del sistema para evitar el uso indebido o alteración de los
servicios por usuarios no autorizados.
Capítulo 1. Marco teórico.

 Confidencialidad
Se encarga de que los datos o servicios estén protegidos contra el acceso no permitido.
 Integridad
Procura que los datos o servicios sean entregados bajo las condiciones acordadas.
 Garantía
En una transacción asegura que la identificación de las partes involucradas sea verificada.
 Auditoría
Es la propiedad que capacita al sistema para llevar un seguimiento de las actividades
realizadas, esto permite la reconstrucción de lo sucedido.
 Seguridad externa
Este atributo se encarga de disminuir daños a la información y al sistema que pudieran
ocasionar eventos externos no tecnológicos, por ejemplo: interrupciones eléctricas,
incendios, derrumbes, etc.
 Disponibilidad y fiabilidad
La disponibilidad es la propiedad de que el sistema esté en correcto funcionamiento,
fiabilidad es el tiempo medio entre fallos, la disponibilidad puede evaluarse a partir del
siguiente modelo:
reparacióndemediotiempofallosentremediotiempo
fallosentremediotiempo
idadDisponibil



 Funcionalidad
Es la habilidad para realizar de forma correcta las tareas asignadas, aquí se involucra tanto
la asignación de cargas de trabajo como la correcta operación de los datos.
 Usabilidad
Es la facilidad y comodidad que el sistema ofrece a los usuarios para su uso, además de
los apoyos que ofrezca.
o Facilidad de aprender las características del sistema e interfaz de usuario
o Uso eficiente del sistema aprovechando sus capacidades
o Disminución de los errores que puedan ocurrir y ayuda para corregirlos
o Adaptación del sistema a las necesidades del usuario
o Incremento de la confianza y satisfacción

Capítulo 1. Marco teórico.

1.2.1.2 Requisitos no funcionales
Atributos no apreciables en tiempo de ejecución.
 Modificabilidad y mantenibilidad
Es la habilidad del sistema para realizar cambios en sí mismo, módulos, componentes,
relaciones sin que estos afecten a otras secciones y al mismo tiempo no sean muy
costosos o requieran una gran inversión de tiempo.
 Portabilidad
Es la capacidad de un sistema para ser ejecutado en distintos ambientes, software o
hardware. Por ejemplo, un servidor de aplicación de otra compañía, una actualización del
servidor o del sistema operativo.
 Reusabilidad
Esta capacidad procura que los distintos componentes del sistema puedan ser utilizados
por otros componentes del mismo, incluso nuevos sistemas, con el fin de ahorrar tiempos
de construcción y de inversión.
 Integridad
Esta capacidad se refiere a la correcta funcionalidad y coordinación de los componentes,
donde cada uno tiene asignada cierta responsabilidad para comunicarse a través de
interfaces conocidas por los mismos.
 Facilidad de ejecución de pruebas
Es la capacidad del sistema sea probado por secciones y, en caso de que ocurra un fallo,
éste pueda ser localizado.

1.2.2 Recomendaciones para el desarrollo de la arquitectura
A continuación se listan algunas recomendaciones para el desarrollo de una arquitectura, no son
reglas obligatorias o absolutas pero pueden considerarse como una buena práctica, se dividen en
dos grupos.
Recomendaciones de proceso.
 La arquitectura debe ser desarrollada por un arquitecto o un grupo pequeño de arquitectos
(designando un líder).
 Listar los requerimientos funcionales y priorizar los atributos de calidad deseados.
Capítulo 1. Marco teórico.

 Documentar la arquitectura, al menos una visión estática y una dinámica, que pueda ser
interpretada por los involucrados en el sistema.
 La arquitectura debe revisarse por las partes interesadas en el sistema.
 La arquitectura se debe revisar con un análisis cuantitativo, por ejemplo el rendimiento
máximo, y evaluar los atributos de calidad.
 El diseño arquitectónico debe procurar ser incremental para facilitar la integración de
futuros elementos.
Se deben especificar áreas de recursos limitados, por ejemplo, si la utilización de la red es un área
de preocupación, hay que proporcionar guías al equipo de desarrollo para que hagan el menor uso
posible de los recursos de red, estas guías deberán especificar como lograr un desarrollo correcto
y eficiente.
Recomendaciones estructurales.
 La arquitectura debe tener módulos bien definidos que cumplan con los principios de
separación de responsabilidades y encapsulamiento de la información.
 Los módulos deben contar con interfaces bien definidas, ocultando la implementación, con
el fin de que los equipos trabajen de forma independiente.
 Se deben aplicar tácticas arquitectónicas que puedan ayudar a satisfacer los atributos de
calidad.
 El diseño no debe depender de una herramienta específica o versión, de otro modo hay
que procurar que el cambio de un producto sea lo más transparente posible.
 Separar los módulos que producen datos de los que los consumen. Se reduce la
posibilidad de que la modificación de un módulo de bajo nivel tenga un impacto en los
módulos que lo utilizan.
 En procesamientos paralelos, hay que identificar y analizar los puntos críticos.
 Los procesos y tareas deben ser documentados, de tal forma que si hay la necesidad de
realizar cambios, estos puedan ser ubicados y realizados.
 La arquitectura debe tener un número pequeño de patrones de interacción, es decir, se
deben hacer las mismas cosas de la misma forma en todas partes. Esto demuestra un
diseño integral, mejorando la legibilidad, el tiempo de desarrollo, la fiabilidad, y
mantenimiento del sistema.

1.2.3 Patrón de arquitectura
Describe un problema que ocurre frecuentemente en un entorno. Para resolverlo es necesario describir
el núcleo de la solución del problema, de tal manera que ésta pueda ser utilizada un sinnúmero de
veces sin requerir de un rediseño.
Capítulo 1. Marco teórico.

Los patrones deben contener cuatro secciones fundamentales, nombre del patrón, problema,
solución y consecuencias. Esto favorece la reutilización de código, ahorro de tiempo y disminución
de posibles problemas.
El incremento en el conocimiento de los patrones permite realizar agrupaciones de patrones
sólidos, llamados lenguajes de patrones. Los lenguajes de patrones definen los estilos
arquitectónicos con los que se forman sistemas completos y robustos.

1.2.4 Estilo de arquitectura
Es un conjunto de componentes y patrones que definen la transferencia y control de la información,
también dicta los tipos de componentes que pueden utilizarse y su interacción. El estilo de la
arquitectura es una vista a un nivel más abstracto que los patrones.

1.2.5 Modelo de referencia
No se trata propiamente de una arquitectura. Es una descomposición estándar de un problema en
unidades funcionales que resuelven una tarea específica: cuando interactúan conjuntamente
resuelven el problema mayor.

1.2.6 Arquitectura de referencia
Esta puede verse como la aplicación de un modelo de referencia en los componentes de software,
no necesariamente con una relación uno a uno. La arquitectura de referencia define la
infraestructura común a todos los sistemas del dominio (componentes, subsistemas, interfaces).
El considerar una arquitectura de referencia facilita el desarrollo de nuevos sistemas, debido a que
se integran guías de cómo desarrollar, facilitando la reutilización de modelos y componentes.

1.3 Arquitectura Orientada a Servicios, SOA
SOA nace a partir de la necesidad de desarrollar sistemas que no tengan una alta dependencia de
la infraestructura tecnológicao de algún otro sistema. Realizar cambios en un sistema para adaptar
nueva funcionalidad, realizar modificaciones de negocio o cambiar componentes tiene un elevado
costo, tanto económicamente, como de tiempo y recursos.
SOA es un estilo de arquitectura de software basado en la operación conjunta y coordinada de
servicios, los cuales son la base de este modelo de arquitectura.
Capítulo 1. Marco teórico.

Un servicio es la encapsulación de una funcionalidad de negocio bien definida, diseñado de tal
manera que pueda ser reutilizado con facilidad. Un servicio a su vez puede estar formado por otros
servicios, trabajar de forma distribuida abstrayendo la complejidad asociada a las comunicaciones,
incluso puede estar conformado por una o más operaciones de más bajo nivel.
Ejemplos de servicios pueden ser la verificación del saldo de una cuenta, el envío de un mensaje o
la validación de una clave CURP.

Ilustración 1-2 Representación de un servicio

SOA tiene como objetivo el desarrollo de sistemas que tengan la facilidad y la rapidez para
soportar cambios tecnológicos o de lógica de negocio, incluso ser capaces de integrarse con
sistemas externos o legados, estas características dan como ventaja el ahorro de tiempo y
reducción de costos.
Los servicios cuentan con una interfaz en la que describen los parámetros de entrada y de salida,
por lo que la implementación queda oculta. La comunicación entre ellos se debe realizar a través
del intercambio de mensajes estandarizados con el fin de disminuir el acoplamiento entre los
mismos.
En muchas ocasiones cuando se habla de SOA, por error suele relacionarsele inmediatamente con
servicios web (web-services), si bien esta tecnología brinda un gran soporte para el desarrollo de
servicios distribuidos con una implementación final oculta, no son estríctamente necesarios para
desarrollar una SOA.
Es posible hacer SOA con alguna otra tecnología de comunicación remota o incluso dentro del
mismo sistema se puede tener servicios si cumplen con las características y con los principios de
diseño que se mencionan a continuación.

1.4 Principios de diseño de servicios
El diseño de una SOA tiene como objetivos ser robusta, escalable, integra y reutilizable. Para
lograr dichos objetivos es buena práctica que los servicios que la componen estén diseñados
Capítulo 1. Marco teórico.

siguiendo ciertos principios. Aunque estos principios no son obligatorios sí es recomendable
seguirlos en la medida de lo posible.
Los primeros cuatro son fundamentales, los últimos derivan indirectamente de los primeros:
 Los servicios son reusables
 Los servicios comparten un contrato formal
 Los servicios están débilmente acoplados
 Los servicios son compuestos
 Los servicios son autónomos
 Los servicios deben ser abstractos
 Los servicios no guardan estado
 Los servicios deben poder ser descubiertos

1.4.1 Los servicios son reusables
Los servicios tienen y expresan una lógica agnóstica con lo que pueden ser utilizados por múltiples
servicios y/o sistemas.
Objetivos
 Permitir la adecuación rápida y de bajo costo a las nuevas necesidades del negocio
 Generar un catálogo de servicios genéricos, capaces de ser utilizados por distintos clientes
Características
 Su diseño debe ser agnóstico a la tecnología
 Su lógica debe ser genérica y puntual, de modo que pueda ser utilizada en distintos
escenarios, servicios o sistemas

Capítulo 1. Marco teórico.

Ilustración 1-3 Principio de reusabilidad.

 Deben poder ser consumidos de forma simultánea
 Deben tener contratos genéricos capaces de procesar una amplia gama de entradas y
salidas

Ejemplo
Un sistema empresarial tiene el servicio de administración de personal el cual tiene operaciones
para crear, dar de baja, consultar y modificación del personal, este servicio se presta a ser
altamente reusable por ejemplo, si dentro de la organización hay un sistema la impartición de
cursos al personal: se poder realizar una integración con el servicio de Administración personal de
modo que se tenga la información de las personas y obtener de ellas cierta información cómo
podría ser, departamento o gerencia, puesto, puesto, entre otros.

1.4.2 Los servicios comparten un contrato formal
Un contrato de servicio es la especificación del servicio, en el cual se debe mencionar:
Cómo debe ser consumido
Su ubicación
Reglas y características de las operaciones (métodos) que ofrece, entre ellas los mensajes de
entrada y de salida

Capítulo 1. Marco teórico.

Objetivos
 Proporcionar la información necesaria para que el servicio pueda ser utilizado de forma
correcta
Características
 Debe procurar usar estándares de comunicación
 Debe estar debidamente documentado:
 Nombre del servicio
 Propietario del servicio
 Tipo de servicio
 Ubicación
 Fecha de liberación
 Versión
 Dominio
 Propósito
 Operaciones del servicio
 Mensaje de entrada
 Mensaje de salida
 Etc.

Ilustración 1-4 Principio de contrato formal

Ejemplo
Contrato para un servicio que genera el CURP.
SERVICIO GENERACIÓN DE CURP.
Propietario del servicio Área de RH
Tipo de servicio Utilitario
Capítulo 1. Marco teórico.

Ubicación http://empresa.com.mx/servicios/utileria/curp
Fecha de liberación 10/01/2013
Versión 1.0
Descripción Obtener la clave del CURP de una persona
Operación Obtener CURP
Mensaje de entrada Campo Tipo de dato Tamaño Obligatorio
Apellido paterno Alfanumérico 40 Sí
Apellido materno Alfanumérico 40 Sí
Nombre Alfanumérico 40 Sí
Fecha de nacimiento Numérico
Formato
(AAAADDMM)
8 Sí
Género Alfanumérico
Femenino: F
Masculino: M
1 Sí
Entidad de Nacimiento

Clave conforme al catálogo
de Claves Alfanuméricas de
Entidades Federativas
Alfanumérico

2 Sí
Mensaje de salida Campo Tipo de dato Tamaño Obligatorio
CURP Alfanumérico 18 Sí
Tabla 1-2 Petición de CURP.

Capítulo 1. Marco teórico.

CLAVES ALFANUMÉRICAS DE ENTIDADES FEDERATIVAS
ESTADO CLAVE ESTADO CLAVE ESTADO CLAVE
AGUASCALIENTES AS GUERRERO GR QUINTANA ROO QR
BAJA CALIFORNIA BC HIDALGO HG SAN LUIS POTOSI SP
BAJA CALIFORNIA
SUR
BS JALISCO JC SINALOA SL
CAMPECHE CC MÉXICO MC SONORA SR
COAHUILA CL MICHOACAN MN TABASCO TC
COLIMA CM MORELOS MS TAMAULIPAS TS
CHIAPAS CS NAYARIT NT TLAXCALA TL
CHIHUHUA CH NUEVO LEON NL VERACRUZ VZ
DISTRITO FEDERAL DF OAXACA OC YUCATÁN YN
DURANGO DG PUEBLA PL ZACATECAS ZS
GUANAJUATO GT QUERETARO QT
NACIDO EN EL
EXTRANJERO
NE
Tabla 1-3 Claves de entidades federativas

1.4.3 Los servicios están débilmente acoplados
Los servicios deben idealmente ser capaces de adaptarse a cambios en sus dependencias en el
menor tiempo posible, a bajo costo y de manera transparente.
El bajo acoplamiento significa tener poca dependencia entre servicios, de modo que si un servicio
sufre un cambio o es sustituido por otro, los servicios dependientes se vean afectados lo menos
posible teniendo los mismos o mejores resultados.
Objetivos
 Disminuir las dependencias fuertes entre servicios
 Poder realizar cambios a bajo costo y en el menor tiempo posible

Capítulo 1. Marco teórico.

Características
 Para lograr bajo acoplamiento las llamadas a los servicios se hacen a través de interfaces,
de este modo la implementación queda oculta, de modo que si se realiza un cambio, el
servicio cliente no se vea afectado

Ilustración 1-5 Principio de bajo acoplamiento.

Ejemplo
Un sistema que depende de un servicio de envío de correo electrónico hace los envíos de correos
a través de Yahoo! con el dominio de la empresa, sin embargo, con el pasar de los años
encontraron que Google ofrecía mejores paquetes para el servicio de correo y por ello deciden
migrar su dominio paraque puedan enviar el correo con la misma dirección.
El realizar este cambio solo se modifica la lógica del servicio del correo, su contrato y la lógica del
sistema que usa este servicio no se ve afectada y puede continuar trabajando como si nada
hubiera ocurrido.

1.4.4 Los servicios son compuestos
En ocasiones en un servicio puede estar compuesto por otros, de modo este conjunto de servicios
pueden encargarse de resolver una tarea más compleja. Este principio puede ser un poco contrario
al principio de autonomía explicado más adelante.
Objetivos
 Reducir código
 Facilitar la ejecución de tareas complejas
Capítulo 1. Marco teórico.

Características
 Los servicios que componen el servicio compuesto deben ser suficientemente eficientes
para manejar la concurrencia
 Los contratos de los servicios deben ser flexibles para poder ser consumidos por otros
servicios, o intercambiar tipos de datos
Ejemplo
Suponiendo que se desea crear una cita al médico, este servicio puede ser compuesto por tres
servicios: guardar el registro de la cita, enviar una notificación electrónica con los datos de la cita y
guardar los logs del proceso.

Ilustración 1-6 Principio de composición.

1.4.5 Los servicios son autónomos
Se debe procurar que los servicios tengan control de sí mismos para realizar sus tareas sin tener
dependencias de factores o actores externos a su entorno.
Capítulo 1. Marco teórico.

Objetivos
 Aumentar el rendimiento del servicio
 Dar mayor autocontrol al servicio

Características
 Los servicios tienen un contrato en el que se determina explícitamente su funcionalidad a
la que no puede superponerse otro servicio
 El ambiente donde los servicios son desplegados debe permitir una alta concurrencia y ser
escalable
Ejemplo
En una empresa el Departamento de Financiamiento debe cumplir con las siguientes tareas para
procesar un financiamiento.
 Comprobar nombre
 Verificar antecedentes
 Verificar ubicación
El Departamento de financiamiento tiene en su poder la información para poder validar el nombre y
la ubicación, sin embargo, la revisión de los antecedentes es manejada por el departamento de
pagos, los cuales pueden ser consultados por el área de financiamiento, esto implica que la
autonomía del Departamento de Financiamiento se ve un poco afectada.

Ilustración 1-7 Principio de autonomía.
Capítulo 1. Marco teórico.

1.4.6 Los servicios guardan estado
Cada petición al servicio debe ejecutarse de forma independiente a las peticiones previas, no debe
guardar información de sesión de quién lo haya ejecutado.
Objetivos
 Incrementar la escalabilidad
 Aumentar la lógica agnóstica del servicio
Características
 Los servicios deben ser de bajo acoplamiento y altamente independientes a la lógica del
negocio
 Los contratos de los servicios deben ser flexibles capaces de permitir la transmisión de
información del estado en tiempo de ejecución
Ejemplo
Los servicios no deben guardar un estado o sesión de quien los invoca, esto incrementaría el
acoplamiento y por lo tanto la escalabilidad también se vería afectada. El rendimiento de un
servicio se ve afectado al tener que estar almacenando una sesión por cada uno de los clientes, el
estado que guarden los servicios solo es momentáneo, durante el tiempo en el que entregan una
respuesta, después la sesión o estado se pierde.

Capítulo 1. Marco teórico.

Ilustración 1-8 Principio de no guardar estado.

1.4.7 Los servicios deben poder ser descubiertos
Este principio está muy ligado al contrato de los servicios, debe existir un mecanismo de inventario
de servicios en los que se especifique su funcionalidad y cómo poder acceder a ellos.
Objetivos
 Exponer las funcionalidades de los servicios
 Evitar la creación de servicios redundantes duplicando lógica
Características
 Se debe contar con un registro de los servicios existentes y agregar los servicios nuevos
que son creado

Capítulo 1. Marco teórico.

Ejemplo
Cuando se desarrolla un sistema se crea un directorio de servicios, en el que se puede consultar
su contrato, de esta forma cuando se necesite cierta lógica se puede consultar si ya existe un
servicio que cumpla los requerimientos, de lo contrario, proseguir con el desarrollo necesario.

Ilustración 1-9 Principio de servicios descubiertos.

1.4.8 Los servicios deben ser abstractos
El propósito de un servicio es realizar sus tareas sin importar cómo opera internamente,
simplemente debe arrojar los resultados obtenidos, de esta forma parecerán como una caja negra,
dando importancia al ¿qué? y no al ¿cómo?
Objetivos
 Ocultar el funcionamiento interno del servicio a los clientes
 Proporcionar la información requerida para la ejecución del mismo
Características
 Los servicios presentan puntualmente la información requerida para su ejecución
 El contrato del servicio no muestra información de cómo está construido
Ejemplo
Suponiendo que el ejemplo del servicio de generación del CURP fuera expuesto a través un
servicio web, el cual podría ser consumido sin ningún problema sin saber el lenguaje que utiliza por
dentro, ya sea Java, .Net, C++, etc.
Capítulo 1. Marco teórico.

Ilustración 1-10 Los servicios deben ser abstractos.
Capítulo 2. MSOAM, una metodología genérica para SOA.

CAPÍTULO 2. MSOAM, UNA METODOLOGÍA GENÉRICA PARA
SOA

En este Capítulo se describe la metodología MSOAM (Mainstream SOA Methodology) propuesta
por Thomas Erl [2], el motivo principal por el que fue elegida es que es bastante genérica y permite
ser adecuada a las necesidades del proyecto en el que se esté implementando, también permite
una libre elección de herramientas tecnológicas utilizadas.
Análisis y diseño son los dos primeros pasos de MSOAM. Estos pasos definen las características de
cómo se debe desarrollar una arquitectura orientada a servicios.

Ilustración 2-1 Metodología MSOAM.

Los pasos de esta metodología deben ser organizados en un proceso que:
 Satisfaga las preferencias de qué tipos de capa de servicios deseamos ofrecer
 Coordine la liberación de las aplicaciones y servicios en tiempo y forma
 Apoye la transición hacia una arquitectura SOA al mismo tiempo que ayuda a satisfacer las
necesidades inmediatas, específicas del sistema
Para llevar a cabo los puntos anteriores hay que seguir una estrategia basada en las prioridades
de la organización y mediar los objetivos de la migración a largo plazo con los requisitos a corto
plazo. MSOAM se basa en una estrategia top – down.
En el enfoque Top – down los servicios son analizados a fondo y diseñados con el fin de ser
escalables y reutilizados. Esta estrategia requiere tiempo y dinero debido a que los primeros pasos
Capítulo 2. MSOAM, una metodología genérica para SOA.

pueden tomar un tiempo considerable, por lo cual los resultados no son evidentes de manera
inmediata.

2.1 Modelo de servicios
Modelo de servicios es la clasificación de los tipos de servicios que existen en un sistema de
acuerdo a tres características básicas:
 Tipo de lógica que encapsulan
 Grado de reutilización
 Relación de la lógica con los dominios del negocio
Conforme a estas características los servicios pueden agruparse en tres principales categorías:
 Servicios de entidad
 Servicios de tarea
 Servicios de utilidad
Dependiendo del análisis y necesidades requeridas puede ser necesario crear una subcategoría
para hacer frente a una necesidad más específica.

Ilustración 2-2 Modelo de servicios.

Un servicio candidato es aquel que se identifica en el análisis inicial, una vez que se determina
que realmente debe ser desarrollado y si será expuesto o interno, se le llamará formalmente
servicio.
De igualmanera se aplica a las operaciones, inicialmente son operaciones candidatas que serán
evaluadas para determinar si serán implementadas.

Capítulo 2. MSOAM, una metodología genérica para SOA.

2.1.1 Servicios de entidad
También conocidos como servicios de negocio centrados en entidad o servicios de entidad de
negocio. En inglés: entity services, entity centric business services o business entity
services.
Su finalidad es dar soporte a las operaciones de administración de las entidades de negocio, tales
como operaciones CRUD.
Este tipo de servicios suele tener un alto grado de reutilización debido a que los servicios de tarea
hacen uso de estos para darle sentido al negocio de la organización.
Ejemplos de servicios de entidad:
 Empleado
 Cliente
 Factura

Ilustración 2-3 Servicio de entidad.

2.1.2 Servicios de tarea
Estos servicios realizan tareas un tanto más complejas que contienen propiamente el negocio y/o
reglas de negocio, usualmente están compuestos por otros servicios, tanto de entidad como de
tarea. Cuando su lógica es altamente compleja tienden a ser menos reutilizables.
Ejemplos de servicios de tarea:
 Contaduría
 Administración de usuarios
 Mensajería

Capítulo 2. MSOAM, una metodología genérica para SOA.

Ilustración 2-4 Servicio de tarea.

Un conjunto de servicios pueden formar parte de un proceso de negocio padre, es posible que
estos estén desarrollados como componentes independientes o como servicios web, incluso estar
alojados en una plataforma especializada en orquestación, para el último caso las características
de diseño son un tanto distintas debido a la naturaleza de la tecnología subyacente, es
conveniente nombrarlo como servicio de orquestación o de tarea orquestada.
Los servicios de tarea también son llamados servicios de negocio centrados en tarea, servicios de
proceso de negocio (task services, task-centric business services, business process services).
Mientras que a los servicios orquestados se les conoce por otros nombres como servicios de tarea
orquestados, servicios de proceso de negocio (En inglés, process services, business process
services, orchestration services).

2.1.3 Servicios de utilidad
Los servicios utilitarios también son conocidos como servicios de aplicación, servicios de
infraestructura o servicios de tecnología, en inglés utility services, application services,
infrastructure services, technology services.
Estos servicios no encapsulan lógica de negocio, se dedican a proporcionar funcionalidad
reutilizable, transversal, por ejemplo, registro de eventos, mensajería, manejo de excepciones, etc.
Estos pueden ser fácilmente reutilizados por otros sistemas ya que son de uso general. En este
tipo de servicios hay una especialización llamada servicios wrapper, estos servicios hacen las
veces de un adaptador para interactuar con sistemas legados o externos, exponiendo una interfaz
de la funcionalidad heredada que envuelven.
Ejemplos de servicios utilitarios:
 Log
Capítulo 2. MSOAM, una metodología genérica para SOA.

 Exportación de archivo
 Enviar correo

Ilustración 2-5 Servicio de utilidad.

2.2 Estrategia Top - down
En esta estrategia primero se realiza un análisis y promueve el desarrollo de tres capas de
servicios, capa de aplicación, capa de negocio y capa de orquestación. Top – down se basa en los
pasos mostrados en la siguiente figura, es posible que no se implementen todos ellos, los
requisitos de negocio deben estar ya establecidos ya que no son parte de esta estrategia.

Ilustración 2-6 Estrategia top – down.

 Paso 1. Definir ontología
Se debe clasificar la información con la que se trabaja con el fin de tener un vocabulario
común y cómo se relacionan los diferentes términos, para que todos los involucrados en la
solución tengan el mismo contexto de los términos.
Capítulo 2. MSOAM, una metodología genérica para SOA.

 Paso 2. Alinear los modelos de negocio relevantes
Aquí se generan o ajustan modelos que brinden una correcta interpretación del negocio.
Entre los modelos que pueden emplearse se encuentran diagramas de entidades que
pueden ser utilizados como base para desarrollar los servicios de entidad.

 Paso 3. Realizar un análisis orientado a servicios
Este paso está subdividido en tres, en el primero se identifican las necesidades de negocio
para identificar que se requiere construir; en el segundo se identifica si hay sistemas o
servicios existentes que puedan seguir siendo utilizados. Por último se realiza el modelado
de los servicios, es decir, se da forma a los servicios con base en la información recabada
previamente.

Este se abordará a profundidad en el “CAPÍTULO 3. ANÁLISIS ORIENTADO A
SERVICIOS, PASO 3”.

 Paso 4. Realizar el diseño orientado al servicio
En este paso se realizan las especificaciones finales de los servicios, entre ellas las
interfaces de los servicios, el cómo deben interactuar entre ellos, se especifican las capas
de la solución que contendrán a los distintos tipos de servicios.
Este se abordará a profundidad en el “CAPÍTULO 4. DISEÑO ORIENTADO A SERVICIOS,
PASO 4”.

 Paso 5. Desarrollar los servicios requeridos
En este paso se realiza el desarrollo de los servicios con forme a las especificaciones de
diseño del Paso 4.

 Paso 6. Pruebas de los servicios
En este paso se realizan pruebas a los servicios para validar que cumplen con la calidad y
especificaciones requeridas, se revisa que los servicios satisfagan las necesidades de
todos sus consumidores.

 Paso 7. Despliegue de los servicios
Los servicios son desplegados en producción, para ello debe considerarse que el ambiente
en el que son alojados es el adecuado para que trabajen satisfactoriamente.

Capítulo 2. MSOAM, una metodología genérica para SOA.

Para tener un panorama general de todos los pasos de MSOAM se agrega la siguiente tabla.
MSOAM
1. Definir ontología.
2. Alinear los modelos de negocio relevantes.
3. Realizar un análisis orientado a servicios.
3.1. Definir las necesidades de automatización del negocio.
3.2. Identificar sistemas de automatización existentes.
3.3. Modelado de servicios candidatos.
3.3.1. Descomponer el proceso de negocio.
3.3.2. Identificar operaciones de los servicios candidatos.
3.3.3. Abstraer la lógica de orquestación.
3.3.4. Crear servicios de negocio candidatos.
3.3.5. Refinar y aplicar los principios de orientación a servicios.
3.3.6. Identificar composiciones de servicios candidatos.
3.3.7. Revisar la agrupación de las operaciones de servicio de negocio.
3.3.8. Analizar los requerimientos de procesamiento de aplicación.
3.3.9. Identificar las operaciones de servicios de aplicación candidatos.
3.3.10. Crear servicios de aplicación candidatos.
3.3.11. Revisar composiciones de servicios candidatos.
3.3.12. Revisar la agrupación de los servicios de aplicación candidatos.
3.3.13. (Opcional) Mantener un inventario de servicios candidatos.
4. Realizar el diseño orientado al servicio.
4.1. Compose SOA.
4.1.1. Seleccionar capas de servicio.
4.1.2. Estándares.
4.1.3. Extensiones SOA.
4.2. Diseño de servicios de entidad.
4.2.1. Revisar servicios existentes.
4.2.2. Definir los parámetros (mensajes) de entrada y salida.
4.2.3. Especificar una interfaz inicial del servicio.
4.2.4. Aplicar los principios de orientación a servicios.
4.2.5. Estandarizar y refinar la interfaz del servicio.
4.2.6. Extender el diseño del servicio.
4.2.7. Identificar el procesamiento requerido.
4.3. Diseño de servicios de aplicación.
4.3.1. Revisar servicios existentes.
Capítulo 2. MSOAM, una metodología genérica para SOA.

4.3.2. Confirmar el contexto.
4.3.3. Especificar una interfaz inicial del servicio.
4.3.4. Aplicar principios de orientación a servicios.4.3.5. Estandarizar y refinar la interfaz del servicio.
4.3.6. Especular características funcionales al servicio.
4.3.7. Identificar limitaciones técnicas.
4.4. Diseño de servicios de negocio o de tarea.
4.4.1. Definir la lógica del flujo de trabajo (workflow).
4.4.2. Especificar una interfaz inicial del servicio.
4.4.3. Aplicar principios de orientación a servicios.
4.4.4. Estandarizar y refinar la interfaz del servicio.
4.4.5. Identificar el procesamiento requerido.
4.5. Diseño de servicio orientados al proceso de negocio.
4.5.1. Mapear los escenarios de interacción.
4.5.2. Diseñar interfaz del servicio de proceso.
4.5.3. Formalizar conversaciones entre servicios asociados
4.5.4. Definir lógica del proceso.
4.5.5. Alinear escenarios de interacción y perfeccionar el proceso.
5. Desarrollar los servicios requeridos
6. Probar los servicios.
7. Desplegar los servicios.

Capítulo 3. Análisis orientado a servicios, proceso 1.

CAPÍTULO 3. ANÁLISIS ORIENTADO A SERVICIOS, PASO 3

En el proceso de análisis se determina cuáles y cómo pueden ser soportadas las tareas de negocio
dentro de una arquitectura orientada a servicios. El análisis busca dar respuesta a las preguntas:
 ¿Qué servicios se deben construir?
 ¿Qué lógica debe encapsular cada servicio?
Los objetivos del análisis orientado a servicios son:
 Definir un conjunto preliminar de operaciones candidatas
 Agrupar las operaciones en contextos lógicos, estos contextos constituyen los servicios
candidatos
 Definir los límites de los servicios preliminares, evitando que se superpongan con otros
 Identificar la lógica con alto grado de reutilización
 Asegurar que el contexto de la lógica encapsulada es adecuado para su uso previsto
 Definir modelos de composición preliminares
El proceso de análisis se subdivide en tres pasos:
1. Definir las necesidades de automatización del negocio
2. Identificar sistemas de automatización existentes
3. Modelado de servicios candidatos

Capítulo 3. Análisis orientado a servicios, proceso 1.

Ilustración 3-1 Proceso de análisis de servicios.

Paso 3.1. Definir las necesidades de automatización del negocio.
En este paso se realiza el análisis de los requerimientos de negocio, tomando en cuenta
principalmente el alcance que tendrá la solución.
Para que un proceso de automatización pueda ser definido es necesario que los requerimientos del
negocio tengan la suficiente madurez. La información obtenida en este paso puede ser utilizada
como punto de entrada para el paso 3.

Paso 3.2. Identificar sistemas de automatización existentes.
En este paso se revisan los sistemas ya implantados con el objetivo de validar la lógica de negocio
existente. En este punto aun no es necesario saber cómo está construida la implementación, aquí
Capítulo 3. Análisis orientado a servicios, proceso 1.

se necesita saber cuáles sistemas pueden verse afectados y cuáles pueden catalogarse como
servicios candidatos.

Paso 3.3. Modelado de servicios candidatos.
Las operaciones de los servicios candidatos se agrupan de acuerdo a la lógica de su contexto.
Aquí se hace la organización de información obtenida en los pasos previos. Las fuentes de
información pueden ir desde modelos en documentos de negocio hasta juntas con los expertos de
negocio.
El modelado de servicios candidatos se subdivide en 12 pasos.

Ilustración 3-2 Pasos del modelado de servicios.

Capítulo 3. Análisis orientado a servicios, proceso 1.

3.1 Modelado de servicios
Paso 3.3.1: Descomponer el proceso de negocio.
Una vez identificado el proceso de negocio completo se debe segmentar en subprocesos más
específicos y granulares, capaces de especificar las tareas que verdaderamente dan sentido a la
automatización del proceso de negocio.

Paso 3.3.2: Identificar operaciones de los servicios candidatos.
En el proceso de negocio existen pasos que no pueden ser automatizados, por lo tanto no pueden
ser encapsulados en un servicio candidato.
Por ejemplo:
 Tareas manuales.
 Tareas realizadas por lógica legada existente.

Paso 3.3.3: Abstraer la lógica de orquestación.
Este paso puede omitirse en caso de no requerir una capa de orquestación.
Deben identificarse las reglas de negocio, secuencias complejas de cómo los servicios deben ser
secuenciados, controles a flujos de excepción; una vez identificados serán útiles para los flujos de
trabajo que deben seguirse para el desarrollo de la solución.

Paso 3.3.4: Crear servicios de negocio candidatos.
Se debe realizar una revisión completa de los pasos del proceso de negocio y agruparlos en
contextos lógicos. En los servicios de entidad es recomendable tomar en cuenta posibles
operaciones adicionales que ayuden a su reusabilidad.

Paso 3.3.5: Refinar y aplicar los principios de orientación a servicios.
Para lograr que los servicios candidatos estén al nivel de una arquitectura SOA se debe hacer una
revisión a la lógica interna de las operaciones, con base en los principios de diseño de servicios
vistos en la sección “1.4 Principios de diseño de servicios”. (principalmente de los cuatro básicos).
 Reutilización Etapa de modelado
 Autonomía Etapa de modelado
 Sin estado Etapa de diseño
Capítulo 3. Análisis orientado a servicios, proceso 1.

 Detectabilidad Etapa de diseño
En el proceso de análisis se debe procurar alcanzar los dos primeros principios, de acuerdo en lo
visto en la sección “1.3 Arquitectura Orientada a Servicios, SOA”.

Paso 3.3.6: Identificar composiciones de servicios candidatos.
En este paso se identifican los escenarios más comunes en el proceso de negocio. Éstos serán
ilustrados para ver más de cerca cómo se componen. Realizar las composiciones de los servicios
permite:
 Dar una buena idea de si la agrupación propuesta es conveniente
 Identificar las posibles relaciones entre los servicios de orquestación y de negocio.
 Identificar composiciones de servicios potenciales.
 Identificar si hay lógica del proceso de trabajo que se haya omitido.
Se deben tomar en cuenta las posibles excepciones que puedan existir. En este punto las capas
de servicios siguen siendo preliminares.

Paso 3.3.7: Revisar la agrupación de las operaciones de servicio de negocio.
Después de haber realizado la composición de servicios del paso anterior es conveniente volver a
revisar la agrupación de los pasos del proceso de negocio, por si es necesario hacer una
reorganización de los servicios candidatos.

Paso 3.3.8: Analizar los requerimientos de procesamiento de aplicación.
Este paso puede requerirse (por lo que se considera opcional) en procesos de negocio complejos y
entornos grandes. Se realiza un análisis a fondo de las necesidades de procesamiento interno de
los servicios candidatos para abstraer posibles dependencias tecnológicas que pudieran
trasladarse a un servicio de aplicación. Las siguientes preguntas deben formularse:
 ¿Qué lógica interna se necesita para ejecutar la operación?
 ¿La lógica de la aplicación ya existe o se requiere un nuevo desarrollo?
 ¿La lógica requerida extiende los límites de la aplicación?, es decir, ¿se requiere más que
un sistema de información para realizar esta acción?

Capítulo 3. Análisis orientado a servicios, proceso 1.

Paso 3.3.9: Identificar las operaciones de servicios de aplicación candidatos.
En este paso se deben analizar los requisitos que deben cubrir los servicios de aplicación. Para los
nombres de las operaciones se recomienda no hacer referencia a la lógica de negocio que los
utiliza, con el fin de que pueden ser utilizados por otros sistemas o servicios.

Paso 3.3.10: Crear servicios de aplicación candidatos.
Las operaciones son agrupadas para conformar los servicios candidatos, la agrupación se debe
realizar deacuerdo a la relación lógica entre operaciones, por ejemplo:
 Asociación con un sistema legado
 Asociación con uno o más componentes de la aplicación
 Agrupación lógica de acuerdo al tipo de función

La agrupación propuesta en este paso no es definitiva, dado que durante el proceso de diseño
pueden hacerse adecuaciones.

Paso 3.3.11: Revisar composiciones de servicios candidatos.
El procedimiento realizado en el paso 5 se efectúa con los servicios de aplicación candidatos.
Dando seguimiento de cómo los servicios de negocio candidatos se enlazan con los servicios de
aplicación subyacentes.

Paso 3.3.12: Revisar la agrupación de los servicios de aplicación candidatos.
Después de realizar el paso 11 puede que haya la necesidad de realizar cambios en la agrupación
de los servicios de aplicación y validar que no se haya omitido algún paso.

Paso 3.3.13: (Opcional) Mantener un inventario de servicios candidatos.
Se sugiere crear un inventario de servicios que sirva de referencia para cuando el sistema crezca,
se realicen modificaciones o se comience a interactuar con futuros proyectos. El inventario
facilitará el verificar que funciones se pueden reutilizar o que servicios pueden adecuarse.
Capítulo 4. Diseño orientado a servicios, proceso 2.

CAPÍTULO 4. DISEÑO ORIENTADO A SERVICIOS, PASO 4

En este proceso se concreta el diseño físico de los servicios candidatos, realizar el diseño
orientado a servicios tiene como objetivos:
 Determinar el conjunto básico de extensiones de la arquitectura
 Establecer límites de la arquitectura
 Identificar las normas de diseño requeridas
 Definir diseños de interfaz de servicios abstractos
 Identificar las composiciones de servicios potenciales
 Evaluar el soporte de los principios de orientación de servicios
El diseño orientado a servicios está conformado por los siguientes pasos:
 Paso 4.1: Compose SOA
 Paso 4.2: Diseño de servicios de negocio centrados en entidad, explicado en la sección
“4.2 Paso 4.2: Diseño de servicios de entidad”.
 Paso 4.3: Diseño de servicios de aplicación, explicado en la sección “4.3 Paso 4.3: Diseño
de servicios de aplicación”.
 Paso 4.4: Diseño de servicios de negocio centrados en tareas, explicado en la sección “4.4
Paso 4.4: Diseño de servicios de negocio o de tarea”.
 Paso 4.5: Diseño de servicio orientados al proceso de negocio, explicado en la sección “4.5
Paso 4.5: Diseño de servicios de proceso de negocio”.
Capítulo 4. Diseño orientado a servicios, proceso 2.

Ilustración 4-1 Proceso de diseño de servicios.

4.1 Paso 4.1: Compose SOA.
Compose se refiere a la acción de integrar distintos componentes para crear un ente más grande,
en este caso una arquitectura orientada a servicios.
Este paso consiste en tres sub pasos, que son tratados en la sección “7.1 Paso 4.1: Compose
SOA”.
 Paso 4.1.1 Elegir las capas de los servicios
 Paso 4.1.2 Posición estándares SOA principales
 Paso 4.1.3 Elegir extensiones SOA

Capítulo 4. Diseño orientado a servicios, proceso 2.

Ilustración 4-2 Compose SOA.

Entre las decisiones que deben tomarse al desarrollar una arquitectura de software se encuentran:
 Las tecnologías que se van a utilizar
 ¿Cómo se van organizar los componentes?
 ¿Qué tipos de servicios serán construidos y cómo serán organizados entre las distintas
capas?

Capítulo 4. Diseño orientado a servicios, proceso 2.

Paso 4.1.1. Seleccionar capas de servicio.
Se debe realizar una evaluación de qué capas van a integrar la solución, algunos puntos que
deben ser tomados en cuenta son: existe la necesidad de enlazarse con otros módulos o sistemas,
adaptarse a lineamientos existentes en la organización.
La capa de interface de servicios puede ser dividida en tres, como se vio en el la sección “2
Modelo de servicios.
 Capa de servicios de aplicación
o Servicios de aplicación
 Capa de servicios de negocio
o Servicios de negocio o de tarea
o Servicios de entidad
 Capa de orquestación de servicios
o Servicios de negocio

Ilustración 4-3 Capas de servicios.

Paso 4.1.2: Estándares.
Se recomienda que en el diseño de la solución se utilicen estándares, ya que promueven reglas
normalizadas que describen los requisitos que deben ser cumplidos por un producto, proceso o
Capítulo 4. Diseño orientado a servicios, proceso 2.

servicio, con el objetivo de establecer un mecanismo base para permitir que distintos elementos de
hardware o software que lo utilicen sean compatibles entre sí.
Algunos estándares que son utilizados para la interconexión entre sistemas o servicios son: RMI,
EJB remotos, servicios web por SOAP o Rest.

Paso 4.1.3: Extensiones SOA.
En este paso se debe verificar si la solución propuesta requiere de tecnologías o herramientas
específicas que brinden la suficiente robustez para que esta pueda adecuarse a los posibles
cambios, estos cambios son donde puede notarse visiblemente el poder de SOA.
Existen herramientas, algunas comerciales, tales como los motores BPEL, BUS de servicio,
estándares para servicios web, como WS-security, WS-Transacction.
En el presente trabajo no se utilizaran herramientas extra como BPEL o BUS, solo se utilizaran
algunos de los estándares para los servicios web, esto se verá más adelante.

4.2 Paso 4.2: Diseño de servicios de entidad
Es conveniente comenzar por el diseño de este tipo de servicios debido a que presentan un alto
grado de reusabilidad por servicios de capas superiores.
A continuación se presentan los pasos para realizar el diseño de estos servicios, hay que recordar
que la metodología MSOAM puede ser adecuada a las necesidades existentes, sin perder de vista
el diseño orientado a servicios.

Paso 4.2.1: Revisar servicios existentes.
El primer paso es verificar si es necesario construir el servicio. Para ello se valida si ya existe algún
servicio que implementa, total o parcialmente, la funcionalidad requerida.

Paso 4.2.2: Definir los parámetros (mensajes) de entrada y salida.
Una vez que se ha determinado la necesidad de crear el servicio se procede a definir los mensajes
de entrada y de salida.
Cabe mencionar que no necesariamente debe existir una relación uno a uno entre los servicios de
entidad y las entidades que conforman el modelo de entidad.

Capítulo 4. Diseño orientado a servicios, proceso 2.

Paso 4.2.3: Especificar una interfaz inicial del servicio.
Para definir la interfaz inicial del servicio se siguen los pasos siguientes:
 Verificar que las operaciones son genéricas y reutilizables, asegurándose que la
granularidad de la lógica encapsulada es adecuada
 Asignar nombres a las operaciones de los servicios
 Formalizar los valores de entrada y de salida para cada una de las operaciones

Paso 4.2.4: Aplicar los principios de orientación a servicios.
En este paso se verifica que los servicios de entidad estén cumpliendo con los cuatro principios
básicos.
 Reutilización
 Autonomía
 No guardar estado
 Detectables

Paso 4.2.5: Estandarizar y refinar la interfaz del servicio.
Si la organización cuenta con normas o directrices de diseño establecidas hay que alinearse a
ellas. Ejemplos incluyen: el cómo deben ser nombrados los servicios y operaciones, los tipos de
datos a utilizar, el cumplimiento de estándares específicos, etc.

Paso 4.2.6: Extender el diseño del servicio.
Con el fin de lograr una mayor reutilización de los servicios se puede hacer una especulación de
qué otras características debería cubrir el servicio, por ejemplo agregar nuevas operaciones o
parámetros a las operaciones.
Si se decide agregar operaciones nuevas deben repetirse los pasos anteriores.

Paso 4.2.7: Identificar el procesamiento requerido.
En este paso se debe verificar que lo realizado en el proceso de análisis