res cap 6 arquitectura de integracion tecnica

1

Soluciones Integrales en la Organización EQ 5

Arquitectura de integración técnica

Visión general ejecutiva

La arquitectura de integración técnica representa la construcción de códigos para la integración de todos los proyectos del negocio.

Es la especificación que todos los proyectos referenciarán al escoger tecnología de integración para su particular implementación. La arquitectura incluye el diseño de guía y las restricciones de cómo deben desarrollarse las aplicaciones.

Por lo tanto, la especificación debe ser profunda para definir todos los aspectos de la arquitectura de integración, y fácilmente accesible, de modo que la información pueda encontrarse fácilmente. Mientras que en muchos casos las descripciones detalladas son necesarias y apropiadas, también se recomienda el uso de mapas, cuadros y resúmenes para presentar la información.

Crear una especificación de arquitectura de integración guiará muchas soluciones de ejecución de TI para asegurar la interoperabilidad y uso repetido de influencia.

La arquitectura técnica de integración se debe manejar por las necesidades de negocio. Con el transcurso del tiempo, una organización puede necesitar uno de cada cosa. Mientras que el negocio actual las necesidades de promontorio deberían manejar las necesidades de infraestructura y

El ejemplo práctico 6.1 de la Florida: Arquitecturas de integración de empresa de guía

La complejidad de cualquier gobierno de estado no es a menudo sobrentendida. Sin embargo, con departamentos múltiples, los presupuestos grandes, cambios en los presupuestos, nuevas leyes, cambios políticos, y las prioridades competitivas son unos de los entornos de TI más complejos que pueden ser imaginados. Aún con el advenimiento de CIO´S de estado, existe un entorno de TI altamente distribuido en los estados guiando a las arquitecturas incompatibles, dificultad al dividir información, y duplicación de esfuerzos.

El estado de la Florida ha sido un líder al organizar la función de TI del estado y bienes. Ello ha reconocido la necesidad de mejorar el acercamiento a arquitectura de integración de empresa dentro del estado. Su estrategia depende en el diseño y el uso repetido de componentes, acoplado a un acercamiento práctico.

2


Esta guía ha sido para incorporar el acercamiento en cada proyecto buscando aprobación:

Demuestre la comprensión del campo de problema en el contexto de las metas del estado. Línea base de lo que el sistema hará y porque ello es necesario.

Explique los datos. Identifique ubicación de datos, flujos, y metadatos Explique se los procesos. Cree los modelos de proceso. Identifique los enlaces de aplicación. Identifique o cree enlaces. Identifique eventos. Identifique los eventos de negocio que aprietan el

gatillo acciones. Identifique guiones de transformación de datos. Combine los formatos

de datos entre los sistemas. Combine el movimiento de información combina flujos de información

entre los sistemas. Aplique tecnología. Tecnología selecta. Prueba. Cree una prueba de lo que planea. Considere ejecución. Especifique las características de ejecución. Defina el valor. Defina ROI. Cree los procedimientos de mantenimiento. Identifique los procesos y

procedimientos operacionales.

Por crear esta guía, ellos están proporcionando una estructura para mejorar cómo los sistemas del estado son organizados y mejorando la habilidad para integrar y volver a usar los componentes en lo sucesivo. Esto es un paso clave hacia lograr una arquitectura de integración de empresa.

Especificación de arquitectura de integración técnica

Las ejecuciones, decisiones de arquitectura deberían tomar las necesidades futuras y adaptabilidad en la cuenta. Deba definir lo siguiente:

El campo de negocio común, para uso repetido atiende que pueda soportar las aplicaciones múltiples

Campo común, normalizó los servicios técnicos que pueden soportar cada estilo del integración tal como servicio, información, o proceso oriente

Atienda los niveles que se deben soportar

Un marco de seguridad comprensivo basado en una norma de actuación sobre seguridad claramente a todo lo ancho de la empresa articulada

Foco en la habilidad para especular existente (herencia) en sistemas de información y comercializar los productos de sistema empaquetados para proporcionar una porción significativa de la funcionalidad de aplicación.

3


En algunos casos, el esfuerzo de arquitectura técnica se enfocará en reducir el número de las tecnologías redundantes.

