sio2009 eq6 l8 tem gold bernstein & ruh cap6 integracion
TRANSCRIPT
Equipo 6:Aguilar Palacios Lizbeth
Rivera Ochoa Julieta FarinaRomero Velázquez Yoreli
INTEGRACIÓN DE ARQUITECTURA
TÉCNICA
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 todos los proyectos de integración a 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.
Visión general de ejecutivo
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.
Visión general de ejecutivo
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.
ESTUDIO DE CASO
ESTADO DE LA FLORIDA: LA INTEGRACIÓN DE LA
EMPRESA RECTORES ARQUITECTURAS
ESTUDIO DE CASO: ESTADO DE LA FLORIDA
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.
ESTUDIO DE CASO: ESTADO DE LA FLORIDA
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 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.
ESTUDIO DE CASO: ESTADO DE LA FLORIDA
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.
ESTUDIO DE CASO: ESTADO DE LA FLORIDA
Implementaciones, la arquitectura debe tomar decisiones y la adaptabilidad de las necesidades futuras en cuenta. Debe definir los siguientes:
Los servicios reutilizables de la empresa de dominio que puede soportar
múltiples aplicaciones.
Servicios técnicos normalizados 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.
Integración de la Arquitectura Técnica de Especificaciones
Representa la arquitectura de integración de la empresa
especificación técnica.
Se define el alcance de la integración de la arquitectura, los
proveedores preferidos y las tecnologías, las normas y de la
empresa.
Á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 debe 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.
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.
Requisitos de la Arquitectura de Integración
Los requisitos para la integración de la Arquitectura
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.
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
(Figura 6-1). Los datos de la estrategia de negocio y los
requisitos recogidos, junto con la evaluación de las 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.
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 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.
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.
Integración de Servicios y Tecnologías
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.
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
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.
conceptual Ver
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.
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.
Visión del 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.
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
Normas de Perfil
Las normas que han sido adoptadas por la organización que son relevantes para la integración de la arquitectura.
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 de la siguiente manera.
Integración de las normas
Protocolos de comunicaciónIndustria o la tecnología estándar para cada tipo de comunicación
Ejemplo: RosettaNet, JMS, etc
Interfaces de la aplicación
Estándar de la industria o la tecnología para cada tipo de aplicación
Ejemplo: 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 mensaje
Ejemplo: XML para la mayoría de los tipos de mes sabios. Para las
transacciones EDI con grandes socios. etc
Modelos de procesos
Está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
metadatos
Ejemplo: los metadatos acerca de las interfaces, servicios Web,
transformación de datos, etc
6.2 Estudio de Caso
Arquitectura Dirigida por Modelos: ¿Cómo se logra Mejorar la integración)
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.
6.2 Estudio de Caso
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 puede desarrollar más rápido y más fácil 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.
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.
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. Estos requisitos están destinados a ser una guía para el diseño y la aplicación de la arquitectura de integraciónEs 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.
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.
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
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>
...
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, pero es más eficaz si se puede definirse específicamente.
Cuadro de
SeguridadAutenticación
Autorizació
nAuditoría
Confidenci
alidad
No
repudiació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■ ■ ■ ■ ■
Visión de Capacidad de Planificación
Esta sección (Figura 6-14),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
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.
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.
Mejores 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.
Á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 saboteado.
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.
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 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).
