sio2009 eq6 l8 tem gold bernstein & ruh cap6 integracion
TRANSCRIPT
FACULTAD DE ADMINISTRACIÓN
LICENCIATURA EN SISTEMAS COMPUTACIONALES
ADMINISTRATIVOS
DR. CARLOS ARTURO TORRES GASTELÚ
SOLUCIONES INTEGRALES EN LAS ORGANIZACIONES
“INTEGRACIÓN DE ARQUITECTURA TÉCNICA"
FUENTE: GOLD-BERNSTEIN & RUH
EQUIPO # 6
AGUILAR PALACIOS LIZBETH
RIVERA OCHOA JULIETA FARINA
ROMERO VELÁZQUEZ YORELI
801-S
H. VERACRUZ, VER., 25 DE MARZO DEL 2009.
VISIÓN GENERAL DE EJECUTIVO
La integración Arquitectura Técnica de la empresa representa los códigos de construcción para todos los proyectos de integración. Es la especificación de que todos los proyectos de integración de referencia la hora de elegir la tecnología para su aplicación. La arquitectura y el diseño incluye orientación restricciones sobre cómo deben desarrollarse las aplicaciones. Por lo tanto, la especificación debe ser minuciosa para definir todos los aspectos de la arquitectura de integración, y de fácil acceso, de modo que la información puede ser fácilmente encontrada y entendida. Si bien en muchos casos las descripciones detalladas son necesarias y adecuadas, también recomendamos el uso de gráficos y tablas resumen para presentar la información. Cada una de las arquitecturas de la solución presentada en la Parte III de este libro se basa en la especificación de esta arquitectura, y es un subconjunto de esta especificación. Creación de una Arquitectura de Integración de Especificaciones guiará muchas aplicaciones de soluciones de TI para garantizar la operatividad entre palanca y la reutilización. Por ejemplo, el Estado de Florida ha creado un conjunto de directrices para la integración de la arquitectura, se describe en el Estudio de caso 6.1 (Estado de la Oficina de Tecnología del Estado de Florida de 2003). La Arquitectura Técnica de Integración debe ser impulsada por los requerimientos del negocio. Con el tiempo, una gran organización puede necesitar de un todo. Si bien las necesidades empresariales actuales deben conducir y las necesidades de infraestructura.
6.1 ESTUDIO DE CASO
ESTADO DE LA FLORIDA: LA INTEGRACIÓN DE LA EMPRESA RECTORES ARQUITECTURAS
La complejidad de cualquier gobierno estatal a menudo no es entendida por aquellos en el exterior. Sin embargo, con múltiples departamentos, grandes presupuestos, los cambios en los presupuestos, nuevas leyes, cambios en los políticos, y otras prioridades, es uno de los más complejos entornos de TI que se puede imaginar. Incluso con el advenimiento del estado Clos, todavía hay un entorno de TI altamente distribuido en los estados para arquitecturas incompatibles, dificultad en el intercambio de información, y la duplicación de esfuerzos.
El Estado de Florida ha sido un líder en la organización de las funciones del Estado y los activos de TI. Se ha reconocido la necesidad de mejorar el enfoque de la arquitectura de integración de la empresa dentro del estado. Su estrategia se basa en patrones de diseño y reutilización de componentes, junto con un enfoque práctico.
Se ha dado orientación para incorporar el enfoque en la búsqueda de aprobación de cualquier proyecto:
Demostrar la comprensión del problema de dominio en el contexto de los objetivos del Estado. Línea de base de lo que el sistema se hace y por qué es necesario.
Compruebe el sentido de los datos. Identificar la localización de datos, flujos, y los metadatos.
Hacer sentido de los procesos. Crear modelos de procesos. Identificar las interfaces de la aplicación. Identificar o crear interfaces. Identificar los eventos. Identificar eventos de negocios que activan las acciones. Identificar escenarios de transformación de datos. Mapa de los formatos de datos
entre sistemas. Mapa Mapa circulación de información entre sistemas de información. Aplicar la tecnología. Seleccione la tecnología, Test. Crear un plan de prueba. Considerar el desempeño. Especificar las características de rendimiento. Definir el valor. Definir el retorno de la inversión. Crear los procedimientos de mantenimiento. Identificar los procesos operativos y
procedimientos.
Mediante la creación de esta guía, que proporcionan una estructura para mejorar el estado de cómo están organizados los sistemas y la mejora de la capacidad de integrar y reutilizar los componentes en el futuro. Este es un paso clave hacia la consecución de una arquitectura de integración de la empresa.
Implementaciones, la arquitectura debe tomar decisiones y la adaptabilidad de las necesidades futuras en cuenta. Debe definir los siguientes:
común, reutilizables empresa los servicios de dominio que puede soportar múltiples aplicaciones
común, normalizado de los servicios técnicos que puedan apoyar cualquier estilo de integración, tales como servicio, información o proceso orientada.
los niveles de servicio que debe ser apoyado Un marco de seguridad basado en un articulado claramente en toda la empresa
política de seguridad Centrarse en la capacidad de apalancamiento existente (herencia) los sistemas de
información y sistema de productos comerciales empaquetados para ofrecer una porción significativa de la funcionalidad de la aplicación.
En algunos casos, la arquitectura técnica esfuerzo se centrará en reducir el número de despedidos tecnologías. La actual arquitectura de integración de la evaluación (capítulo 5), prevé una gran cantidad de información para impulsar la arquitectura decisiones.
6.2 Integración de la Arquitectura Técnica de Especificaciones
Como se señaló anteriormente, la técnica proporciona la arquitectura de integración de los códigos de construcción para la integración de infraestructura. Proyecto a nivel de la adhesión a esta arquitectura garantiza que haya coherencia, la reutilización, y el beneficio económico a la organización para las inversiones en tecnología de integración. Esta adhesión se puede lograr a través del diseño de evaluación, como se explica en la sección de Arquitectura de Gobierno Capítulo 4. Véase el Apéndice D de la especificación completa plantilla.
6.2.1 Introducción
Esta especificación representa la arquitectura de integración de la empresa especificación técnica. Este documento se utilizará para orientar todas las decisiones y diseños relacionados con la integración en la organización. Se define el alcance de la integración de la arquitectura, los proveedores preferidos y las tecnologías, las normas y de la empresa. Al crear la introducción, el esquema de toda la empresa todas las decisiones de los lectores el documento debe ser consciente de, y llamar la atención sobre apéndices, como se referencias y normas de gobernanza.
6.2.2 Ámbito de aplicación
Definir el alcance de la arquitectura de integración. Se debe abordar si se trata de toda la empresa o limitarse a una determinada organización o clase de aplicaciones. Otras áreas para hacer frente a determinados tipos de integración (datos, aplicación o proceso), las limitaciones y las razones de las limitaciones. El alcance también deben indicar qué tipos de aplicaciones externas están cubiertas, incluida la de si la solicitud fuera del ámbito de la empresa es un candidato para la conexión a aplicaciones empresariales. Este será el caso si la organización tiene la cadena de suministro o comercio electrónico iniciativas previstas.
6.2.3 Los participantes clave
Definir el público y los principales interesados. El público debe incluir a todos los miembros de la organización de TI, sin embargo, debe explícitamente lista los títulos o funciones específicas que se aplicarán a la integración en la ejecución normal de sus puestos de trabajo. Los principales interesados deben incluir la TI y los ejecutivos responsables de mantener el documento.
6.2.4 Requisitos de la Arquitectura de Integración
Esta sección se basa en las necesidades capturadas en el capítulo 2, así como la integración en curso de evaluación. La integración Arquitectura Requisitos sección incluye los requisitos para los tipos de servicios de integración y tecnologías que serán parte de la
infraestructura y los servicios que se define lo que debe utilizarse para los diferentes tipos de aplicaciones, las aplicaciones que necesitan ser integrados entre sí, y los tipos o estilos de la integración que se utilizarán en toda la empresa.
6.2.4.1 Tipos de Integración
La organización debe comenzar esta especificación mediante la identificación de los tipos de la integración que necesitan apoyo (véase la Figura 6-1). Los datos de la estrategia de negocio y los requisitos recogidos en el capítulo 2 y en el Capítulo 3, junto con la evaluación que se describe en el capítulo 5 guías de esta actividad. Ayuda a definir los requisitos conocidos para este tipo de integración a fin de determinar el alcance de la inversión. Por ejemplo, si hay una serie de aplicaciones que requieren proceso de integración y, a continuación, la organización debería considerar la posibilidad de una empresa una licencia para la solución de BPM.
6.2.4.2 Integración de Servicios y Tecnologías
Como se señaló anteriormente, la arquitectura de integración está compuesta por una serie
de servicios de integración, y estos servicios pueden ser implementados con diferentes.
Aplicación interna
requisitos de integración
Conectividad simple,
enrutamiento inteligente, la
traducción y la transformación,
la aplicación de interfaces /
adaptadores
aplicaciones que requieran este
nivel de integración
Legado requisitos de
integración
Mainframe, la costumbre o las
aplicaciones de la ERP.
aplicaciones que requieran este
nivel de integración
Clientes, socios,
proveedores (B2B), los
requisitos de integración
EDI, la costumbre o servicios
B2B
aplicaciones que requieran este
nivel de integración.
Compuesto de los requisitos
de integración
Aplicaciones compuestas, SOA.
novedad
aplicaciones que requieran este
nivel de integración
Portal de integración de
requisitos
Portal Integrado aplicaciones que requieran este
nivel de integración
la formación de los
requisitos de integración
Lote, en tiempo real,
volúmenes, programación,
aplicaciones que requieran este
nivel de integración
información estructurada y no
estructurada
Proceso de integración de
requisitos
BPM, BAM, y aplicaciones de
flujo de trabajo
aplicaciones que requieran este
nivel de integración
Figura 6-1 Tipos de Integración
Tecnologías. En lugar de dejar que la unidad de selección de productos de arquitectura, la
arquitectura debe basarse en un marco que engloba todos los aspectos necesarios para la
integración de esa organización. La arquitectura se construye con existentes o nuevos
productos. Además, la arquitectura está construida sobre los principios de la organización y
no de los productos seleccionados. Por ejemplo, las empresas de embarcarse en el camino
de SOA pueden definir su arquitectura como una serie de servicios. Figura 6-2 muestra los
diferentes tipos de servicios de integración, y las tecnologías que pueden utilizarse para
ejecutar el servicio. Como se señala más adelante, puede haber un número de tecnologías
utilizadas para poner en marcha un servicio, debido a las diferentes tecnologías son
adecuadas para los diferentes tipos de aplicaciones. Distintas tecnologías de aplicación el
mismo servicio no siempre significa la redundancia en caso de las tecnologías entregar el
mismo servicio a los diferentes tipos de aplicaciones.
Figura 5-3 (página 81), que fue construido durante la evaluación de la arquitectura actual y
muestra los productos existentes en la organización, se utiliza como base para determinar si
el proveedor preferido o la tecnología que está instalado actualmente.
Integración
de servicios
Tecnología de
integración
Uso recomendado Preferencia
Vendedor /
Tecnología
Actualmente
instalados?
Procesos de
integración
BP IV Modelado, ejecución y
gestión de procesos
empresariales integrados
Nombre del
proveedor, el
nombre del
producto
Si o No
BAM Seguimiento en tiempo real
de los procesos y guión ¬
juntas; puede ser parte de
la herramienta BAM
Nombre del
proveedor, el
nombre del
producto
Si o No
B2B
integración
B2B servidores Utilizados para la
integración con socios y
proveedores, construir
comunidad on-line. Se
integra con aplicaciones de
back-end a través de
adaptadores o servidores
EAI
Nombre del
proveedor, el
nombre del
producto
Si o No
EDI Utilizado para los grandes
socios, las soluciones EDI.
Usado con VAN
Nombre del
proveedor, el
nombre del
producto
Si o No
XML Utilizados para el envío de
mensajes a los socios a
través de Internet
Nombre del
proveedor, el
nombre del
producto
Si o No
Servidores web Utilizarse como una
interfaz
Nombre del
proveedor, el
nombre del
producto
Si o No
Integración
móvil
Servidores de
integración
móvil
Entrega de información a
diferentes dispositivos
móviles de información
común y las reglas de
negocio
Nombre del
proveedor, el
nombre del
producto
Si o No
Seguridad
integración
La integración
de servidores de
seguridad
Integra diferentes sistemas
de seguridad
Nombre del
proveedor, el
nombre del
producto
Si o No
Figura 6-2 (cont.)
6.2.5 Descripción de la Arquitectura de Integración
Descripción de la Arquitectura contiene dos vistas diferentes: el conceptual y el desarrollo
opinión. La vista conceptual proporciona el panorama general de la empresa de integración
de infraestructura y los tipos de servicios que serán prestados. La visión de desarrollo
contiene información de interés para los desarrolladores que utilizan la arquitectura. En la
parte III de este libro se describen las pautas específicas de integración y cómo utilizar los
servicios de integración de la Arquitectura Técnica.
6.2.5.1 Visión conceptual
La arquitectura conceptual se destina a dar el panorama de la arquitectura de integración.
No hay manera correcta o una forma de desarrollar este esquema. Se trata de un dibujo
conceptual. Es necesario transmitir todos los componentes de la infraestructura, cómo se
interrelacionan, y cómo se relacionan con los otros componentes de la empresa. De hecho,
puede haber varios puntos de vista conceptual para ilustrar una serie de desmayos en la
arquitectura.
La arquitectura conceptual debe incluir los tipos de aplicaciones o sistemas que conectarse
a través de la integración de arquitectura, ¿qué tecnologías se utilizan para la integración, la
forma en que la arquitectura técnica será utilizada por los portales y en la red corporativa y
conectividad externa, así como cómo los usuarios interactúan con los las aplicaciones
resultantes. La arquitectura conceptual debe ser un diagrama que se puede utilizar para
explicar la arquitectura a la gestión y el personal. No va a ser satisfactorio para el personal
técnico profundo, pero puede ser usado para explicar los 10 usuarios de negocios la forma
en que la infraestructura se utiliza.
La parte III del libro contiene las pautas y los diagramas de arquitectura de referencia para
diferentes soluciones de integración. Sin embargo, las grandes empresas pueden tener una
combinación de requisitos de integración. A continuación se presentan dos ejemplos de
diagramas. Figura 6-3 representa una visión simplificada de la superposición de servicios
de integración ofrecidos. Figura 6-4 (página 99) representa una visión alternativa de la
integración de todos los servicios que pueden ser parte de la Arquitectura Técnica de
Integración.
El diagrama debe ir acompañada de una descripción general de los planos de arquitectura,
las descripciones de cada uno de los componentes y las relaciones entre cada uno.
6.2.5.2 Visión de Desarrollo
La visión de desarrollo es una descripción de cómo y cuándo cada una de las diferentes
herramientas e interfaces se utiliza para guiar el equipo de desarrollo utilizando la
arquitectura de integración. Una arquitectura de integración puesto en marcha para apoyar a
los desarrolladores en el rápido desarrollo de nuevas aplicaciones que requieren gran
integración. Diferentes herramientas y enfoques podrían ser empleadas por los
desarrolladores a usar la arquitectura. Para todos y cada uno de los aspectos de la
arquitectura de integración no debe ser una descripción de cómo un desarrollador puede
utilizar los servicios de integración en una aplicación. Esto incluiría las lenguas apoyo y la
manera en que los servicios son accesibles y las capacidades, herramientas para el
desarrollo de cualquier integraciones y herramientas para configuración y administración.
También las interfaces estándar disponibles para su uso debe ser definido. (Ver la Figura 6-
5, página 100.)
6.2.6 Normas de Perfil
En esta sección se especifican todas las normas que han sido adoptadas por la organización
que son relevantes para la integración de la arquitectura. La especificación completa debe
incluir también una política de gobierno que define la forma de cumplimiento de las normas
será gestionado, y el proceso y las directrices para la aprobación de soluciones que no
cumplen con las normas. La mayoría de estas normas se refieren a las interfaces, formatos,
mecanismos o las comunicaciones. Normas arquitectónicas están empezando a parecer que
puede tener un impacto mayor en el futuro sobre una arquitectura de integración de la
empresa. Una norma fundamental que hay que vigilar es la Arquitectura Dirigida por
Modelos (MDA) de la norma objeto del Grupo de Gestión. 6.2 Estudio de caso describe las
actividades de MDA (Soley ª).
Tipos de normas que se abordarán en el pliego de condiciones se enumeran en Figura 6-6,
(página 100).
Soporte de idiomas <Lista de cómo cada uno de los idiomas es compatible. Describir la forma de acceso>
Integración de herramientas de definición <Lista de las herramientas empleadas para crear y gestionar una definición de integración
Integración de herramientas de apoyo <Lista de las Herramientas utilizadas para apoyar la gestión y configuración de integraciones>
Interfaces abiertas Cualquier lista de interfaces abiertas que se pueden utilizar independientemente de los idiomas o las herramientas de desarrollo
Figura 6-5 Ver Tabla de Desarrollo
Protocolos de comunicación
Industria o la tecnología estándar para cada tipo de comunicaciónEjemplo: RosettaNet, JMS, etc
Interfaces de la aplicación
Estándar de la industria o la tecnología para cada tipo de aplicaciónEjemplo: los servicios Web para x tipos de aplicaciones, empaquetado y adaptadores para el tipo de aplicaciones. JCA para z tipo de aplicaciones
Formatos de mensaje
Norma de la industria o la tecnología para cada uno tipo de mensajeEjemplo: XML para la mayoría de los tipos de mes ¬ sabios. Para las transacciones EDI con grandes socios. etc
Modelos de procesosEstándar de la industria y la tecnología
Ejemplo: Estandarizar en una herramienta de modelado o de una norma como la BPEL
Metadatos
Normas para diferentes tipos de metadatosEjemplo: los metadatos acerca de las interfaces, servicios Web, transformación de datos, etc
Figura 6-6 Integración Normas
6.2 ESTUDIO DE CASO
ARQUITECTURA DIRIGIDA POR MODELOS: ¿CÓMO MEJORAR LA
INTEGRACIÓN SE LOGRA
El objeto del Grupo de Gestión se ha embarcado en la creación de las normas relacionadas
con la Arquitectura Dirigida por Modelos (MDA). Esta actividad fue impulsado por un
deseo de proteger las inversiones de software mediante la integración de lo que se ha
construido con lo que van a construir. El objetivo es la especificación de una arquitectura
que puede durar los próximos veinte años. Desarrollo se logra mediante el desarrollo de
modelos de los sistemas que se construirán son comprobables y que puede ser simulado.
Una vez que el modelo es validado, el código se genera en el entorno de destino, que
integra las aplicaciones heredadas y fuera de la plataforma de productos con código
generado.
El proceso para el desarrollo de una aplicación de MDA es el siguiente:
1. Desarrollar una plataforma independiente del modelo que describe la funcionalidad y
comportamiento.
2. Mapa de la modelo a la tecnología middleware objetivo crear una plataforma y modelo
específico.
3. Generar el código de la plataforma modelo para el despliegue.
A través de este enfoque, los sistemas que están muy basados en la integración se pueden
desarrollar más rápidos y más fáciles que es típico de hoy. Además, los OMG se prevé que
a través de la MDA se desarrollarán herramientas para la ingeniería inversa, para generar
modelos de los sistemas existentes para su uso en nuevas aplicaciones. Además, será más
fácil de generar puentes entre aplicaciones tanto dentro como en toda la empresa,
compartiendo la plataforma independiente modelos entre las organizaciones que necesitan
integrar a otros sistemas.
4.2.7 Requisitos de nivel de servicio
Requerimientos de nivel de servicio incluye la disponibilidad, integridad y servicio,
escalabilidad, mantenimiento, gestión, facilidad de uso, y el rendimiento. Transacción, la
persistencia, y servicios de directorio también puede ser necesaria para apoyar el necesario
nivel de servicio. Estos requisitos pueden ser derivados de los requisitos de las aplicaciones
de la sección, o bien ser establecidos por la organización basada en las necesidades de la
empresa.
Cada sección es muy probable necesidad de romper los requisitos de solicitud, así como el
tipo o espacio de integración. Estos requisitos están destinados a ser una guía para el diseño
y la aplicación de la arquitectura de integración. Muchos de estos requisitos serán de alto
nivel y no a un nivel detallado que se producirán con la aplicación de diseño. Necesidades
específicas de las aplicaciones pueden requerir ajustes a la especificación de alto nivel. Es
importante que la organización de tratar la integración de la empresa La arquitectura como
un proceso continúo en lugar de un producto terminado.
6.2.7.1 Disponibilidad
Esta sección recoge los requisitos de disponibilidad, por ejemplo, cuando la integración se
llevará a cabo (en tiempo real o por lotes), las expectativas sobre el acceso al servicio, así
como los parámetros que la arquitectura de integración de las necesidades a satisfacer. Hay
dos tipos de parámetros que se definan con respecto a la disponibilidad: la disponibilidad
del sistema y disponibilidad de la integración. Típico sistema de mediciones de la
disponibilidad de horas de trabajo son la disponibilidad, por lo general se define como 8
horas por día, 5 días a la semana (8 X 5), o la disponibilidad de tiempo completo, definido
como 24 horas al día, 7 días a la semana (24 X 7). Disponibilidad de la integración puede
ser definida como tiempo real o de otro tipo, tales como periódicos o lote. Este parámetro
define cuando la información que se ha integrado está disponible para su uso.
6.2.7.2 La integridad y la entrega de servicios
La integridad de la información integrada se basa en la integridad de la transmisión, así
como la integridad de la información que está siendo procesado. Transmisión integridad
está garantizada por los servicios de transmisión, tales como la entrega garantizada, una vez
y sólo una vez la entrega, y la persistencia de mensaje tiendas. La integridad de los
procesos de información depende de la validez de la traducción y el proceso de
transformación, así como el tratamiento de la información por el sistema de destino. Este
parámetro puede ser medido en los índices de error, y se refiere tanto a la calidad y el costo
del sistema.
6.2.7.3 Escalabilidad
La escalabilidad es un gran factor de la capacidad de planificación y compra. La
escalabilidad de los requisitos debe ser definidos para las necesidades previstas de la
organización tanto en el corto plazo y largo plazo. Requisitos de escalabilidad puede ser
definido por los siguientes parámetros:
• Cantidad de la información se transmita a
• Tasas de transacción (tiempo / volumen)
• Número de solicitudes que deben integrarse
• Conexiones simultáneas de usuarios finales
6.2.7.4 mantenimiento y administración
Mantenimiento y la capacidad de gestión se refieren a las características operativas de la
arquitectura. Esta parte de la especificación define los servicios específicos requeridos.
También definir los requisitos para integrarse con el entorno operativo actual, por último,
identificar todas las limitaciones de mantenimiento, tales como aplicaciones Abt están
migrando a plataformas diferentes, o se están "sunsetted".
Mantenimiento y gestión de requisitos pueden ser definidos por los siguientes servicios:
• Vigilancia y alerta
• de inicio, cierre y reinicie
• Solución de problemas y el nivel de apoyo al mantenimiento del código y el uso de
herramientas
• Instalación y gestión de liberación de las actualizaciones y la capacidad de revertir la
• Sheduling
• Integración con las herramientas existentes
Después de determinar los requisitos, se recomienda que se resuman a los efectos de la
planificación empresarial. Asignación de un requisito de calificación de gestión a cada
solicitud o proyecto puede hacer esto. Esta calificación se presenta un resumen de la
opinión de todos los requisitos de gestión. La siguiente clasificación se puede utilizar:
Nivel 1. De inicio, cierre y reinicie, la solución de problemas, la programación de
instalación remota
Nivel 2. Nivel 1, más actualizaciones y rollbacks, integrada de la aplicación del
repositorio
Nivel 3. Nivel 2 y seguimiento en tiempo real y alertas, la plena integración y desarrollo
de herramientas de gestión
6.2.5 Usabilidad
Usabilidad se refiere a la facilidad con cada tipo de usuario utilizará el sistema. Definición
de todos los tipos de usuarios de la red, junto con el tipo de acceso y facilidad de uso que
necesitan, las herramientas y ayuda a determinar las necesidades de las aplicaciones. Figura
6-7 (página 104) ofrece un plantilla para determinar los requisitos de usabilidad. Este
cuadro puede ser modificado o ampliado según se requiera.
Tipo de Usuario Requisitos de usabilidadDesarrolladores <J2EE,. NET, servicios Web, legado, la integración se especializan
J2EE y / o. NET programación, interfaces de programación de servicios Web>
Analista Modelado de la interfazDiseñador Modelado y configuración de la interfazLínea de los directores de empresa Portal basado en navegador o el tablero de
instrumentos, en tiempo real de alertasOtros asuntos de usuario Basada en navegador del portal, alertas en tiempo
realGerentes operativos Interfaz con herramientas de gestión, la interfaz
de portal de la situación operacional, en tiempo real de alertas
Figura 6 -7 Usabilidad Tabla Requisito
6.2.7.6 Rendimiento
Requisitos de desempeño definir el nivel de servicio de las necesidades de infraestructura
para prestar apoyo a los usuarios de negocios, procesos y operaciones. Requisitos de
desempeño se utilizan también en la capacidad de planificación de vista (véase la Figura 6-
8).
Un número de diferentes tipos de mediciones pueden incluirse en los requisitos de
rendimiento. Tiempo de respuesta es la esperada o aceptable para el tiempo Usuarios o
aplicaciones a la espera de una respuesta del sistema. Puede ser medido; en el sub-segundos
(tiempo real), minutos, horas o días. El rendimiento es Ac cantidad de información que se
pueden enviar a través del sistema dentro de una cierta cantidad de tiempo. Puede medirse
en número de transacciones o del volumen de datos. El tiempo es la cantidad de tiempo
necesario para que todo el proceso para completar, pueda ser medido en segundos, minutos,
horas o días. Número de usuarios simultáneos determina el número de conexiones en vivo o
sesiones el sistema de apoyo. Número de aplicaciones conectadas refiere al número de
aplicaciones integradas que pueden enviar o recibir información a través del sistema.
Tiempo de respuesta En tiempo real, minutos, horas, díasRendimiento Número de transacciones, los volúmenes de datos
El tiempo de Segundos, minutos, horas, días
Número de usuarios simultáneos Subtotales por tipos de usuarios definidos en la usabilidad
Número de aplicaciones conectadas Nombre de todas las aplicaciones que se integrarán
Servicios de transacciones
Servicios de transacciones distribuidas de transacción incluyen el apoyo y el cumplimiento
de transacciones XA estándar. Esta información determina cómo se gestionará las
operaciones y la forma en la integridad transaccional se mantendrá. Esta sección también
define los requisitos para el apoyo a la industria y las normas reglamentarias, tales como
RosettaNet, HIPAA, u otras transacciones estándar de la industria.
6.2. 7.8 Persistencia de Servicios
A menudo es necesario persistir o almacenar datos para su uso en el futuro durante un
proceso de integración. La persistencia es necesaria para mejorar la fiabilidad cuando se
estaba recuperando de un dure. Ser capaz de reiniciar un sistema fracasado, sin perder en
cualquier proceso de integración es el uso más básico de una persistencia sen-hielo. Sin
embargo, hay numerosos • (sus usos para este tipo de servicio. Otros tipos de usos de los
datos persistentes incluyen la capacidad de revertir cualquier acción, realizar auditorías de
la actividad, o utilizar el 4ata recogidos para analizar la actividad en la infraestructura. En
esta sección se definen aneats los requisitos para proporcionar el almacenamiento de datos
y la integración de información de estado durante y después de cualquier uso de la
infraestructura de integración.
6.2.7.9 Servicios de directorio
Se ha convertido en una buena práctica en los modernos sistemas distribuidos para
proporcionar la capacidad de los servicios de directorio. Directorios proporcionar varias
capacidades fundamentales para la infraestructura. Que pueden proporcionar la ubicación
de transparencia al permitir a aplicaciones de "encontrar" otras aplicaciones para la
integración. Esto reduce la necesidad de codificar la información de localización en la
aplicación, y aumenta la capacidad de adaptación debido a que un cambio de ubicación no
exigiría cambios en otras aplicaciones. Además, los directorios se pueden utilizar para
almacenar información de configuración de los recursos o los usuarios que puedan ser
utilizados por cualquier aplicación o proceso de integración.
Por último, un directorio puede ser usado para almacenar la información de seguridad. Este
uso será examinado con más detalle en la sección sobre seguridad.
En esta sección, definir los requisitos para servicios de directorio. Esto incluye la capacidad
para registrar cualquier "componente" del sistema, incluidos servidores, interfaces de
servicio, esquemas, u otros tipos de información.
Figura 6-9 es un ejemplo de una sencilla configuración de un directorio que puedan existir.
Los campos obligatorios son el nombre y la ubicación. El tipo y la descripción son útiles en
un sistema que funcione. Otros campos pueden ser añadidos para componentes específicos.
6.2.7.10 Cuadro Resumen de nivel de servicio
El Cuadro Resumen de nivel de servicio (Figura 6-10) es útil para mostrar una vista global
de requerimientos de nivel de servicio.
6.2.8 Seguridad
La seguridad es un tipo de servicio a nivel de exigencia, pero es un tema tan importante y
un tema altamente especializado que es tratado por separado. La especificación debe
comenzar con un resumen de la parte superior de seguridad a nivel de las necesidades por
las categorías o tipos de aplicaciones que serán la utilización de la arquitectura. Esto puede
hacerse de manera general como se muestra en la Figura 6-11 (página 108), pero es más
eficaz si se puede definirse específicamente.
Nombre componente
Tipo de componente de
Ubicación Descripción Otros campos
Nombre componente
Nombre componente
Ubicación Descripción <valor>
Nombre componente
Nombre componente
Ubicación Descripción <valor>
Figura 6-9 Cuadro de servicios de directorio
Tipo de aplicación o
Nombre
Nombre de la
aplicación
Nombre de la
aplicación
Disponibilidad Tiempo real o por lotes;
8x5 o 24x7
Integridad y servicio
de entrega
Garantizada, una vez y
sólo una vez; mensaje
tiendas
Escalabilidad Conexiones, lugares
transacciones, los
volúmenes de datos
Mantenimiento y
gestión
Nivel 1, Nivel 2, Nivel
3
Usabilidad Desarrolladores,
analistas, diseñadores,
directores de LOB,
otros usuarios de
negocios, gerentes
operativos
1 El rendimiento Tiempo de respuesta,
rendimiento,
simultánea usuarios.
Servicios de
transacción
Transacciones
distribuidas, compatible
con XA, HIPAA, otros
...
Persistencia Almacenamiento de
datos e integración de
información para la
recuperación,
reproducción y análisis
...
Servicios de
directorio
información acerca de
todos los componentes
de la infraestructura de
integración>
...
Figura 6-10 Cuadro Resumen de nivel de servicio
Autenticación Autorización Auditoría Confiden
cialidad
No
Reputación
Datos Internos ■
Los datos de los Asociados ■ ■ ■
Datos del cliente ■ ■ ■ ■
Aplicación interna ■ ■
Aplicación de los socios ■ ■ ■
Datos de los asociados ■ ■ ■ ■ ■
Procesos internos
Procesos de los asociados ■ - ■ ■
Procesos de los clientes ■ ■ ■ ■ ■
Figura 6 - 11 Cuadro de Seguridad
6.2.8.1 Autenticación
Servicios de autenticación de confirmar la identidad de un usuario. Una definición detallada
de los requisitos de autorización de servicio incluye lo siguiente:
• Lista de los tipos de usuarios. Tipos de usuarios que se correlacionan con los tipos de
aplicaciones o servicios de un grupo de acceso. Los ejemplos incluyen: los diseñadores,
programadores, administradores, usuarios de línea de negocio, clientes y socios.
• Nivel de autenticación para cada tipo de usuario o función. Los niveles de autenticación
pueden incluir: la contraseña, con contraseña pública / clave privada de encriptación,
certificado digital, y datos biométricos.
• Si unitario contará con el apoyo de acceso. Unitario si se define la lógica de autenticación
se puede realizar una vez por todas las aplicaciones y servicios. Esto requiere un directorio
centralizado para todos los servicios.
• Definición de cuentas de usuario cómo se gestionará. Cuentas de usuario debe ser creado
y constantemente actualizada sobre la base de los cambios que ocurren en el negocio. Es
importante tener un proceso formal definido sobre cómo esta información se mantendrá
sincronizada.
6.2.8.2 Autorización
Determinar qué niveles de autorización de operaciones de un usuario o proceso está
autorizado a realizar en un conjunto de datos o dentro de una aplicación. En esta sección se
definen las categorías de autorización, sobre la base de aplicación y / o sensibilidad de los
datos (ver Figura 6-12). Autorización se define generalmente en una matriz CRUD que
define los derechos para crear, leer, actualizar o eliminar información.
6.2.8.3 Seguridad Perimetral
En esta sección se debe abordar la manera en que la arquitectura de integración de trabajo
con la seguridad del perímetro y los tipos o categorías de integración que será necesaria
para utilizar el perímetro de seguridad. Perímetro de seguridad es la combinación de
servidores de seguridad, cifrado, autenticación de los servicios, y la arquitectura utilizada
para proteger a la empresa desde el mundo exterior. La configuración del perímetro de
seguridad se dicta el diseño de la arquitectura de integración de lo que se refiere a uso
externo.
6.2.8.4 Auditoría
En esta sección se definen las categorías de la auditoría basado en el tipo de aplicación y la
sensibilidad de los datos procesados. Categorías básicas de la auditoría son:
• Nivel 0. Mantener ninguna información
En los casos en que no hay preocupación acerca de las interacciones a causa de otros
factores relacionados con la confianza, Nivel 0 se puede utilizar, y no se realizó la
auditoría.
• Nivel 1. Mantener la información sobre el tipo de interacción y de los participantes
En los casos en que los detalles no son necesarios y sólo el conocimiento de que una
interacción se ha llevado a cabo es necesario, Nivel 1 sería aplicable. Esto sería utilizado en
los casos en que un retroceso no es posible o necesario, pero sólo el hecho de que se llevó a
cabo una interacción es necesario.
Aplicación 1 Aplicación 2 Aplicación 3 Aplicación 4
Rol de usuario #
1
<C. R. U. D> <R, U> <R. U> <R>
Rol de usuario #
2
<R> <C, R, U. D> <R. U> <R. U>
Rol de usuario #
3
<R> <R> <C, R. U, D> <R>
Rol de usuario #
4
<R> <R, U> <R. U> <C. R, U. D>
Figura 6 - 12 Solicitud de autorización de la tabla
• Nivel 2. Mantener únicamente las instrucciones para cada interacción
Nivel 2 se utiliza para examinar los tipos de interacciones que se han producido y observa
conductas raras o comprobar que se produjo una interacción. Esto puede ser utilizado para
verificar que un empleado ha efectuado una operación no autorizada en el sistema y
disponer de la información para revertir la acción.
• Nivel 3. Mantener un conjunto completo de información en cada interacción
El nivel 3 se utiliza en los casos en que las interacciones son muy sensibles y la prueba de
la interacción o la necesidad de cada auditoría es necesaria la interacción. Auditoría
completa puede ser necesario en los casos de importantes operaciones financieras, por
ejemplo.
Rendimiento y las necesidades de recursos son las ventajas de hacer una distinción entre
cada nivel. En caso contrario, si el rendimiento y los recursos son gratis, entonces el nivel
cuatro que siempre se han de aplicar. En muchos casos, esto puede no ser viable.
6.2.8.5 Confidencialidad
La confidencialidad se refiere al nivel de intimidad que requiere una transmisión.
Confidencialidad se aplica en general al nivel de cifrado que se aplica. Sin embargo,
también podría reflejarse en el camino de comunicación que se utiliza. Por ejemplo, si un
alto grado de confidencialidad es necesario, la interacción puede ser dirigida a un costo más
elevado línea dedicada en lugar de seguir un camino que utiliza una conexión a Internet. En
términos generales, cuando el uso de la codificación, mayor es el nivel de confidencialidad,
el más lento el tiempo de respuesta. Sin embargo, al examinar los canales de comunicación,
el mayor grado de confidencialidad, la más cara de las comunicaciones. Rendimiento, costo
y seguridad son a menudo compensaciones.
6.2.8.6 No reputación
No reputación es sumamente importante para las operaciones B2B. Se asegura de que una
petición o una orden no pueden ser repudiadas más tarde. No reputación servicios son
necesarios para garantizar la validez y ejecutabilidad de los contratos electrónicos. La
especificación debe definir el nivel de servicio requerido No reputación, y que los tipos y
categorías de las aplicaciones lo requieran (Figura 6-13). Tipos de No reputación incluyen:
• No reputación sesiones de comunicaciones. Los criterios de valoración en la
comunicación período de sesiones, como una sesión de SSL, el intercambio de fichas que
les identifique de forma exclusiva. Este tipo de No reputación confirma que se llevó a cabo
una sesión, pero No validar la información específica que se intercambió en la sesión, ya
que no obligar a la sesión permanente a los contenidos el iniciador o el destinatario.
• No reputación servicios de middleware. Interacciones entre los servicios de middleware
incluir un signo que valida la autenticidad del servicio. Interacciones están bien y con
marca de tiempo registrado. Este tipo de No reputación valida una interacción que se llevó
a cabo, pero no específica que se intercambió información en la interacción.
• No reputación transacciones. La operación se acompaña con una muestra que valida su
autenticidad y la operación es el tiempo-sellado y conectado. Este tipo de No reputación
valida que la operación se llevó a cabo, pero no lo fue procesado de datos específicos en la
transacción.
Tipo de No reputación Tipo de Aplicación
No reputación sesiones de comunicaciones Simple integración de las aplicaciones o el
intercambio de datos entre aplicaciones.
No reputación servicios middleware Integraciones que son las interacciones con
una infraestructura de middleware.
No reputación transacciones Procesamiento de transacciones.
No reputación aplicación de medidas
consistentes transacciones múltiples
Complejos procesos de negocio
Figura 6 – 13 Cuadro de Nonrepudiation
No reputación aplicación consta de múltiples acciones de las transacciones. El usuario final
de la intención de tomar la acción se registra, la solicitud única son las acciones e
irrefutable trazabilidad para el usuario, y las acciones están bien con marca de tiempo y de
forma segura conectado. Esto confirma que los participantes la intención de participar en la
acción, valida su identidad irrefutable, irrefutablemente se asocia el tiempo de la acción con
esta información, y proporciona no reputación que todo el proceso se completó.
6.2.9 Capacidad de Planificación de Ver
Esta sección (Figura 6-14, página 112) especifica el diseño de criterios para alcanzar los
requisitos de las aplicaciones se definen en la sección de nivel de servicio. El objetivo es
definir la forma en todos los requerimientos de nivel de servicio se sufragarán incluyendo
tecnologías, políticas y procedimientos.
Requerimientos Enfoque de diseño
Disponibilidad Back-up y planes de recuperación, redundancia
plan de conmutación por error, el desastre del
sitio, etc
Tiempo de respuesta Ancho de banda de red, acceso de alta velocidad,
acceso localizados, optimizado las interacciones
humanas, la aplicación de optimización de
rendimiento, optimización de bases de datos
Rendimiento Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
capacidad de almacenamiento.
Los tiempos de Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
alertas en tiempo real
Número de usuarios Conexión de la gestión, el almacenamiento en
caché, la localización de acceso redundante a
través de las tiendas, la optimización de las
interacciones humanas, el rendimiento de las
aplicaciones, optimización de bases de datos
Número de aplicaciones conectadas Punto a punto de integración, servidor de
integración, integración de los servidores
distribuidos
Servicios de transacción operación de seguimiento, servicios de
transacciones dentro de la aplicación, otros
Persistencia Sistemas de almacenamiento, recuperación y
capacidades de reproducción, los instrumentos
analíticos
Servicios de directorio Servidor de directorio, herramientas
administrativas
Figura 6 - 14 Capacidad de Planificación de la tabla
4.2.10 Limitaciones del diseño y de Orientación
Todas las limitaciones y directrices específicas para los arquitectos, diseñadores,
desarrolladores y definido en este momento. Este es un tema que es ilimitado. Sin embargo
las áreas a considerar en la fijación de limitaciones y la orientación son
• Conozca las limitaciones de rendimiento.
• Formateo de datos directrices.
• Limitaciones en el registro de metadatos y definiciones.
• Preferencia en el uso de diferentes tipos de interfaces.
• Casos de implementación de seguridad.
• Desviaciones permitido la integración de la arquitectura.
Esta sección será muy probablemente muy limitado al principio, pero como el uso de la
arquitectura lleva a una mejor comprensión y conocimiento de lo que funciona o no, que
crecerá más de la cal.
6.2.11 Conclusiones y comentarios
La sección final de la Arquitectura de Integración de Especificaciones resume cualquier
aspecto o las decisiones relativas a la arquitectura de integración. Estos pueden incluir sin
resolver soluciones a necesidades específicas. Esto podría ser un buen lugar para el
ejecutivo de administración de TI para proporcionar orientación sobre las expectativas de la
integración de la arquitectura, la manera en que afectan a la organización, y lo que se espera
del personal. Por último, podría incluir la discusión sobre dónde va la arquitectura en el
futuro.
6.3 Buenas Prácticas en la Integración de Arquitectura Técnica
• Hacer la arquitectura de un documento de especificación. Debe ser consultado para cada
nuevo proyecto de integración y revisar periódicamente, o cuando sea necesario.
• No hervir el océano primera vez a cabo. Ámbito de aplicación inicial de la arquitectura de
integración de definición del proyecto a la última no más de dos a tres meses.
• Asegúrese de que todas las partes interesadas han de entrada a la definición y revisión de
la especificación de arquitectura. En caso contrario, la arquitectura puede ser saboteada.
• Plan a nivel mundial, la aplicación a nivel local.
• Diseño para su reutilización.
• Medida y gestión de la reutilización.
• Implementar la calidad de las cifras para justificar las inversiones en infraestructura.
6.4 Próximos pasos
La Arquitectura Técnica de Integración proporciona el marco para la elección de
infraestructura de tecnologías de las soluciones examinadas en la Parte III del libro.
Aquellos que buscan implementar soluciones tácticas será la tentación para ir allí
inmediatamente. Sin embargo, las compañías que deseen maximizar la agilidad
empresarial, la reutilización y retorno de la inversión, se desea completar la integración de
la empresa Archi ¬ arquitectura mediante la definición de la Arquitectura de Integración de
Servicios (Capítulo 7), Arquitectura de Información de Integración (capítulo 8), el Proceso
de Integración y Arquitectura (capítulo 9).
6.2.9 Capacidad de Planificación de Ver
Esta sección (Figura 6-14, página 112) especifica el diseño de criterios para alcanzar los
requisitos de las aplicaciones se definen en la sección de nivel de servicio. El objetivo es
definir la forma en todos los requerimientos de nivel de servicio se sufragarán incluyendo
tecnologías, políticas y procedimientos.
Requerimientos Enfoque de diseño
Disponibilidad Back-up y planes de recuperación, redundancia
plan de conmutación por error, el desastre del
sitio, etc
Tiempo de respuesta Red de banda ancha, acceso de alta velocidad,
acceso localizados, optimizado las interacciones
humanas, la aplicación de optimización de
rendimiento, optimización de bases de datos
Rendimiento Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
capacidad de almacenamiento
Los tiempos de Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
alertas en tiempo real
Número de usuarios Conexión de gestión, el almacenamiento en
caché, la localización de acceso redundante a
través de las tiendas, la optimización de las
interacciones humanas, el rendimiento de las
aplicaciones, optimización de bases de datos
Número de aplicaciones conectadas Punto a punto de integración, servidor de
integración, la integración de servidores
distribuidos
Servicios de transacción operación de seguimiento, servicios de
transacciones dentro de la aplicación, otros
Persistencia Sistemas de almacenamiento, recuperación y
capacidades de reproducción, los instrumentos
analíticos
Servicios de directorio Servidor de directorio, herramientas
administrativas.