Especificación de arquitectura de integración técnica

Como manifieste sobre, la arquitectura técnica de integración proporciona los códigos de edificio para la infraestructura de integración. La adherencia de proyecto a nivel a esta arquitectura asegura que existen consistencia, reutilización, y el beneficio económico a la organización para inversiones en la tecnología de integración.

Introducción

Esta especificación representa la especificación de arquitectura de integración técnica de empresa. Este documento estará acostumbrado a guiar todas las decisiones y diseños relacionados con la integración en la organización. Define el alcance de la arquitectura de integración, los vendedores y tecnologías, y normas de empresa preferidos. Al crear la introducción, bosqueje todos los lectores de decisiones a todo lo ancho de la empresa del documento deber tener conciencia de, y llamar la atención sobre apéndices, tal como referencian los reglamentos y normas de gobernanza

Arquitectura de integración técnica

Alcance

Defina el alcance de la arquitectura de integración. Deba dirigir si es a todo lo ancho de la empresa o limite a cierta organización o clase de aplicaciones. Otras áreas para dirigir incluyen tipos de la integración (datos, aplicación, o proceso), cualesquiera limitaciones y razones para las limitaciones. El alcance debe describir también lo que tipos de aplicaciones externas están cubiertos, incluyendo si una aplicación fuera del alcance de la empresa es un candidato para unirse a las aplicaciones de empresa. Esto será el caso si la organización tiene cada aprovisionamiento encadene o las iniciativas de comercio electrónico planearon.

Seleccione a los participantes

Defina la audiencia y los depositarios de una apuesta principales. La audiencia debería incluir todos los miembros de la organización de TI; sin embargo, ello debe listar explícitamente los papeles o títulos específicos que es aplicar la integración en la ejecución normal de sus trabajos. Los depositarios de una apuesta principales deberían incluir los poderes ejecutivos de TI y esos responsables para mantener el documento.

4


Necesidades de arquitectura de integración

Esta sección depende en las necesidades de negocio, así como la evaluación actual de integración. Las necesidades de arquitectura de la sección de integración incluyen necesidades para los tipos de los servicios y tecnologías de integración que serán parte de la infraestructura y define lo que los servicios deben utilizar para los tipos diferentes de aplicaciones, las aplicaciones que necesitan ser integradas, y los tipos o estilos de la integración que estará usado a través de la empresa.

Tipos de integración

La organización necesita comenzar esta especificación por identificar los tipos de integración que necesita ser sostenida. Ayuda para definir las necesidades conocidas para este tipo de la integración para determinar el alcance de la inversión. Por ejemplo, si existe varias aplicaciones que requieren proceso integración, entonces la organización debería considerar una licencia de empresa para una solución de BPM.

Servicios y tecnologías de integración

La arquitectura de integración es comprendida de varias integraciones diferentes, y estos servicios se pueden poner en práctica con diferentes tecnologías

Antes que dejar la arquitectura de guía de selección de producto, la arquitectura debe ser basada sobre un marco que abarca todos los aspectos de integración necesaria para esa organización. La arquitectura se construye entonces usando existente o nuevos productos. Además, la arquitectura es construida en los principios de la organización y no de los productos escogidos. Por ejemplo, las compañías que se embarcan en el camino de SOA pueden definir su arquitectura como una serie de servicios.

La figura 6-2 muestra los tipos diferentes de integración, y las tecnologías que pueden estar acostumbrados a poner en práctica el servicio.

Las tecnologías diferentes ponen en práctica el mismo servicio siempre no significa la redundancia si las tecnologías dan el mismo servicio a los tipos diferentes de aplicaciones.

5


6


7


8


Descripción de arquitectura de integración

La descripción de arquitectura contiene dos vistas diferentes: la vista conceptual y la vista de desarrollo:

La vista conceptual proporciona la pintura grande de la infraestructura de integración de empresa y los tipos de servicios que se proveerá.

La vista de desarrollo contiene información pertinente a desarrolladores que utilizarán la arquitectura.

Vista conceptual

La arquitectura conceptual es propuesta dando a la pintura grande de la arquitectura de integración. No existe ninguna vía derecha o una vía para

