MetrÃ³polis y Gobierno de SOA - Willy .Net

More documents

Recommendations

Info

Aviones, Trenes y Automóviles Los modelos que hemos visto en este artículo pueden generar más preguntas que las respuestas que proporcionan. Es de esperar, no obstante, que se vea que utilizar Servicios Web con transportes alternativos puede ofrecer una nueva variedad de aplicaciones que hasta el momento habían sido restringidas por el uso de HTTP. Una de las preguntas que pude surgir es "¿Cuándo se debe implementar un transporte que no sea HTTP?" Para colaborar con la respuesta y para sintetizar los contextos enumerados en este artículo, pueden referirse a la Figura 14. Sobre el autor Simon Guest es Program Manager en el grupo de Architecture Strategy en Microsoft Corporation, y se especializa en la interoperabilidad y la integración. Simon realizó un Master sobre Seguridad IT en la Universidad de Westminster, Londres, y es el autor de Microsoft .NET y de J2EE Interoperability Toolkit (Microsoft Press, Sept. 2003). Se puede llegar a Simon a través de su blog en http://www.simonguest.com. 32 • Journal 5 • www.microsoft.com /architecture
Relación de la estrategia de producto con la arquitectura Charlie Alfred Introducción Existen sistemas para generar valor para sus interesados. Lamentablemente, este ideal sólo se cumple en forma limitada. Los métodos actuales de desarrollo, como cascada, espiral, ágil, con frecuencia brindan una dirección incompleta e inadecuada a los interesados, arquitectos, y personas a cargo del desarrollo. El presente documento presenta dos conceptos esenciales: modelos de valor y estrategia de arquitectura, que no figuran en muchos procesos de desarrollo. La creación de modelos de valor bien definidos brinda una dirección que mejora la calidad de las decisiones de intercambio, en especial en sistemas configurados para muchos usuarios en diversas configuraciones. La existencia de una estrategia de arquitectura claramente establecida brinda una dirección coherente y de alto nivel para el sistema, de la misma forma que la Constitución de Estados Unidos lo hace para su nación. Finalmente, el presente documento mostrará cómo estos dos conceptos se pueden integrar de forma eficaz con los métodos de espiral, cascada o ágil. Nuestras maneras actuales de construir sistemas complejos de software intensivo no son efectivas. Esto no significa que sean inadecuadas. Muchos sistemas hechos utilizando métodos de cascada, espiral o ágiles se configuran con éxito y pueden satisfacer a sus interesados. Sin embargo, muchos no lo logran, y por causas que pueden corregirse. Los procesos tradicionales para construir sistemas de software intensivo, como los métodos de cascada y espiral, se basan en los requerimientos para brindar una dirección. Una creencia errónea típica es que los requerimientos son afirmaciones que describen el problema. Según Greenfield y Short [1], no es así. Ellos definen la solución desde un punto de vista de los usuarios y el patrocinador del sistema. Figura 1. Agilidad del Sistema Caracteristica Mecanismo Ejemplo Brindar Funciones Útiles Brindar una Nueva Capacidad Importante Mejorar la Calidad de Capacidades Existentes Superar obstáculos Factores de Limitación de Dirección Sobrellevar los cambios • Journal 5 • www.microsoft.com /architecture Los Requerimientos tienen algunas fallas notables: • Los requerimientos con frecuencia utilizan una estructura binaria. Funcionan como calificación de aprobado/no aprobado en un curso escolar, y brindan poca ayuda para la toma de decisiones de intercambio. Por supuesto, estas decisiones de intercambio se deben tomar en alguna parte del proceso. Con frecuencia se toman en forma implícita, y sin considerar totalmente las consecuencias. • Los requerimientos con frecuencia se utilizan como base para especificar los criterios de aceptación evaluables para un sistema. En el proceso de especificarlos, se toman en forma implícita importantes decisiones sobre el diseño, sin considerar en forma total las implicancias. Con el tiempo, estas decisiones se deberán revertir con un costo significativo, o sino terminarán limitando el potencial del sistema. • Los requerimientos tienden a considerar a todas las personas de un determinado tipo de usuario como iguales. Por ejemplo, el uso de escenarios típicos para un sistema médico podría referirse a médicos y enfermeras, mientras que los que se usan para sistemas inmobiliarios podrían referirse al comprador, vendedor, agente o prestamista. El problema es que dos médicos no son el mismo, y no necesariamente tendrán las mismas necesidades. Existe una buena razón por la cual los restaurantes más conocidos tienen muchas opciones de platos en el menú. • Con frecuencia, no está definida la información necesaria para tomar decisiones de arquitectura de software efectivas. Todos los sistemas se configuran en entornos que colocan obstáculos importantes en su camino. Superar estos obstáculos es responsabilidad de cada sistema, y tener éxito a pesar de estos es indicio de un sistema eficaz. Sin embargo, salvo que las personas a cargo del desarrollotengan un entendimiento extremadamente profundo del dominio del problema, no tienen la sagacidad adecuada para realizar juicios valorativos correctos. Given Imaging Inc desarrolló la cápsula de 11x26 mm que contiene una cámara digital capaz de atravesar y tomar fotos de partes del tracto superior Gastrointestinal del paciente. Intel Pentium 4 CPU utiliza una regla de diseño de 90 mm (reducida de los 130 mm) y puede llevar a cabo 13 mil millones de instrucciones por segundo. Muchos fondos comunes de inversión y carteras privadas gestionadas están obligados a cumplir con limitaciones de inversión. Los sistemas de cumplimiento pre-comerciales analizan actividades propuestas para verificar que la cartera siga en cumplimiento Identificar y Mitigar Riesgos Un sistema de detección corta-viento en aviones comerciales detecta la presencia de microráfagas que pudieran provocar estallido del avión en proceso de aterrizaje Oportunidades de explotación eBay reconoció que la población creciente de consumidores con acceso a Internet creó una oportunidad para brindar capacidad de remate electrónico Adaptarse Rápidamente a las Nuevas Condiciones Eastman Kodak reconoció el salto tecnológico que permitió el uso de la fotografía digital y logró la penetración en el mercado en este segmento para compensar la baja en ventas de película. Polaroid no tuvo tanto éxito en este aspecto. 33
Page 1 and 2: Aprenda la disciplina ejerza el art
Page 3 and 4: Reconocimientos Editor Ejecutivo &
Page 5 and 6: Introducción a Mapas Conceptuales
Page 7 and 8: Figura 3. Estructura de una asociac
Page 9 and 10: "ABC Limited era el proveedor top d
Page 11 and 12: Esta función permite que la ontolo
Page 13 and 14: Metrópolis y Gobierno de SOA Richa
Page 15 and 16: entre lo homogéneo y lo heterogén
Page 17 and 18: Figura 2. Composición colaborativa
Page 19 and 20: Figura 4. Esquematización de la Of
Page 21 and 22: mas. Esto conduce a la necesidad de
Page 23 and 24: Las tecnologías para la construcci
Page 25 and 26: Con respecto a los recursos, las et
Page 27 and 28: 3.J. Kontio, A Case Study in Applyi
Page 29 and 30: Figura 1. Se utiliza un Web Service
Page 31 and 32: Tuxedo, etc.), siempre y cuando sea
Page 33: Esto funciona, pero un enfoque más
Page 37 and 38: • Se enfoca más en lo que hacen
Page 39 and 40: Figura 5. Arquitectura sobre Creaci
Page 41 and 42: Alguien tuvo la idea de esbozar una
Page 43 and 44: Permitir una informática a escala
Page 45 and 46: Figura 4. Ejemplo de una aplicació
Page 47 and 48: Tal como es el caso de nuestro mund
Page 49: ha atraído es en algún punto inme

MetrÃ³polis y Gobierno de SOA - Willy .Net

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?