La Arquitectura de Integración de Servicio
7.1 el Ejecutivo Hacen Una Lectura Ligera
La Arquitectura de Integración de Servicio define aplicaciones comerciales como componentes reusables, con holgura cambiados de funcionabilidad comercial, y cómo se vinculan estos componentes. Éste es el concepto de una arquitectura orientada en servicio (SOA). Mientras SOA ha sido considerada una mejor práctica por más de dos decenios (vea recuadro complementario), hasta hace poco, muy pocas compañías estaban interesadas en ellos. Ahora SOA es repentinamente un tema caliente en la tecnología de la información, y en el centro de muchas iniciativas en las que se puso la mira aumentar agilidad de negocio. En este punto, si su compañía no es por lo menos investigar a SOA, debería ser.
En una SOA, el negocio discreto funciona o los procesos son creados como componentes independientes con acoplamientos mutuos normalizados que pueden ser a los que se accedió por otras aplicaciones, servicios, o los procesos comerciales, a pesar de la plataforma o lenguaje de programación. Estos servicios pueden estar flexiblemente combinados para soportar procesos diferentes o cambiantes y comerciales y funciones. Soporta la creación de aplicaciones complejas, lo cual puede rápidamente ser ensamblado de servicios existentes y nuevos.
Existiendo misión aplicaciones críticas actualmente en la computadora central y otras plataformas pueden estar envueltas en interfaces de servicios de Web y luego podido acceder a de otras aplicaciones o navegadores de Internet. Esto le permite negocios hacer servicios empresariales de existir sistemas, y rápidamente implemente e integre funcionabilidad nueva. La Web utilizadora repara, las compañías pueden empezar a creando a una SOA por el apalancamiento existiendo inversiones e incrementally sumando funcionabilidad nueva. SOA es la arquitectura que mejor permitirá agilidad comercial de largo plazo porque soporte aprovechamiento, e implementación rápida de soluciones nuevas.
La Historia de Servicio Orientó A Architectures
El concepto de SOA comenzó en los inicios de 1980s y fue estrechado por el sistema de redes y comunidades orientadas a objetos que programa. En 1983 el Modelo de Referencia Open Systems Interconnect (la Organización Internacional de Normalización) fue adoptado por el International Standards Organization como una referencia común para el desarrollo de estándares de comunicación de datos (la interconexión de sistemas abiertos). Define las funciones de comunicaciones de datos en siete estratos. Cada estrato define un servicio de comunicación, y cada servicio tiene una interfaz claramente definida con el estrato arriba y debajo de ella. Esta SOA ha pasado la prueba de tiempo. Mientras la tecnología y las capacidades en cada estrato han cambiado dramáticamente, la arquitectura misma perdura. Con tal de que las interfaces entre los servicios permanezcan igual, los servicios mismos pueden variarse fácilmente.
La Fundación Abierta de Software, el (la expansión del crédito interior) grupo responsable para el estándar UNIX, desarrolló el Ambiente de Computación Distribuida basado en una arquitectura orientada en servicio (la Fundación de Software Abierto). La expansión del crédito interior provee servicios de infraestructura para la computación distribuida, incluyendo autenticación y servicios prendarios (Kerberos), los servicios del directorio, las llamadas de procedimiento remoto, y el archivo y los servicios de la gerencia.
CORBA es una arquitectura independiente en vendedor y una infraestructura definida por el Grupo de Gestión del Objeto (OMG) que le permite aplicaciones de computadora trabajar hombro a hombro sobre redes usando el protocolo estándar IIOP. CORBA permite interoperabilidad a través de plataformas. Las aplicaciones CORBA son basadas en componentes.
Las tecnologías más componentes actuales son J2EE y .NET. J2EE es una plataforma basada en componentes que maneja la infraestructura distribuida y soporta servicios de Web para permitir aplicaciones de negocio del interoperable. Es actualmente el modelo más ampliamente componente destacado.
La RED es la implementación de Corporación Microsoft de una arquitectura de servicios de Web, lo cual le permite a las legiones de programadores Corporación Microsoft crear servicios de Web en los lenguajes de programación con los que ellas son más familiares. Estas conservas una inversión muy grande en sets existentes de habilidad. Los programadores J2EE son usualmente más caros que programadores Corporación Microsoft.
7.2 Beneficios de SOA
• permita agilidad comercial. SOA es lo mejor muy para permitir agilidad comercial. Maximiza apalancamiento de recursos existentes al minimizar el tiempo y el costo de destacar hojas de solicitud nuevas. En vez de desarrollar aplicaciones de la nada, compañías pueden utilizar funcionabilidad saliente y pueden crear soluciones nuevas por aplicaciones del componente que ensambla de funcionabilidad existente y nueva. Esto permite implementación rápida de soluciones nuevas.
• provea regreso superior en investment.Companies que definen servicios empresariales reusables y crea o la funcionabilidad de negocio de la envoltura como los servicios estándar maximizará sus inversiones de tecnología de la información, a través del aprovechamiento y el apalancamiento existiendo activos.
• permita agilidad de tecnología de la información. Las definiciones estándar de servicio pueden proveer un estrato de abstracción para los servicios empresariales. Un servicio puede correr dondequiera y puede ser al que se accedió de dondequiera. Por consiguiente, una compañía fácilmente puede cambiar posición o tecnología del código subyacente.
• recorte entrenar costos. Los servicios empresariales pueden ser narrados de forma resumida y abstraídos en una forma que los facilita a utilizar y ensamblar en aplicaciones componentes con programación mínima. Las compañías pueden utilizar a más programadores expertos para crear las definiciones de funcionabilidad subyacente y de servicio, lo cual luego puede ser reusado por ahí menos programadores técnicos y herramientas aplicativas visuales de asamblea.
• reduzca el costo de experimentar y el insecto concentrándose. Cada servicio es como una caja negra que realiza una función específica y tiene una interfaz publicada que acepta que los aportes definidos y los productos definieron salidas. Cada servicio puede ser probado individualmente, luego podido reusar repetidas veces. El probar interfaces es medianamente franco, y puede estar automatizado usando probando herramientas.
• los tipos del cliente de múltiplo del soporte y las plataformas. La SOA le ofrece un estrato de abstracción de las plataformas subyacentes. Esto lo hace posible para los tipos múltiples de dispositivos de usuarios finales, incluyendo navegadores y dispositivos móviles como localizadores, los teléfonos celulares, PDAs, y otros dispositivos especializados para utilizar la misma funcionabilidad comercial y comunicar información para los dispositivos diferentes. Esta independencia de la plataforma provee grandes ahorros para empresas de envergadura que tienen una miríada de tecnologías en uso.
• el tiempo de desarrollo de velocidad a través del desarrollo paralelo. Los programadores diferentes independientemente pueden dedicarse a los servicios diferentes porque cada servicio es autónomo y no depende del estado de otro servicio. Con tal de que las interfaces de servicio son bien definidas al principio del proyecto, y los programadores saben qué esperar de otros servicios, fácilmente pueden definir y pueden crear servicios independientemente. Solía ser que se dice tan programadores pasados unos ciertos más que continúan diciendo punto para un proyecto el tiempo de desarrollo de incrementos. Esto es ya no cierto con SOAs.
• aumente dimensionalidad y disponibilidad. Porque SOA le ofrece diapositiva de la posición, allí está el potencial para aumentar dimensionalidad por las instancias de múltiplo de adición de un servicio. Tecnología que contrarresta carga dinámicamente encontraría y encaminaría la petición a la instancia apropiada de servicio. Asimismo, si hay instancias múltiples de un servicio en la red, y uno se hace disponible, el software transparentemente puede encaminar la petición a otra instancia, por consiguiente con tal que la mejor disponibilidad. Esto son más el caso pues los servicios nuevos se fundamentaron en servicios aplicativos, y no funcionabilidad del legado que han estado envueltos en el servicio de Web interactúa.
Lo que hace SOA tan autoritaria es que puede estar hecha en ambos una escama grande y pequeña con los mismos beneficios. La A de Tejas y M University pudieron demostrar que estos principios en el desarrollo de su sistema de inscripción de clase en línea describieron en el Estudio de Casos 7.1 (el Software AG n.d.). Esta aplicación fue un paso pequeño en la aplicación de SOA con un impacto grande. Finalmente, SOAs se convertirán en la forma que la mayoría de organizaciones construyen sus infraestructuras de tecnología de la información, porque es la forma mejor y sólo probada proveer a agility.However de largo plazo, tomará bastante tiempo e inversión a lograr llegar. Hasta la fecha, la mayor parte del foco de la industria ha estado encendido solucionando los problemas técnicos considerables de conectividad. Sin embargo, los obstáculos de más grande para verdaderamente permitir agilidad comercial a través de SOA están adentro definiendo, construyendo, y manejando servicios empresariales reusables.
El Estudio De Casos 7.1
Los Servicios Estudiantiles Perfeccionadores en A de Tejas y M
La A de Tejas y M University han sido una lídera verdadera en la aplicación de tecnología para soportar la misión de la universidad. Como uno de las instituciones educativas más grandes del mundo, mejorar servicios para los estudiantes – especialmente durante inscripción – permanece una prioridad alta.
Una arquitectura orientada en servicio usando Web servicios está bien satisfacida proveer mejoró inscripción y servicios auxiliares para los estudiantes que esperan más servicios electrónicos y menos tiempo estando en líneas. Así es que una decisión estaba hecha para implementar un servicio en línea. El DEPARTAMENTO DE INFORMÁTICA desarrolló su sistema de inscripción de clase usando servicios de Web y dos empleados y pudo dar un sistema en tres meses. La mayor parte del servicio fue provisto por el Cobol existente y corrida Natural de programas en la computadora central. Fueron vinculados en los servicios de Web usando a EntireX Communicator. Fue estimado tan utilizador que este acercamiento y esta tecnología allí fueron un ahorro de sobre 50 % en el desarrollo que el tiempo comparó con anteriores esfuerzos similares en el departamento.
Durante inscripción, miles de estudiantes fueron servidos simultáneamente y eficazmente. El impacto para la universidad fue un grado superior de satisfacción por estudiantes y una reducción significativa en llamadas telefónicas para el personal universitario.
¿7.3 Servicios Defining – de Abajo hacia Arriba o de Arriba a Abajo?
Hasta la fecha, la mayor parte del foco en SOA y los servicios de Web ha estado en las letras menudas técnicas de definir interfaces. Mientras la definición estándar de la interfaz es la posibilitadora crítica del sistema, el enfoque ascendente tiene sus limitaciones. Si el foco está sólo en la especificación de la interfaz, y no en relación a la forma de definir qué funcionabilidad para exponer como un servicio, las compañías no cosecharán los beneficios completos de una SOA. La agilidad comercial aumentada y los costos disminuidos son dependientes en servicios bien definidos, bien manejados, reusables a los que están acelerados y fáciles conectarse. Desafortunadamente, no hay teoría matemática o la metodología que le puede decir a un desarrollador ya sea el componente o puede reparar está en el nivel correcto de granularity para maximizar aprovechamiento. El método más comúnmente usado de crear servicios empresariales es el acercamiento por tanteo. Esto usualmente significa definir servicios en el contexto de un proceso comercial particular, luego revisando para el aprovechamiento en la siguiente solución.
Un acercamiento comercial de arriba a abajo para definir servicios le permitirán compañías mejor encontrar las necesidades actuales y futuras del negocio. Comienza con los requisitos comerciales. Cada servicio debería proveer la funcionabilidad para encontrar uno o más requisitos comerciales, y el set de funciones debería relacionarse estrechamente. Ésta es cohesión funcional designada. Sin embargo, los servicios deberían ser acoplados ligeramente. El procesamiento dentro de un servicio no debería ser dependiente en el estado de procesamiento en otro. Un servicio abstrae la funcionabilidad de la tecnología subyacente.
En verdad, para lograr terminar el trabajo, ambos métodos de abajo hacia arriba y de arriba a abajo son menester. La estrategia descendente produce un nivel de abstracción que hay que crear agilidad comercial. Sin embargo, en algún punto las necesidades de modelo para encontrar la tecnología, y los servicios necesitan ser implementados como componentes o colecciones de componentes. Las compañías continuarán construyendo componentes de lo de abajo hacia arriba para narrar de forma resumida servicios empresariales. La llave debe hacer estos componentes funcionalmente cohesivo para evitar traslapar funcionabilidad y acoplado ligeramente para permitir cambio rápido y minimizar el impacto de cambio.
7.4 el Diseño Conducido En Acontecimiento de Servicio
En este capítulo le ofrecemos un método conducido en acontecimiento de arriba a abajo para definir servicios empresariales discretos que se usó en un proyecto o base de la empresa. Definir requisitos comerciales en términos de acontecimientos comerciales le ofrece un número de ventajas. Las primeras, conducidas en acontecimiento arquitecturas orientadas en servicio proveen los sistemas más dinámicos. En el ebizQ webinar, " Creando al New Enterprise Agility: El orientado en servicio y "Roy Schulte" conducido en acontecimiento "(http://www.ebizq.net/expoq/events/event39.html),, VP Gartner, indicado," agilidad generalmente involucran prácticas comerciales conducidas en acontecimiento, facilitadas por las arquitecturas orientadas en servicio ". Él usó la analogía de trenes y camiones para describir la agilidad de SOA. " Cambiar la dirección de un camión es más fácil hacer un tren ir donde las huellas no hacen. Si usted quiere que el tren se moviera sobre un pie, usted tiene que hacer una cantidad de trabajo inmensa despedazando y volviendo a poner huellas, " Schulte dijo. "Por otra parte, todo lo que usted necesita hacer para revolver el camión más ágil es movimiento el" timón. SOA es la arquitectura que provee los talones para la empresa ágil.
Los segundos, acontecimientos comerciales son una buena manera para diseñar servicios porque son fáciles que para usuarios comerciales entiendan, identifiquen, y se aseguren en un diseño. Representan las actividades esenciales del negocio. Una de las mejores formas para asegurar máximo aprovechamiento de un servicio es tener un diseño de la interfaz revisión, tan todos los tenedores de apuestas pueden evaluar si el servicio encontrará sus necesidades. Éste es el proceso usado por OASIS para desarrollar estándares. Cuando las compañías adoptan esta práctica, los servicios tienen mejor probabilidad de encontrar un rango más ancho de necesidades. Los tenedores de apuestas comerciales pueden mejor definir y verificar acontecimientos comerciales y respuestas requeridas de sistema, que interfaces técnicas. Las respuestas de acontecimiento definen los requisitos para el diseño de la interfaz.
Finalmente, definiendo los acontecimientos comerciales que el sistema captará y responda para claramente definen los linderos del sistema. Esto es esencial para asegurar implementaciones exitosas y rápidas. Las respuestas de acontecimiento están más allá descompuesto en sets de respuestas de sistema funcionalmente cohesivas. Estas respuestas pueden ser suministradas por sistemas salientes o desarrollo nuevo. Al servicio le puede ser una interfaz integrada para un set de respuestas suministrado por sistemas diferentes que necesitan estar coordinados. Un servicio mismo puede proveer niveles de abstracción diferentes. El servicio también puede ser una función sola provista por un componente o aplicación. Enfocando la atención en acontecimientos comerciales y respuestas requeridas le provee un acercamiento de oriente comercial a definir a la SOA. Este método está descrito en la Especificación de Integración de Servicio.
7.5 Reparan Especificación de Arquitectura de Integración
Algunos ha llamado el proceso de crear servicios empresariales reusables parecido a cocinar panqueques cuadriculados. Usted necesita tirar a lo primer fuera, y se mejora con el paso del tiempo. Mientras es ciertamente un proceso iterativo, esta especificación proveerá líneas directivas para crear servicios reusables. Una transcripción completa de las especificaciones está en E Appendix.
El Estudio De Casos 7.2
Las Aerolíneas del Delta – Manejando Acontecimientos Comerciales
A través del Sistema Nervioso del Delta El Sistema Nervioso del Delta (el DNS) representa una inversión de billón del $1 "para darle los datos oportunos a los clientes, los empleados, y los socios". Sin embargo, no es la entrega de la información, pero el uso de esa información en manejar acontecimientos comerciales que es el beneficio principal del DNS. Por ejemplo, una aplicación inicial del sistema es apuntada contra cargadoras de equipajes y asegurar que tienen un cuadro preciso de portilla los cambia y el vuelo se demora así es que mejor pueden planificar el movimiento de equipaje adelante y completamente aviones. El cambio en el estatus de un vuelo es un acontecimiento comercial que tiene repercusiones a través del sistema de la aerolínea. Cada vez que un acontecimiento ocurre, el cambio en el estatus puede ser sobre el que se actuó proveyendo a los participantes cruciales de ese acontecimiento de la información y los servicios reaccionar a estos cambios.
El DNS convierte Delta en una empresa de tiempo real con la habilidad mejor servirle a sus clientes. Sin embargo, también tiene la generación enorme de renta y las implicaciones que ahorra costos. Por ejemplo, tener información de tiempo real le permite a Delta aumentar el número de vuelos al día llevando hacia dentro aviones y fuera ayunador. El tiempo extra de tripulaciones de tierra desocupadas puede acortarse a través de mejor planificación. Los costos asociados con el mal uso de bolsas pueden ser eliminados.
Mientras el foco está encendido haciendo disponible información, el valor estará de moda identificar acontecimientos significativos y luego tomar asigne acción como resultado de los acontecimientos. No es menester que un negocio cree a una fuente informativa nueva. Más bien, es importante para crear una arquitectura que puede actuar sobre flujo y acontecimientos comerciales esos a través del sistema eficazmente como un servicio. El delta ha puesto tal sistema en el lugar con su DNS
La Mesa de Categoría de Servicio lista todas las respuestas requeridas para los acontecimientos comerciales, y define si la función ya existe en uno o más sistemas, o si es funcionabilidad nueva. La mesa también define servicios probables para proveer la funcionabilidad. El servicio en este punto es una primera mejor suposición en una definición de servicios y será afinado más allá en el siguiente paso. Al definir servicios, piense acerca de módulos dentro de una aplicación existente que puede realizar el servicio o componente probable
Los módulos para el desarrollo (la Figura 7-2, página 128).
La Mesa de Definición de Servicio
La Mesa de Definición de Servicio completamente describe cada servicio en un nivel suficiente para servicios de Web que crea u otra integración interactúa. Cada servicio debería estar descrito en términos de sus funciones y los sistemas usaron crear el servicio. En crear esta mesa, el grupo todo funciona y respuestas conjuntamente eso formará un módulo cohesivo. Por ejemplo, el servicio debería manejar un set particular de datos, algo semejante como la información del cliente, o la información del producto, o debería realizar un servicio específico que podría ser usado en otras aplicaciones, como el crédito inspeccionando o valorando. Allí debería ser suelto acoplándose entre los servicios. Cada servicio le debería interactuar cualquier otro servicio a través de la interfaz definida. Los cambios en un servicio no deberían afectar funcionar de otros servicios.
La descripción define cómo será el servicio implementado, algo semejante como el servicio de Web, el adaptador aplicativo, o la interfaz aplicativa (la Figura 7-3, página 129) de módulo. Éste es el lugar en la especificación que derriba el diseño de arriba a abajo al nivel de especificación de tecnología.
La Mesa de la Interfaz de Servicio
Mientras la Web que el estándar de utilidades define cómo especificar una interfaz, no define los datos y funcionabilidad que las necesidades de la interfaz a contener. La Especificación de la Interfaz de Servicio provee la información necesaria para servicios de Web que crea u otra aplicación o el componente interactúa. Usando la Mesa de Definición de Servicio, liste todos los aportes, todas salidas, y todos métodos que las necesidades de la interfaz para soportar, y determinar cómo será la interfaz implementado (la Figura 7-4).
El portal basó interfaz con servicio de acceso de datos que controlaLa conectividad para fuentes de datos de atrás. Ya sea construirá WebRepare o instale solución de conectividad de datos del vendedor
La Mesa de la Interfaz de Servicio
La meta de acoplamientos mutuos normalizados decisivos es maximizar agilidad comercial. La interfaz estándar permite aplicaciones y los servicios construyeron en plataformas diferentes con tecnología e idiomas diferentes para intermanejar. Le permite servicios cambiar funcionabilidad interna y decreta o estando bajo de tecnología sin aplicaciones de otro que impacta o componentes, con tal de que la interfaz permanece igual. Por consiguiente, entender bien la interfaz es esencial para maximizar aprovechamiento y agilidad. Es altamente recomendado que las compañías sigan mejores prácticas de los comités de estándares cuándo definiendo interfaces por revisiones del diseño que tiene que incluyen a todos los tenedores de apuestas. Es también recomendado que usted cree un glosario de terminología que es significativa y coherente a través de todos los tenedores de apuestas. El propósito de la Especificación de la Interfaz es permitir tales revisiones del diseño, y completamente describir la interfaz así es que puede ser implementada correctamente y óptimamente.
Los componentes de un Diagrama de Caso de Uso
El Diagrama de Caso de Uso y la Especificación
Un diagrama de caso de uso puede usarse para bosquejar las relaciones entre usuarios, acontecimientos, y servicios. Es la pieza final del acertijo para la especificación. Integra toda la información de las secciones previas.
Los casos de uso definen actores y cómo le interactúan los services.Actors de sistema representan un papel, y pueden ser humanos, otras computadoras, pedazos de hardware, o aun otros soportes lógicos. Deben suministrar estímulos para iniciar el acontecimiento que a su vez requiere a un respuesta de sistema (o el servicio) .Use los casos describe el comportamiento del sistema cuándo uno de estos actores envía un estímulo particular. Bosqueja los acontecimientos comerciales y las respuestas de sistema en términos del estímulo de acontecimiento que provoca el caso de uso, los aportes de y las salidas para otros actores, y los comportamientos que convierten los aportes a las salidas.
Los componentes antiácidos de diagramas de caso de uso son el actor, el caso de uso, y el actor societario .An (vea a Figure 7-5) es bosquejado usando una figura de la vara, y el papel del usuario está escrito bajo los icon.Actors pueden ser humanos, otras computadoras, pedazos de hardware, o aun otros soportes lógicos. Un caso de uso es bosquejado con una elipse, y el nombre del caso de uso está escrito inside.Associations son líneas entre actores y los casos de uso, y señalan que un actor participa del caso de uso.
Para soportar el análisis de requisitos poco funcionales (e.g., La fiabilidad, maintainability, y actuación), los casos de uso deberían crearse soportar panoramas en las cuales estos requisitos poco funcionales serán probados. Los ejemplos incluyen: 1) crear un caso de uso que prueba actuación a través de una interfaz componente distribuida, y 2) creando un caso de uso que prueba lo adaptable de un componente por ahí extendiéndolo (i.e., Sumando clases) y examinándolo para determinar si los principios arquitectónicos del diseño aquiete agarre. Estos casos nivelados en sistema de uso pueden ser implementados en una moda autónoma por medio de lo que una parte o la rebanada de la arquitectura está siendo probado independientemente de la funcionabilidad comercial de dominio que necesitará soportar.
Para crear el caso de uso, primero identifican los actores primarios en el sistema. Luego priorice los servicios para ser implemented.We recomiende crear un caso de uso para cada servicio propuesto. Por poner un ejemplo, vea a Figure 7-6 (página 132).
El cliente Haga un pedido Ostente perfil de cliente
Ordene estándar ítem de lista del producto Los usos
El Diagrama de Caso de Uso
La Especificación de Caso de Uso contiene texto que más allá describe el caso de uso (la Figura 7-7). La especificación del texto también usualmente describe todo lo que puede ir incorrectamente durante el curso del comportamiento especificado, y qué acción remediadora el sistema tomará. Esta especificación puede estar hecha a la medida o expandida para manejar asuntos particulares dentro de una implementación o la organización.
Las Conclusiones del 7.5.7 y el Comentario
Esta sección debería proveer cualquier comentarios finales en el sistema, el diseño, o el uso del sistema. Debería incluir cualquier asuntos sabidos, cualesquiera restricciones, o a atenuar factores tan contribuidos para las decisiones, o podría afectar el sistema en el futuro.
7.6 Mejores Prácticas en la Arquitectura de Integración de Servicio
Una arquitectura orientada en servicio exitosa le permite a las compañías rápidamente implementar soluciones comerciales nuevas o cambie a existentes y pueda entregar un ROI. físico Sin Embargo, SOA no es necesariamente fácil para lograr. Las siguientes mejores prácticas le ayudarán a cosechar los beneficios completos de SOA.
• provea soporte y estructura organizativa de alto nivel. El éxito con SOA requiere compromiso de la inversión y empresa en curso. SOA no puede estar consumada con un proyecto solo. Allí necesita ser un grupo de expertos, algo semejante como el centro de aptitud, eso enfoca la atención en la definición, el crecimiento, y el aprovechamiento de la SOA. Allí necesita ser procesos organizativos e integración de la empresa que gobierna políticas. Como la integración cruza linderos organizativos, también puede causar disputas territoriales. Las compañías necesitan procesos y políticas para manejar estas disputas (descrito en más detalle en seccione 4.4, Gobierno de Estructura Organizativa y de Arquitectura).
• implemente arquitectura basada en normas. Los estándares ayudan a asegurar la interoperabilidad y portabilidad. Impiden cierre de tecnología adentro, y ayudan a conservar valor en las inversiones de tecnología de la información. Los estándares de servicio de Web permiten la adopción extendida de SOA, a pesar de que ha sido una práctica arquitectónica mejor sabida para tres decenios. XML permitiendo sus sistemas es una forma para proveer un transporte basado en normas, gerencia, y formato de almacenamiento para todos los datos estructurados y el contenido no estructurado dentro de la organización.
• implemente un acercamiento basado en normas. Siga los pasos de los comités de estándares que tienen larga experiencia con crear procesos que tienen éxito en estándares del interoperable que crea. Realice revisiones del diseño para interfaces de servicio, e incluya a todos los tenedores de apuestas. Los tenedores de apuestas pueden ser identificados a través de los casos de uso.
• piense a lo grande, empiece en trozos pequeños. Al prever una implementación SOA, considere el impacto ancho en la empresa para maximizar aprovechamiento y agilidad. Pero comience con un proyecto que tiene un alcance limitado y una probabilidad alta de éxito. De un éxito nacen otros. Usted aprenderá bastante de cada implementación, así es que espere hasta que usted tenga un par de implementaciones más pequeñas bajo su cinturón antes de abordar los retos más difíciles.
• invierta dinero en entrenamiento. Usted tendrá una probabilidad superior de éxito si sus empleados saben lo que están desempeñándose. Pocos diseñadores y programadores tienen experiencia con SOAs construidos en estándares como los servicios de Web y XML. Es demasiado nuevo. Todos los tenedores de apuestas, los gerentes de negocio inclusivo y de tecnología de la información, los arquitectos, los diseñadores, los programadores, y el personal operacional del soporte necesitan entender los conceptos globales de SOA y lo que su papel en el proceso es. Los arquitectos y los diseñadores necesitan entender los parámetros del diseño y las mejores prácticas para crear sistemas dinámicos y reusables. Los programadores necesitan entender la tecnología nueva, y cómo implementar servicios y componentes de infraestructura. La necesidad operacional del personal del soporte para entender las implicaciones de manejar a una SOA distribuida.
• use herramientas para ahorrar tiempo y dinero. No pruebe para handcraft todo. Una variedad ancha de herramientas está disponible que puede hacer más pequeño el tiempo y los sets de habilidad requirieron implementar la solución. Invierta dinero en herramientas cuando las ventajas claramente pesan más que el costo.
El Grupo Delantero es un estudio de casos interesante donde cada uno de estas mejores prácticas entraron en juego (el Estudio de Casos 7.3) (el Dragón 2003).
El Estudio De Casos 7.3
"La solución brillantemente Simple" del Grupo Delantero
Había estado descrito como una "solución brillantemente simple" cuando el Grupo Delantero tomó una decisión a finales de los 1990s para poner en línea su portal de Web de clientes con su sistema de servicio al cliente. Retrospectivamente, sorprende que más organizaciones no se hayan tratado de la misma conclusión, porque los beneficios parecen tan aparentes:
• la paridad entre la interfaz del cliente canaliza en la funcionabilidad
• la reducción de complejidad en mantener sistemas múltiples
• una arquitectura que puede ser con apoyo externo y reusada para otros propósitos
Los resultados reales han sido impresionantes. El entrenamiento de empleados internos se acortó significativamente, virtualmente eliminando cuatro para seis semanas de entrenamiento. Retirar un gran número de bases de datos y las aplicaciones redujeron la complejidad de la arquitectura subyacente. Personal de casi 10 % de menos estaba obligado a mantener los sistemas. El usuario que los tiempos de respuesta fueron reducidos por 60 % para 70 %, aumentar la eficiencia del personal. Además, la arquitectura soportó que el desarrollo de aplicaciones tan mejorados de varios claves de comercial va en procesión, resultando adentro procesamiento directamente directo de transacciones. Los ahorros de estos cambios - se esperó - dan como resultado ahorros anuales de millón del $30. La inversión para lograr esto fue significativa, pero lo esperado rendimiento de la inversión es una tasa de rendimiento interno de sobre 20 %.
Mientras las inversiones en la arquitectura son a menudo consideradas como costos que no tienen beneficio aparente, la Vanguardia demuestra que la implementación de una arquitectura que soporta reusabilidad puede tener impacto significativo en un negocio. Una arquitectura orientada en servicio bien diseñada es la llave para lograr estos beneficios. Los servicios de Web no son requeridos, como vemos con qué logró Vanguard, pero debería ayuda más bajo los costos que se aguantó en este proyecto reduciendo la cantidad de trabajo aduanero de infraestructura que es ahora previsto a través de la Web repara tecnología.
7.7 Siguientes Pasos
Los servicios son los bloques constructivos para aplicaciones complejas e integración conducida en proceso. La empresa reusable decisiva repara, así como también ingeniarse y medir aprovechamiento, requiere compromiso de la inversión y empresa en curso. El éxito con SOA es mucho una materia de gerencia como sea tecnología. Las compañías interesadas en agilidad comercial de largo plazo invertirá dinero en todos los aspectos de la arquitectura de integración de la empresa, incluyendo información y arquitecturas de integración de proceso (Capítulo 8 y Capítulo 9, respectivamente). Las compañías enfocaron la atención en agilizar necesidades tácticas, definirán sólo lo que es absolutamente necesario y siguen adelante hacia implementación (la Parte III). Vea 7-8 de la Figura.
7.1 el Ejecutivo Hacen Una Lectura Ligera
La Arquitectura de Integración de Servicio define aplicaciones comerciales como componentes reusables, con holgura cambiados de funcionabilidad comercial, y cómo se vinculan estos componentes. Éste es el concepto de una arquitectura orientada en servicio (SOA). Mientras SOA ha sido considerada una mejor práctica por más de dos decenios (vea recuadro complementario), hasta hace poco, muy pocas compañías estaban interesadas en ellos. Ahora SOA es repentinamente un tema caliente en la tecnología de la información, y en el centro de muchas iniciativas en las que se puso la mira aumentar agilidad de negocio. En este punto, si su compañía no es por lo menos investigar a SOA, debería ser.
En una SOA, el negocio discreto funciona o los procesos son creados como componentes independientes con acoplamientos mutuos normalizados que pueden ser a los que se accedió por otras aplicaciones, servicios, o los procesos comerciales, a pesar de la plataforma o lenguaje de programación. Estos servicios pueden estar flexiblemente combinados para soportar procesos diferentes o cambiantes y comerciales y funciones. Soporta la creación de aplicaciones complejas, lo cual puede rápidamente ser ensamblado de servicios existentes y nuevos.
Existiendo misión aplicaciones críticas actualmente en la computadora central y otras plataformas pueden estar envueltas en interfaces de servicios de Web y luego podido acceder a de otras aplicaciones o navegadores de Internet. Esto le permite negocios hacer servicios empresariales de existir sistemas, y rápidamente implemente e integre funcionabilidad nueva. La Web utilizadora repara, las compañías pueden empezar a creando a una SOA por el apalancamiento existiendo inversiones e incrementally sumando funcionabilidad nueva. SOA es la arquitectura que mejor permitirá agilidad comercial de largo plazo porque soporte aprovechamiento, e implementación rápida de soluciones nuevas.
La Historia de Servicio Orientó A Architectures
El concepto de SOA comenzó en los inicios de 1980s y fue estrechado por el sistema de redes y comunidades orientadas a objetos que programa. En 1983 el Modelo de Referencia Open Systems Interconnect (la Organización Internacional de Normalización) fue adoptado por el International Standards Organization como una referencia común para el desarrollo de estándares de comunicación de datos (la interconexión de sistemas abiertos). Define las funciones de comunicaciones de datos en siete estratos. Cada estrato define un servicio de comunicación, y cada servicio tiene una interfaz claramente definida con el estrato arriba y debajo de ella. Esta SOA ha pasado la prueba de tiempo. Mientras la tecnología y las capacidades en cada estrato han cambiado dramáticamente, la arquitectura misma perdura. Con tal de que las interfaces entre los servicios permanezcan igual, los servicios mismos pueden variarse fácilmente.
La Fundación Abierta de Software, el (la expansión del crédito interior) grupo responsable para el estándar UNIX, desarrolló el Ambiente de Computación Distribuida basado en una arquitectura orientada en servicio (la Fundación de Software Abierto). La expansión del crédito interior provee servicios de infraestructura para la computación distribuida, incluyendo autenticación y servicios prendarios (Kerberos), los servicios del directorio, las llamadas de procedimiento remoto, y el archivo y los servicios de la gerencia.
CORBA es una arquitectura independiente en vendedor y una infraestructura definida por el Grupo de Gestión del Objeto (OMG) que le permite aplicaciones de computadora trabajar hombro a hombro sobre redes usando el protocolo estándar IIOP. CORBA permite interoperabilidad a través de plataformas. Las aplicaciones CORBA son basadas en componentes.
Las tecnologías más componentes actuales son J2EE y .NET. J2EE es una plataforma basada en componentes que maneja la infraestructura distribuida y soporta servicios de Web para permitir aplicaciones de negocio del interoperable. Es actualmente el modelo más ampliamente componente destacado.
La RED es la implementación de Corporación Microsoft de una arquitectura de servicios de Web, lo cual le permite a las legiones de programadores Corporación Microsoft crear servicios de Web en los lenguajes de programación con los que ellas son más familiares. Estas conservas una inversión muy grande en sets existentes de habilidad. Los programadores J2EE son usualmente más caros que programadores Corporación Microsoft.
7.2 Beneficios de SOA
• permita agilidad comercial. SOA es lo mejor muy para permitir agilidad comercial. Maximiza apalancamiento de recursos existentes al minimizar el tiempo y el costo de destacar hojas de solicitud nuevas. En vez de desarrollar aplicaciones de la nada, compañías pueden utilizar funcionabilidad saliente y pueden crear soluciones nuevas por aplicaciones del componente que ensambla de funcionabilidad existente y nueva. Esto permite implementación rápida de soluciones nuevas.
• provea regreso superior en investment.Companies que definen servicios empresariales reusables y crea o la funcionabilidad de negocio de la envoltura como los servicios estándar maximizará sus inversiones de tecnología de la información, a través del aprovechamiento y el apalancamiento existiendo activos.
• permita agilidad de tecnología de la información. Las definiciones estándar de servicio pueden proveer un estrato de abstracción para los servicios empresariales. Un servicio puede correr dondequiera y puede ser al que se accedió de dondequiera. Por consiguiente, una compañía fácilmente puede cambiar posición o tecnología del código subyacente.
• recorte entrenar costos. Los servicios empresariales pueden ser narrados de forma resumida y abstraídos en una forma que los facilita a utilizar y ensamblar en aplicaciones componentes con programación mínima. Las compañías pueden utilizar a más programadores expertos para crear las definiciones de funcionabilidad subyacente y de servicio, lo cual luego puede ser reusado por ahí menos programadores técnicos y herramientas aplicativas visuales de asamblea.
• reduzca el costo de experimentar y el insecto concentrándose. Cada servicio es como una caja negra que realiza una función específica y tiene una interfaz publicada que acepta que los aportes definidos y los productos definieron salidas. Cada servicio puede ser probado individualmente, luego podido reusar repetidas veces. El probar interfaces es medianamente franco, y puede estar automatizado usando probando herramientas.
• los tipos del cliente de múltiplo del soporte y las plataformas. La SOA le ofrece un estrato de abstracción de las plataformas subyacentes. Esto lo hace posible para los tipos múltiples de dispositivos de usuarios finales, incluyendo navegadores y dispositivos móviles como localizadores, los teléfonos celulares, PDAs, y otros dispositivos especializados para utilizar la misma funcionabilidad comercial y comunicar información para los dispositivos diferentes. Esta independencia de la plataforma provee grandes ahorros para empresas de envergadura que tienen una miríada de tecnologías en uso.
• el tiempo de desarrollo de velocidad a través del desarrollo paralelo. Los programadores diferentes independientemente pueden dedicarse a los servicios diferentes porque cada servicio es autónomo y no depende del estado de otro servicio. Con tal de que las interfaces de servicio son bien definidas al principio del proyecto, y los programadores saben qué esperar de otros servicios, fácilmente pueden definir y pueden crear servicios independientemente. Solía ser que se dice tan programadores pasados unos ciertos más que continúan diciendo punto para un proyecto el tiempo de desarrollo de incrementos. Esto es ya no cierto con SOAs.
• aumente dimensionalidad y disponibilidad. Porque SOA le ofrece diapositiva de la posición, allí está el potencial para aumentar dimensionalidad por las instancias de múltiplo de adición de un servicio. Tecnología que contrarresta carga dinámicamente encontraría y encaminaría la petición a la instancia apropiada de servicio. Asimismo, si hay instancias múltiples de un servicio en la red, y uno se hace disponible, el software transparentemente puede encaminar la petición a otra instancia, por consiguiente con tal que la mejor disponibilidad. Esto son más el caso pues los servicios nuevos se fundamentaron en servicios aplicativos, y no funcionabilidad del legado que han estado envueltos en el servicio de Web interactúa.
Lo que hace SOA tan autoritaria es que puede estar hecha en ambos una escama grande y pequeña con los mismos beneficios. La A de Tejas y M University pudieron demostrar que estos principios en el desarrollo de su sistema de inscripción de clase en línea describieron en el Estudio de Casos 7.1 (el Software AG n.d.). Esta aplicación fue un paso pequeño en la aplicación de SOA con un impacto grande. Finalmente, SOAs se convertirán en la forma que la mayoría de organizaciones construyen sus infraestructuras de tecnología de la información, porque es la forma mejor y sólo probada proveer a agility.However de largo plazo, tomará bastante tiempo e inversión a lograr llegar. Hasta la fecha, la mayor parte del foco de la industria ha estado encendido solucionando los problemas técnicos considerables de conectividad. Sin embargo, los obstáculos de más grande para verdaderamente permitir agilidad comercial a través de SOA están adentro definiendo, construyendo, y manejando servicios empresariales reusables.
El Estudio De Casos 7.1
Los Servicios Estudiantiles Perfeccionadores en A de Tejas y M
La A de Tejas y M University han sido una lídera verdadera en la aplicación de tecnología para soportar la misión de la universidad. Como uno de las instituciones educativas más grandes del mundo, mejorar servicios para los estudiantes – especialmente durante inscripción – permanece una prioridad alta.
Una arquitectura orientada en servicio usando Web servicios está bien satisfacida proveer mejoró inscripción y servicios auxiliares para los estudiantes que esperan más servicios electrónicos y menos tiempo estando en líneas. Así es que una decisión estaba hecha para implementar un servicio en línea. El DEPARTAMENTO DE INFORMÁTICA desarrolló su sistema de inscripción de clase usando servicios de Web y dos empleados y pudo dar un sistema en tres meses. La mayor parte del servicio fue provisto por el Cobol existente y corrida Natural de programas en la computadora central. Fueron vinculados en los servicios de Web usando a EntireX Communicator. Fue estimado tan utilizador que este acercamiento y esta tecnología allí fueron un ahorro de sobre 50 % en el desarrollo que el tiempo comparó con anteriores esfuerzos similares en el departamento.
Durante inscripción, miles de estudiantes fueron servidos simultáneamente y eficazmente. El impacto para la universidad fue un grado superior de satisfacción por estudiantes y una reducción significativa en llamadas telefónicas para el personal universitario.
¿7.3 Servicios Defining – de Abajo hacia Arriba o de Arriba a Abajo?
Hasta la fecha, la mayor parte del foco en SOA y los servicios de Web ha estado en las letras menudas técnicas de definir interfaces. Mientras la definición estándar de la interfaz es la posibilitadora crítica del sistema, el enfoque ascendente tiene sus limitaciones. Si el foco está sólo en la especificación de la interfaz, y no en relación a la forma de definir qué funcionabilidad para exponer como un servicio, las compañías no cosecharán los beneficios completos de una SOA. La agilidad comercial aumentada y los costos disminuidos son dependientes en servicios bien definidos, bien manejados, reusables a los que están acelerados y fáciles conectarse. Desafortunadamente, no hay teoría matemática o la metodología que le puede decir a un desarrollador ya sea el componente o puede reparar está en el nivel correcto de granularity para maximizar aprovechamiento. El método más comúnmente usado de crear servicios empresariales es el acercamiento por tanteo. Esto usualmente significa definir servicios en el contexto de un proceso comercial particular, luego revisando para el aprovechamiento en la siguiente solución.
Un acercamiento comercial de arriba a abajo para definir servicios le permitirán compañías mejor encontrar las necesidades actuales y futuras del negocio. Comienza con los requisitos comerciales. Cada servicio debería proveer la funcionabilidad para encontrar uno o más requisitos comerciales, y el set de funciones debería relacionarse estrechamente. Ésta es cohesión funcional designada. Sin embargo, los servicios deberían ser acoplados ligeramente. El procesamiento dentro de un servicio no debería ser dependiente en el estado de procesamiento en otro. Un servicio abstrae la funcionabilidad de la tecnología subyacente.
En verdad, para lograr terminar el trabajo, ambos métodos de abajo hacia arriba y de arriba a abajo son menester. La estrategia descendente produce un nivel de abstracción que hay que crear agilidad comercial. Sin embargo, en algún punto las necesidades de modelo para encontrar la tecnología, y los servicios necesitan ser implementados como componentes o colecciones de componentes. Las compañías continuarán construyendo componentes de lo de abajo hacia arriba para narrar de forma resumida servicios empresariales. La llave debe hacer estos componentes funcionalmente cohesivo para evitar traslapar funcionabilidad y acoplado ligeramente para permitir cambio rápido y minimizar el impacto de cambio.
7.4 el Diseño Conducido En Acontecimiento de Servicio
En este capítulo le ofrecemos un método conducido en acontecimiento de arriba a abajo para definir servicios empresariales discretos que se usó en un proyecto o base de la empresa. Definir requisitos comerciales en términos de acontecimientos comerciales le ofrece un número de ventajas. Las primeras, conducidas en acontecimiento arquitecturas orientadas en servicio proveen los sistemas más dinámicos. En el ebizQ webinar, " Creando al New Enterprise Agility: El orientado en servicio y "Roy Schulte" conducido en acontecimiento "(http://www.ebizq.net/expoq/events/event39.html),, VP Gartner, indicado," agilidad generalmente involucran prácticas comerciales conducidas en acontecimiento, facilitadas por las arquitecturas orientadas en servicio ". Él usó la analogía de trenes y camiones para describir la agilidad de SOA. " Cambiar la dirección de un camión es más fácil hacer un tren ir donde las huellas no hacen. Si usted quiere que el tren se moviera sobre un pie, usted tiene que hacer una cantidad de trabajo inmensa despedazando y volviendo a poner huellas, " Schulte dijo. "Por otra parte, todo lo que usted necesita hacer para revolver el camión más ágil es movimiento el" timón. SOA es la arquitectura que provee los talones para la empresa ágil.
Los segundos, acontecimientos comerciales son una buena manera para diseñar servicios porque son fáciles que para usuarios comerciales entiendan, identifiquen, y se aseguren en un diseño. Representan las actividades esenciales del negocio. Una de las mejores formas para asegurar máximo aprovechamiento de un servicio es tener un diseño de la interfaz revisión, tan todos los tenedores de apuestas pueden evaluar si el servicio encontrará sus necesidades. Éste es el proceso usado por OASIS para desarrollar estándares. Cuando las compañías adoptan esta práctica, los servicios tienen mejor probabilidad de encontrar un rango más ancho de necesidades. Los tenedores de apuestas comerciales pueden mejor definir y verificar acontecimientos comerciales y respuestas requeridas de sistema, que interfaces técnicas. Las respuestas de acontecimiento definen los requisitos para el diseño de la interfaz.
Finalmente, definiendo los acontecimientos comerciales que el sistema captará y responda para claramente definen los linderos del sistema. Esto es esencial para asegurar implementaciones exitosas y rápidas. Las respuestas de acontecimiento están más allá descompuesto en sets de respuestas de sistema funcionalmente cohesivas. Estas respuestas pueden ser suministradas por sistemas salientes o desarrollo nuevo. Al servicio le puede ser una interfaz integrada para un set de respuestas suministrado por sistemas diferentes que necesitan estar coordinados. Un servicio mismo puede proveer niveles de abstracción diferentes. El servicio también puede ser una función sola provista por un componente o aplicación. Enfocando la atención en acontecimientos comerciales y respuestas requeridas le provee un acercamiento de oriente comercial a definir a la SOA. Este método está descrito en la Especificación de Integración de Servicio.
7.5 Reparan Especificación de Arquitectura de Integración
Algunos ha llamado el proceso de crear servicios empresariales reusables parecido a cocinar panqueques cuadriculados. Usted necesita tirar a lo primer fuera, y se mejora con el paso del tiempo. Mientras es ciertamente un proceso iterativo, esta especificación proveerá líneas directivas para crear servicios reusables. Una transcripción completa de las especificaciones está en E Appendix.
El Estudio De Casos 7.2
Las Aerolíneas del Delta – Manejando Acontecimientos Comerciales
A través del Sistema Nervioso del Delta El Sistema Nervioso del Delta (el DNS) representa una inversión de billón del $1 "para darle los datos oportunos a los clientes, los empleados, y los socios". Sin embargo, no es la entrega de la información, pero el uso de esa información en manejar acontecimientos comerciales que es el beneficio principal del DNS. Por ejemplo, una aplicación inicial del sistema es apuntada contra cargadoras de equipajes y asegurar que tienen un cuadro preciso de portilla los cambia y el vuelo se demora así es que mejor pueden planificar el movimiento de equipaje adelante y completamente aviones. El cambio en el estatus de un vuelo es un acontecimiento comercial que tiene repercusiones a través del sistema de la aerolínea. Cada vez que un acontecimiento ocurre, el cambio en el estatus puede ser sobre el que se actuó proveyendo a los participantes cruciales de ese acontecimiento de la información y los servicios reaccionar a estos cambios.
El DNS convierte Delta en una empresa de tiempo real con la habilidad mejor servirle a sus clientes. Sin embargo, también tiene la generación enorme de renta y las implicaciones que ahorra costos. Por ejemplo, tener información de tiempo real le permite a Delta aumentar el número de vuelos al día llevando hacia dentro aviones y fuera ayunador. El tiempo extra de tripulaciones de tierra desocupadas puede acortarse a través de mejor planificación. Los costos asociados con el mal uso de bolsas pueden ser eliminados.
Mientras el foco está encendido haciendo disponible información, el valor estará de moda identificar acontecimientos significativos y luego tomar asigne acción como resultado de los acontecimientos. No es menester que un negocio cree a una fuente informativa nueva. Más bien, es importante para crear una arquitectura que puede actuar sobre flujo y acontecimientos comerciales esos a través del sistema eficazmente como un servicio. El delta ha puesto tal sistema en el lugar con su DNS
La Mesa de Categoría de Servicio lista todas las respuestas requeridas para los acontecimientos comerciales, y define si la función ya existe en uno o más sistemas, o si es funcionabilidad nueva. La mesa también define servicios probables para proveer la funcionabilidad. El servicio en este punto es una primera mejor suposición en una definición de servicios y será afinado más allá en el siguiente paso. Al definir servicios, piense acerca de módulos dentro de una aplicación existente que puede realizar el servicio o componente probable
Los módulos para el desarrollo (la Figura 7-2, página 128).
La Mesa de Definición de Servicio
La Mesa de Definición de Servicio completamente describe cada servicio en un nivel suficiente para servicios de Web que crea u otra integración interactúa. Cada servicio debería estar descrito en términos de sus funciones y los sistemas usaron crear el servicio. En crear esta mesa, el grupo todo funciona y respuestas conjuntamente eso formará un módulo cohesivo. Por ejemplo, el servicio debería manejar un set particular de datos, algo semejante como la información del cliente, o la información del producto, o debería realizar un servicio específico que podría ser usado en otras aplicaciones, como el crédito inspeccionando o valorando. Allí debería ser suelto acoplándose entre los servicios. Cada servicio le debería interactuar cualquier otro servicio a través de la interfaz definida. Los cambios en un servicio no deberían afectar funcionar de otros servicios.
La descripción define cómo será el servicio implementado, algo semejante como el servicio de Web, el adaptador aplicativo, o la interfaz aplicativa (la Figura 7-3, página 129) de módulo. Éste es el lugar en la especificación que derriba el diseño de arriba a abajo al nivel de especificación de tecnología.
La Mesa de la Interfaz de Servicio
Mientras la Web que el estándar de utilidades define cómo especificar una interfaz, no define los datos y funcionabilidad que las necesidades de la interfaz a contener. La Especificación de la Interfaz de Servicio provee la información necesaria para servicios de Web que crea u otra aplicación o el componente interactúa. Usando la Mesa de Definición de Servicio, liste todos los aportes, todas salidas, y todos métodos que las necesidades de la interfaz para soportar, y determinar cómo será la interfaz implementado (la Figura 7-4).
El portal basó interfaz con servicio de acceso de datos que controlaLa conectividad para fuentes de datos de atrás. Ya sea construirá WebRepare o instale solución de conectividad de datos del vendedor
La Mesa de la Interfaz de Servicio
La meta de acoplamientos mutuos normalizados decisivos es maximizar agilidad comercial. La interfaz estándar permite aplicaciones y los servicios construyeron en plataformas diferentes con tecnología e idiomas diferentes para intermanejar. Le permite servicios cambiar funcionabilidad interna y decreta o estando bajo de tecnología sin aplicaciones de otro que impacta o componentes, con tal de que la interfaz permanece igual. Por consiguiente, entender bien la interfaz es esencial para maximizar aprovechamiento y agilidad. Es altamente recomendado que las compañías sigan mejores prácticas de los comités de estándares cuándo definiendo interfaces por revisiones del diseño que tiene que incluyen a todos los tenedores de apuestas. Es también recomendado que usted cree un glosario de terminología que es significativa y coherente a través de todos los tenedores de apuestas. El propósito de la Especificación de la Interfaz es permitir tales revisiones del diseño, y completamente describir la interfaz así es que puede ser implementada correctamente y óptimamente.
Los componentes de un Diagrama de Caso de Uso
El Diagrama de Caso de Uso y la Especificación
Un diagrama de caso de uso puede usarse para bosquejar las relaciones entre usuarios, acontecimientos, y servicios. Es la pieza final del acertijo para la especificación. Integra toda la información de las secciones previas.
Los casos de uso definen actores y cómo le interactúan los services.Actors de sistema representan un papel, y pueden ser humanos, otras computadoras, pedazos de hardware, o aun otros soportes lógicos. Deben suministrar estímulos para iniciar el acontecimiento que a su vez requiere a un respuesta de sistema (o el servicio) .Use los casos describe el comportamiento del sistema cuándo uno de estos actores envía un estímulo particular. Bosqueja los acontecimientos comerciales y las respuestas de sistema en términos del estímulo de acontecimiento que provoca el caso de uso, los aportes de y las salidas para otros actores, y los comportamientos que convierten los aportes a las salidas.
Los componentes antiácidos de diagramas de caso de uso son el actor, el caso de uso, y el actor societario .An (vea a Figure 7-5) es bosquejado usando una figura de la vara, y el papel del usuario está escrito bajo los icon.Actors pueden ser humanos, otras computadoras, pedazos de hardware, o aun otros soportes lógicos. Un caso de uso es bosquejado con una elipse, y el nombre del caso de uso está escrito inside.Associations son líneas entre actores y los casos de uso, y señalan que un actor participa del caso de uso.
Para soportar el análisis de requisitos poco funcionales (e.g., La fiabilidad, maintainability, y actuación), los casos de uso deberían crearse soportar panoramas en las cuales estos requisitos poco funcionales serán probados. Los ejemplos incluyen: 1) crear un caso de uso que prueba actuación a través de una interfaz componente distribuida, y 2) creando un caso de uso que prueba lo adaptable de un componente por ahí extendiéndolo (i.e., Sumando clases) y examinándolo para determinar si los principios arquitectónicos del diseño aquiete agarre. Estos casos nivelados en sistema de uso pueden ser implementados en una moda autónoma por medio de lo que una parte o la rebanada de la arquitectura está siendo probado independientemente de la funcionabilidad comercial de dominio que necesitará soportar.
Para crear el caso de uso, primero identifican los actores primarios en el sistema. Luego priorice los servicios para ser implemented.We recomiende crear un caso de uso para cada servicio propuesto. Por poner un ejemplo, vea a Figure 7-6 (página 132).
El cliente Haga un pedido Ostente perfil de cliente
Ordene estándar ítem de lista del producto Los usos
El Diagrama de Caso de Uso
La Especificación de Caso de Uso contiene texto que más allá describe el caso de uso (la Figura 7-7). La especificación del texto también usualmente describe todo lo que puede ir incorrectamente durante el curso del comportamiento especificado, y qué acción remediadora el sistema tomará. Esta especificación puede estar hecha a la medida o expandida para manejar asuntos particulares dentro de una implementación o la organización.
Las Conclusiones del 7.5.7 y el Comentario
Esta sección debería proveer cualquier comentarios finales en el sistema, el diseño, o el uso del sistema. Debería incluir cualquier asuntos sabidos, cualesquiera restricciones, o a atenuar factores tan contribuidos para las decisiones, o podría afectar el sistema en el futuro.
7.6 Mejores Prácticas en la Arquitectura de Integración de Servicio
Una arquitectura orientada en servicio exitosa le permite a las compañías rápidamente implementar soluciones comerciales nuevas o cambie a existentes y pueda entregar un ROI. físico Sin Embargo, SOA no es necesariamente fácil para lograr. Las siguientes mejores prácticas le ayudarán a cosechar los beneficios completos de SOA.
• provea soporte y estructura organizativa de alto nivel. El éxito con SOA requiere compromiso de la inversión y empresa en curso. SOA no puede estar consumada con un proyecto solo. Allí necesita ser un grupo de expertos, algo semejante como el centro de aptitud, eso enfoca la atención en la definición, el crecimiento, y el aprovechamiento de la SOA. Allí necesita ser procesos organizativos e integración de la empresa que gobierna políticas. Como la integración cruza linderos organizativos, también puede causar disputas territoriales. Las compañías necesitan procesos y políticas para manejar estas disputas (descrito en más detalle en seccione 4.4, Gobierno de Estructura Organizativa y de Arquitectura).
• implemente arquitectura basada en normas. Los estándares ayudan a asegurar la interoperabilidad y portabilidad. Impiden cierre de tecnología adentro, y ayudan a conservar valor en las inversiones de tecnología de la información. Los estándares de servicio de Web permiten la adopción extendida de SOA, a pesar de que ha sido una práctica arquitectónica mejor sabida para tres decenios. XML permitiendo sus sistemas es una forma para proveer un transporte basado en normas, gerencia, y formato de almacenamiento para todos los datos estructurados y el contenido no estructurado dentro de la organización.
• implemente un acercamiento basado en normas. Siga los pasos de los comités de estándares que tienen larga experiencia con crear procesos que tienen éxito en estándares del interoperable que crea. Realice revisiones del diseño para interfaces de servicio, e incluya a todos los tenedores de apuestas. Los tenedores de apuestas pueden ser identificados a través de los casos de uso.
• piense a lo grande, empiece en trozos pequeños. Al prever una implementación SOA, considere el impacto ancho en la empresa para maximizar aprovechamiento y agilidad. Pero comience con un proyecto que tiene un alcance limitado y una probabilidad alta de éxito. De un éxito nacen otros. Usted aprenderá bastante de cada implementación, así es que espere hasta que usted tenga un par de implementaciones más pequeñas bajo su cinturón antes de abordar los retos más difíciles.
• invierta dinero en entrenamiento. Usted tendrá una probabilidad superior de éxito si sus empleados saben lo que están desempeñándose. Pocos diseñadores y programadores tienen experiencia con SOAs construidos en estándares como los servicios de Web y XML. Es demasiado nuevo. Todos los tenedores de apuestas, los gerentes de negocio inclusivo y de tecnología de la información, los arquitectos, los diseñadores, los programadores, y el personal operacional del soporte necesitan entender los conceptos globales de SOA y lo que su papel en el proceso es. Los arquitectos y los diseñadores necesitan entender los parámetros del diseño y las mejores prácticas para crear sistemas dinámicos y reusables. Los programadores necesitan entender la tecnología nueva, y cómo implementar servicios y componentes de infraestructura. La necesidad operacional del personal del soporte para entender las implicaciones de manejar a una SOA distribuida.
• use herramientas para ahorrar tiempo y dinero. No pruebe para handcraft todo. Una variedad ancha de herramientas está disponible que puede hacer más pequeño el tiempo y los sets de habilidad requirieron implementar la solución. Invierta dinero en herramientas cuando las ventajas claramente pesan más que el costo.
El Grupo Delantero es un estudio de casos interesante donde cada uno de estas mejores prácticas entraron en juego (el Estudio de Casos 7.3) (el Dragón 2003).
El Estudio De Casos 7.3
"La solución brillantemente Simple" del Grupo Delantero
Había estado descrito como una "solución brillantemente simple" cuando el Grupo Delantero tomó una decisión a finales de los 1990s para poner en línea su portal de Web de clientes con su sistema de servicio al cliente. Retrospectivamente, sorprende que más organizaciones no se hayan tratado de la misma conclusión, porque los beneficios parecen tan aparentes:
• la paridad entre la interfaz del cliente canaliza en la funcionabilidad
• la reducción de complejidad en mantener sistemas múltiples
• una arquitectura que puede ser con apoyo externo y reusada para otros propósitos
Los resultados reales han sido impresionantes. El entrenamiento de empleados internos se acortó significativamente, virtualmente eliminando cuatro para seis semanas de entrenamiento. Retirar un gran número de bases de datos y las aplicaciones redujeron la complejidad de la arquitectura subyacente. Personal de casi 10 % de menos estaba obligado a mantener los sistemas. El usuario que los tiempos de respuesta fueron reducidos por 60 % para 70 %, aumentar la eficiencia del personal. Además, la arquitectura soportó que el desarrollo de aplicaciones tan mejorados de varios claves de comercial va en procesión, resultando adentro procesamiento directamente directo de transacciones. Los ahorros de estos cambios - se esperó - dan como resultado ahorros anuales de millón del $30. La inversión para lograr esto fue significativa, pero lo esperado rendimiento de la inversión es una tasa de rendimiento interno de sobre 20 %.
Mientras las inversiones en la arquitectura son a menudo consideradas como costos que no tienen beneficio aparente, la Vanguardia demuestra que la implementación de una arquitectura que soporta reusabilidad puede tener impacto significativo en un negocio. Una arquitectura orientada en servicio bien diseñada es la llave para lograr estos beneficios. Los servicios de Web no son requeridos, como vemos con qué logró Vanguard, pero debería ayuda más bajo los costos que se aguantó en este proyecto reduciendo la cantidad de trabajo aduanero de infraestructura que es ahora previsto a través de la Web repara tecnología.
7.7 Siguientes Pasos
Los servicios son los bloques constructivos para aplicaciones complejas e integración conducida en proceso. La empresa reusable decisiva repara, así como también ingeniarse y medir aprovechamiento, requiere compromiso de la inversión y empresa en curso. El éxito con SOA es mucho una materia de gerencia como sea tecnología. Las compañías interesadas en agilidad comercial de largo plazo invertirá dinero en todos los aspectos de la arquitectura de integración de la empresa, incluyendo información y arquitecturas de integración de proceso (Capítulo 8 y Capítulo 9, respectivamente). Las compañías enfocaron la atención en agilizar necesidades tácticas, definirán sólo lo que es absolutamente necesario y siguen adelante hacia implementación (la Parte III). Vea 7-8 de la Figura.
No hay comentarios:
Publicar un comentario