9


desarrollar este diagrama. Es un dibujo conceptual. Necesita transportar todos los componentes de la infraestructura, cómo correlacionan, y cómo se relacionan con otros componentes de la empresa en realidad; puede existir las vistas conceptuales múltiples para ilustrar una variedad de puntos en la arquitectura.

La arquitectura conceptual debería incluir los tipos de aplicaciones o sistemas que se unirá usando la arquitectura de integración, lo que las tecnologías son usadas para integración, cómo la arquitectura técnica se usará por portales y en la red corporativa y conectividad externa así como cómo el intermedio de usuarios con las aplicaciones resultantes. La arquitectura conceptual debe ser un diagrama que puede estar acostumbrado a explicar la arquitectura a ambos directivos y personal. Ello lo puede estar dando satisfacción al personal técnicamente profundo, pero puede estar acostumbrado a explicar así los usuarios de negocio cómo la infraestructura es usada.

Vista de desarrollo

La vista de desarrollo es una descripción de cómo y cuando cada una de las herramientas y enlaces diferentes están acostumbrado a guiar el equipo de desarrollo utilizando la arquitectura de integración.

Muchas herramientas y acercamientos diferentes podrían ser empleadas por desarrolladores para usar la arquitectura. Para todos y cada aspecto de la arquitectura de integración debe existir una descripción de cómo un desarrollador puede utilizar los servicios de integración en una aplicación. Esto incluiría los lenguajes soporte y la manera en que los servicios y capacidades son accedidos, las herramientas para desarrollar todas las integraciones, y herramientas para configuración y administración. También las interfaces normalizadas disponibles por el uso se deben definir.

10


Perfil de normas

Esta sección específica toda las normas que han sido adoptadas por la organización que es pertinente a la arquitectura de integración. La especificación completa debe incluir también una política de gobierno que define cómo sumisión a normas será manejado, y el proceso y orientaciones para aprobar soluciones que no cumplen con normas. Las normas arquitecturales que están comenzando a aparecer puede que tengan un impacto más grande en lo sucesivo en una arquitectura de integración de empresa.

11


12


13


Ejemplo práctico 6.2

Modele maneje arquitectura: Mejorar cómo integración es realizada

La anca de manejo de objeto se ha embarcado sobre la creación de normas relacionada con el modelo de manejo de la arquitectura (MDA). Esta actividad ha sido manejada por un deseo para proteger la inversión de software integrando lo que ha sido construido con lo que construirá. La meta es la especificación de una arquitectura que podría estar durante los próximos veinte años. El proceso es realizado para desarrollar los modelos de los sistemas para ser fabricado que sea probable y se pueda simular. Una vez que el modelo es validado, código es generado en el entorno de objetivo que integran las aplicaciones de herencia y de los productos de estante con el código generado.

El proceso para desarrollar una aplicación MDA es:

Desarrolle un modelo de plataforma independiente que describa la funcionalidad y comportamiento.

Combine el modelo a la tecnología de soporte intermedio de objetivo y cree un modelo de la plataforma específico.

Genere código del modelo de plataforma específica para el despliegue.

Por este acercamiento, los sistemas que se basan pesadamente sobre la integración se pueden desarrollar rápidamente y más fácil hoy. Además, el OMG lo imagina las herramientas de MDA para desarrolle se para el contrario diseñando para generar modelos de los sistemas existentes para uso en nuevas aplicaciones. Además, será fácil de generar puntales de refuerzo entre las aplicaciones ambos dentro de y a través de la empresa por dividir el moderno de plataforma independiente de ferrocarriles elevados entre organizaciones que necesita integrar a otros sistemas.

Necesidades de servicio a nivel

Las necesidades de servicio a nivel incluyen disponibilidad, integridad y servicio de entrega, escalabilidad, capacidad de mantenimiento, manejabilidad, valor práctico, y ejecución. Transacción, persistencia, y los servicios directivos también pueden ser requeridos para soportar el nivel necesario del servicio.

14


Estas necesidades pueden ser derivadas de la aplicación a la sección de necesidades o se pueden imponer por la organización basada en sobre necesidades del negocio.

Cada sección puede la mayoría probablemente necesita derrumbar las necesidades para la aplicación así como tipo o trecho de la integración. Estas necesidades son propuestas para una guía para el diseño y ejecución de la arquitectura de integración. Muchas de estas necesidades estarán a un nivel alto y no a un nivel detallado que ocurrir con el diseño de aplicación. Las necesidades de aplicación específicas pueden necesitar ajustes a la especificación de alto nivel. Es importante que la organización trate la arquitectura de integración de empresa como un proceso progresivo antes que un producto terminado.

Disponibilidad

Esta sección captura las necesidades de disponibilidad, tal como cuando la integración tendrá lugar (tiempo real), expectaciones en el acceso al servicio, y cualesquiera métricas específicas que la arquitectura de integración necesita acercarse. Existen dos tipos de las métricas para ser definido con respecto a la disponibilidad: disponibilidad de sistema y disponibilidad de la integración. Las medidas de disponibilidad de sistema típicas están trabajando disponibilidad de hora, normalmente definido como 8 horas por día, 5 días por semana (8 x 5), o la disponibilidad constante, definido como 24 horas diarias, los 7 días por semana (24 x 7). Disponibilidad de la integración puede ser definida como tiempo real u otro, tal como periódico o lote. Este métrico define cuando la información que ha sido integrada es el provecho capaz para el uso.

Integridad y servicio de entrega

La integridad de transmisión es asegurada por la transmisión atienda tal como entrega avalada, una vez y único una vez entrega, y los almacenes de mensajes persistentes. La integridad de la información los procesos que son dependientes de la validez de la traducción y el proceso de transformación, y el proceso de la información por el sistema de objetivo. Este métrico pueda ser medido y evaluado por error, y se relacionan con ambas calidad y coste del sistema.

Escalabilidad

La escalabilidad es un factor grande en la capacidad planear y comprar. Las necesidades de escalabilidad deben ser definidas para las necesidades estimadas de la organización en ambos a corto plazo y el más tiempo término. Las necesidades de escalabilidad se pueden definir por los parámetros siguientes:

15


Cantidad de la información para pasarse La transacción evalúa (tiempo / volumen)

Número de aplicaciones para integrarse

Las conexiones de usuario final simultáneas

Estas necesidades determinan el tipo de arquitectura así como las tecnologías escogidos para la ejecución.

Capacidad de mantenimiento y manejabilidad

Capacidad de mantenimiento y manejabilidad se refiere a las características operacionales de la arquitectura. Esta parte de la especificación define los servicios específicos que exija.

También define todas las necesidades para integrar con el entorno operacional existente. En último lugar, identifica todas las limitaciones de Capacidad de mantenimiento relacionados, tales como aplicaciones que están emigrando a las plataformas diferentes, o esté siendo cambiado.

Capacidad de mantenimiento y necesidades de manejo se pueda morar por los servicios siguientes:

Controlando y alertando Arranque, paro del trabajo, y comience de nuevo Localizador de problemas y nivel del apoyo Capacidad de mantenimiento de código y uso de herramientas:

instalación y manejando la liberación de actualizaciones y habilidad a reducción de precios al nivel original por resolución gubernamental

Programación Integración con las herramientas existentes

Después de determinar necesidades se recomienda asignar un requerimiento de manejabilidad desertando la o cada aplicación o proyecto pueden hacer esto. Esta clasificación proporciona un resumen mire las necesidades de manejabilidad de caída. La clasificación siguiente se puede usar:

Nivel 1. Arranque, paro del trabajo y comience de nuevo, localizando, fijando la hora de remoto instalación

Nivel 2. Nivel 1 más las actualizaciones y reducciones de precios al nivel original por resolución gubernamental, integró depósito de

16


aplicación Nivel 3. Nivel 2 más supervisión en tiempo real y alarmas, la

integración completa de las herramientas de desarrollo y de manejo

Valor práctico

La responsabilidad se refiere a cómo fácilmente cada tipo del usuario usará el sistema. Definiendo todos los tipos de los usuarios de sistema, conjuntamente con el tipo de acceso y valor práctico ellos exigen, ayude a determinar herramientas y necesidades de aplicación. La figura 6-7 proporciona una plantilla para determinar las necesidades de valor práctico. Esta mesa puede ser modificada o expandida según sea necesario.

Ejecución

Las necesidades de ejecución definen el nivel de atienda la infraestructura necesita proporcionar para soportar los usuarios, procesos, y transacciones de negocio. Las necesidades de ejecución son también usadas en la vista de planificación de capacidad de varios tipos diferentes de medidas pueden incluirse en por necesidades de rendimiento. El tiempo de respuesta es el tiempo estimado o aceptable para usuarios o aplicaciones para esperar a una respuesta del sistema. (véase la figura 6-8 ).

17


El rendimiento es la cantidad de la información que se puede enviar completamente el sistema dentro de cierta cantidad del tiempo. Puede ser medido en el número de transacciones o volumen de los datos.

El tiempo de inversión es la cantidad del tiempo toma para el proceso entero para completar.

En poder ser medido en los segundos, minutos, horas, o días. Número de usuarios simultáneos determina el número de conexiones o sesiones vivas el sistema debe soportar. Número de aplicaciones unidas se refiere al número de las aplicaciones integradas que pudo enviar o recibir la información por el sistema.

Servicios de transacción

Los servicios de transacción incluyen el apoyo de transacción distribuido y la sumisión de transacción estándar de XA. Esta información determina cómo transacciones serán manejadas y cómo la integridad de transacción se mantendrá. Esta sección también define necesidades para apoyar industria y las normas reguladoras tales como RossanettaNet, HIPAA, u otras transacciones de industria estándar.

Servicios de persistencia

A menudo es necesario para persistir o almacenar datos para el uso futuro durante un proceso de integración. La persistencia es requerida por mejore la fiabilidad al recobrarme de una falta. Sea capaz de comenzar de nuevo un sistema suspendido sin perder ningún en progreso integraciones son el más básico uso de un servicio de persistencia.

Otros tipos de usos para los datos persistidos incluyen habilidad de la reducción de precios al nivel original por resolución gubernamental cualesquiera acciones, ejecutan exámenes de cuentas de la actividad, o usan los reunidos para analizar la actividad en la infraestructura. Esta sección define los requerimientos para proporcionar el almacenamiento de

18


los datos de integración e información de estado durante y después de cada uso de la infraestructura de integración.

Servicios directivos

Se convierte en una práctica mejor en los sistemas distribuidos modernos para proporcionar la habilidad para los servicios directivos.

Pueden proporcionar transparencia de ubicación por permitir aplicaciones al "hallazgo" otras aplicaciones para la integración. Esto reduce la necesidad de codificar información fuerte de una ubicación en la aplicación, y aumente la adaptabilidad porque un cambio de ubicación no podría requerir cambios en otras aplicaciones. Además, los directivos pueden estar acostumbrados a almacenar información de configuración sobre recursos o usuarios que se puede usar por cada aplicación o proceso de integración.

Finalmente, el directivo puede estar acostumbrado a almacenar información de seguridad. Este uso se examinará en el detalle más cercano en la sección en la seguridad.

En esta sección, se define las necesidades para los servicios directivos. Esto incluye la habilidad para registrar cada "componente" del sistema incluyendo servidores, enlaces, servicio, esquemas, u otros tipos de la información.

La figura 6-9 es un ejemplo de una disposición simple para un directorio que puede existir. Los campos forzosos son el nombre y ubicación. El tipo y descripción son útiles en un sistema operacional. Otros campos podrían ser añadidos para los componentes específicos.

19


Atienda la mesa sumaria de nivel

El servicio nivela la mesa sumaria (Figura 6-10) es útil para mostrar un acuerdo que provea de puerta la vista de necesidades de servicio a nivel.

20


Seguridad

La seguridad es un tipo de requerimiento de servicio a nivel, pero es tal tema importante y un tema altamente especializado que se negocia con separadamente. La especificación debería empezar por resumiendo las necesidades a nivel superior de seguridad por los categorías o tipos de aplicaciones que estará utilizando la arquitectura. Esto se puede hacer en una manera general como se muestra en la figura 6-11.

Autenticación

Los servicios de autenticación confirman la identidad de un usuario. Una especificación detallada de la autorización atiende necesidades incluya lo siguiente:

Lista de tipos de usuario. Los tipos de usuario deberían ser correlativos los tipos de aplicaciones o atienden un grupo accedería. Los ejemplos incluyen: diseñadores, programadores, gerentes, la línea de los usuarios, clientes, y socios de negocio.

Nivel de la autenticación para cada tipo de usuario o papel. Niveles del autentificación puede incluir: contraseña, contraseña con codificación de público/clave privada, certificado digital, y

21


estadísticas de datos biológicos. Si la entrada en el sistema unitaria se soportar. La lógica unitaria

define si la autenticación se puede ejecutar definitivamente aplicaciones y servicios. Esto requiere un directorio centralizado para todos los servicios.

Definición de cómo cuentas de usuario maneje los asuntos. Las cuentas de usuario deben ser constantemente creado y actualice basado en los cambios que ocurren en la empresa. Es importante tener un proceso formal definido en cómo esta información será mantenido sea sincrónico.

Autorización

Los niveles de autorización determinan las operaciones que un usuario o proceso son autorizados para ejecutarse en un conjunto de los datos o dentro de una aplicación. (Véase la figura 6-12). La autorización es normalmente morada en una matriz de CRUD que define se endereza para crear, leer, actualizar, o borrar información.

Seguridad de perímetro

La seguridad de perímetro es la combinación de cortafuegos, codificación, servicios de autenticación, y arquitectura acostumbró a proteger la empresa del mundo exterior.

La configuración de la seguridad de perímetro dictará el diseño de la arquitectura de integración como se relaciona con el uso externo.

Auditoría

22


Esta sección define categorías para revisar basada en el tipo de aplicación y la sensibilidad de los datos andando en una procesión. Categorías básicas de la auditoría son:

Nivel 0. No mantenga ninguna información

En casos donde allí no está ninguna preocupación sobre las interacciones debido a otros factores relacionada con fie de, nivel 0 puede ser usado, y ninguna auditoría podría ser ejecutada.

Nivel 1. Mantenga información en el tipo de la interacción y participantes

En casos donde los detalles no son requeridos y sólo el conocimiento que una interacción ha tomado lugar es requerido, nivel 1 podría ser aplicable. Esto podría usado en los casos donde una reducción de precios al nivel original por resolución gubernamental no es factible o necesaria, pero sólo el hecho que una interacción tuvo lugar se exige.

Nivel 2. Mantenga las instrucciones solas para cada interacción

El nivel 2 está acostumbrado a examinar los tipos de interacciones que ha ocurrido y busca comportamiento impar o verifique que una interacción ocurrió. Esto puede estar acostumbrado a verificar que un empleado tenga ejecute un desautorizado la operación en el sistema y tenga la información a reducción de precios al nivel original por resolución gubernamental la acción.

Nivel 3. Mantenga un conjunto completo de la información sobre cada interacción

El nivel 3 es usado en casos donde las interacciones son extremadamente sensitivas y prueba de la interacción o el necesite revisar enteramente cada interacción es requerido. El examen de cuentas completo puede ser requerido en caso de las transacciones financieras significativas, por ejemplo.

Las necesidades de ejecución y de recurso son las compensaciones al hacer un distinción entre cada nivel. De otra manera, si ejecución y recursos eran libremente, entonces nivel cuatro se podría aplicarse siempre. En muchos casos, esto no puede ser factible.

Confidencialidad

La confidencialidad se refiere al nivel del retiro que una transmisión exige. Contra la confidencialidad normalmente aplica al nivel de la codificación que

23


es aplicado. Sin embargo, ello también pudo ser reflejado en los camino de comunicaciones que se usa. Por ejemplo, si un alto grado de la confidencialidad es requerido, entonces la interacción pudo ser orientada en un coste más alto dedicado alinee se antes que seguir un camino que usa una conexión en Internet. Hablando en términos generales, al usar codificación, los más altos el nivel de confidencialidad, los lentos el tiempo de respuesta. Sin embargo, cuando considerando canales de comunicación, el grado más alto de la confidencialidad, más costoso seran las comunicaciones. Ejecución, coste, y seguridad son a menudo las compensaciones.

Ninguna repudiación

Ninguna repudiación es extremadamente importante para las transacciones de B2B. Asegura que una solicitud o una orden no se pueden repudiar luego. Ningunos servicios repudiaciones son requeridos para asegurar la validez y fuerza ejecutiva de contratos electrónicos. La especificación debería definir el nivel de ninguna repudiación atienda requiera, y que tipos y categorías de aplicaciones lo requieren (Figure 6-13).

Ningún tipo de repudiación incluye:

Ninguna repudiación de sesiones de comunicaciones. Los puntos finales en la sesión de comunicación, tal como una sesión de SSL, cambian símbolos que singularmente los identificaron no valide que la información específica ha sido cambiada en la sesión, como no ata permanentemente los contenidos de sesión al creador o el receptor.

24


Ninguna repudiación de servicios de soporte intermedio. Interacciones entre servicios de soporte intermedio, incluyen un símbolo que valida la autenticidad del servicio. Las interacciones son con seguridad de tiempo sellado y entrado. Este tipo de ningún repudiación valida que una interacción tuvo lugar, pero no ese específico información es sido cambiada en la interacción.

Ninguna repudiación de transacciones. La transacción es acompañada con un simbólico que valide su autenticidad y la transacción es de tiempo sellado y entre. Este tipo de ninguna repudiación valida que una transacción tuvo lugar, pero no lo que los datos específicos son sido andados en una procesión en la transacción.

Esta sección (figura 6-14 , página 112) especifica los acercamientos de diseño para lograr las necesidades de aplicación definidas en la sección a nivel de servicio. La meta es definir cómo todo de servicio a nivel necesidades serán acercadas incluyendo tecnologías, políticas, y procedimientos, limitaciones de diseño y guía.

25


Esta es un área de tema abierta que es ilimitada. Sin embargo ciertas áreas para considerar en la colocación de limitaciones y la guía son

Las limitaciones de ejecución conocidas

Orientaciones de formato para los datos

Limitaciones en las definiciones de metadatos y preferencia de registro en el uso de tipos diferentes de enlaces

Casos especiales de las ejecuciones de seguridad

Desviaciones permitieron de la arquitectura de integración

26


Conclusiones y comentarios

La sección final de la especificación de arquitectura de integración resume todos los asuntos particulares o decisiones con respecto a la arquitectura de integración. Éstas pueden incluir las soluciones no resuelto a las necesidades específicas. Esto podría ser un lugar bueno para el manejo de TI ejecutivo para proporcionar guía en las expectaciones de la arquitectura de integración, cómo impactará la organización, y lo que es estimado del personal. En último lugar, podría incluir discusión en donde la arquitectura está yendo en lo sucesivo.

Las mejores prácticas en la arquitectura de integración técnica

Haga la especificación de arquitectura un documento vivo. Debe ser la consulta para proyectar cada nueva integración y revisó periódicamente o siempre que exija.

El alcance de la arquitectura inicial de integración, la definición del proyecto para último no más que de dos a tres meses. Asegúrese todos los depositarios de una apuesta tienen entrada a la definición y repase la especificación de la arquitectura. De otra manera, la arquitectura quizá sea saboteada. Planee mundialmente, el instrumento localmente. Diseño para el uso repetido. Medida y uso repetido de manejo. Ponga en práctica las métricas de calidad para justificar las inversiones de infraestructura.

Pasos próximos

La arquitectura técnica de integración proporciona el marco para escoger las tecnologías de infraestructura para las soluciones discutidas en la parte III del libro. Ésos mirando a poner en práctica las soluciones tácticas será tentar al salto allí inmediatamente. Sin embargo, las compañías desean aumentar al máximo agilidad de negocio, vuelva a usar, y retorne en inversión, desee completar la integración de la arquitectura de la empresa por definir la arquitectura de integración de servicio (Cap 7), arquitectura de integración de información (Cap 8), y la arquitectura de integración de proceso (Cap 9).

res cap 6 arquitectura de integracion tecnica

Documents