Modelamiento Orientado a Servicios (SOMA)

En [Jolla 2005] se define SOMA como una empresa inspirada en el enfoque de transformacin tcnica, destinada a la aplicacin de los objetivos de procesos de negocios en base de una arquitectura orientada a servicios. Se crea una continuidad entre la intencin de negocios y de TI mediante la extensin de la aplicacin de caractersticas del negocio (objetivos, indicadores clave de rendimiento, y los objetos de la supervisin de la ejecucin) en el anlisis y las decisiones de TI. El mtodo de SOMA puede servir como un complemento de la CBM (o de otros enfoques de modelado de negocios), teniendo los procesos clave de negocio y los modelos identificados y priorizados por un compromiso de CBM y armonizarlos con las aplicaciones y la infraestructura necesaria para poner en prctica esos procesos. El mtodo de SOMA incluye siete grandes etapas como se muestra en la figura 3.7. Estas fases son fractales es decir que contienen capacidades que pueden ser aprovechados como sea necesario en secuencias diferentes.

Figura : Etapas de SOMA [Arsanjani 2008]

Es importante sealar que las fases de SOMA no son lineales. Se aplican en un riesgo impulsado, iterativo, y el enfoque incremental utilizando un matiz peculiar al ciclo de vida de SOA. El ciclo de vida de un proyecto de SOA, utiliza un enfoque de fractales, que es una combinacin de dos principios clave. El primer principio del desarrollo de software fractal es la aplicacin de las tareas de mtodo a libre alcance similar, es decir, las tareas se realizan de manera similar en los mbitos de lmites ms grandes o ms pequeos (ya sea en toda la empresa, lnea de negocio, o de un solo proyecto de iniciativa).

El segundo principio de desarrollo de software fractal es la iteracin sucesiva. Los conceptos de ciclo de vida iterativo e incremental de desarrollo han existido por mucho tiempo. Se centran en el establecimiento de prioridades y la mitigacin de los factores de riesgo a fin de garantizar la calidad de los productos de la solucin. Esto tiene sus races en el modelo en espiral de desarrollo de software. Iteracin sucesiva est conectada con la idea de la evolucin del servicio, e implica un enfoque no slo los riesgos asociados a la ejecucin, sino tambin con las dependencias relacionadas con la cartera de servicios como los servicios se desarrollan a travs del ciclo de vida. As, en SOMA, la priorizacin del modelo de servicio se lleva a cabo y sobre la base de un servicio de diagrama de dependencia y tiene en cuenta los factores de riesgo implicados en la arquitectura TI. Un subconjunto de los servicios es prioridad para la siguiente implementacin prevista para ser medida dentro de un concepto de pruebas de prototipo. Con el tiempo las funcionalidades y capacidades del negocio que no fueron seleccionados para la exposicin de servicios pueden ser definidas en una iteracin posterior. 3.4.1. Ciclo de vida SOMA En [Arsanjani 2008] se muestran una representacin secuencial de la corriente general del ciclo de vida fractal de SOMA a un nivel alto. En la figura 3.8 se muestra un flujo de proceso tpico de un compromiso de ejecutar el mtodo de SOMA.

Figura : Ciclo de vida SOMA a un nivel alto [Arsanjani 2008]

3.4.1.1. Modelado de Transformacin Empresarial Fase en la que los procesos y componentes que representan las funciones ms importantes son modelados y analizados, ya sea en toda la organizacin o dentro del un rea de dominio concreta que represente nuestro objetivo. Esta fase no es estrictamente necesaria, pero es muy recomendable su realizacin.

3.4.1.2. Gestin de la Solucin Las soluciones de SOA son hbridos por naturaleza y suelen incluir varios tipos de soluciones. Esto se debe a los servicios identificados y especificados durante la fase inicial de SOMA, estas soluciones se pueden realizar en fases posteriores de SOMA por diferentes escenarios, tales como desarrollos a medida, integracin y transformacin de sistemas legados y la integracin de paquetes de aplicacin. SOMA est diseado para apoyar el carcter hbrido de las soluciones SOA y prescribe las actividades especficas de orientacin para aplicar cada uno de los tipos de solucin. SOMA define una plantilla de solucin para cada tipo de solucin, esta plantillas contienen: tareas, productos de trabajo, roles y orientacin. 3.4.1.3. Fase de Identificacin La fase de identificacin se refiere a la identificacin de los tres constructos fundamentales de SOA: servicios, componentes, y los flujos. En SOMA se fundamenta que una buena prctica es utilizar un conjunto de tcnicas de identificacin complementaria de servicios. Basndose en una sola tcnica se tiende a crear un conjunto incompleto de los servicios. La fase de identificacin de SOMA es un proceso que identifica los servicios candidatos y crea una cartera de servicios de negocio alineados a los servicios de TI, que en su conjunto apoyan los procesos de negocio y los objetivos de la organizacin. Los servicios son inicialmente designados como candidatos durante la identificacin, porque todas las capacidades comerciales y las funcionalidades no tendrn que ser expuestas como servicios ni fondos disponibles para cubrir a todos. Adems, slo el subconjunto de los servicios de candidatos se expone en la cartera de servicios. La cartera de servicios completa a menudo tendr que ser escalonada en varias liberaciones. As, los servicios designados como expuestos sern implementados. Dentro de la identificacin SOMA define las siguientes etapas: - Modelado de los servicios por los objetivos (GSM) - Descomposicin de dominio - Anlisis de los activos existentes - Servicio de refactorizacin y racionalizacin Modelado de los Servicios por los Objetivos (GSM): GSM es una declaracin generalizada de los objetivos de negocio relacionadas con el alcance del proyecto, se descompone en sub-objetivos que deben cumplirse para que el nivel mayor de objetivos se pueda cumplir. Esta descomposicin jerrquica de objetivos lleva entonces, a una serie de acciones concretas que conduzcan a la identificacin de los servicios que le ayudarn en el cumplimiento de los sub-objetivos. Tambin es importante identificar los indicadores clave de rendimiento (KPI) para proporcionar una base objetiva para evaluar el grado en que el objetivo ha sido alcanzado. KPI y mtricas identificadas durante este proceso se utilizan para medir, controlar y cuantificar el xito de la solucin de SOA. En la tabla 3.1 se muestra un ejemplo del proceso GSM.

Tabla 3.1: Ejemplo de las GSM [Arsanjani 2008]

Descomposicin del dominio: Esta tcnica se centra en el anlisis top-down de los dominios del negocio y el modelado de procesos de negocio para identificar los servicios, componentes y flujos. Se analizan puntos de vista estticos y dinmicos del negocio, incluyendo la informacin, reglas y variaciones. El dominio del negocio se divide en reas funcionales (grano grueso) para llegar a una visin esttica de su estructura subyacente. El proceso de anlisis de informacin comienza con la identificacin de las entidades del negocio, adems de particin se realiza para llegar al conjunto de subsistemas que son las fronteras para realizar las funciones de negocio. Los dominios y sus reas funcionales son las conexiones iniciales a la gobernabilidad en SOA, porque ellos sern los propietarios de los servicios. En la tabla 3.2 se puede apreciar un ejemplo sobre la descomposicin de areas funcionales.

Tabla 3.2: Descomposicin del dominio [Arsanjani 2008]

Una visin dinmica de la empresa se refleja en sus procesos de negocio. Normalmente los procesos son identificados y una jerarqua proceso se desarrolla para un dominio de negocio para iniciar el modelado de procesos y la descomposicin. Un subconjunto de los procesos de negocios atribuible a los objetivos de negocio pertinentes requiere el modelado de procesos ms detallados y la descomposicin para obtener una mayor comprensin de las interacciones del conjunto seleccionado de procesos de negocio. En la tabla 3.3 se muestra un ejemplo del proceso de descomposicin.

Tabla 3.3: Proceso de descomposicin de dominio [Arsanjani 2008]

Los mtodos de ciclo de vida de estas entidades empresariales significativas se aaden como servicios candidatos para la cartera de servicios. El anlisis de los activos existentes: En esta actividad, el arquitecto SOA lleva a cabo un anlisis de alto nivel de los sistemas existentes, servicios de aplicacin, y otros activos disponibles para el proyecto. El propsito es identificar los activos, tales como los sistemas, paquetes y funcionalidad legadas que son capaces de apoyar a la realizacin de los servicios que satisfagan las necesidades de negocio. La atencin se centra en los activos existentes, que desempean un papel en los procesos de negocio. Inicialmente, se realizar un mapeo de grano grueso de los procesos de negocio y el proceso de las actividades de la cartera de las aplicaciones existentes e interfaces de las aplicaciones. Posteriormente se realiza un pliego de condiciones con un grano ms fino, donde se incluye las especificaciones de los mensajes. En la prctica, se tiende a mirar a las funciones del sistema facilitados por los activos existentes, lo que conduce a las funciones de negocios que luego son designados como servicios candidatos. En [Arsanjani 2008] se recomienda que se debe abstenerse de aadir todos las funciones del los sistemas existentes como candidatos, slo se deben consideran aquellos que proporcionan valor al negocio. Al finalizar esta etapa se tendr un portafolio de servicios ms completo y listo para entrar al proceso de refactorizacin y racionalizacin. Refactorizacin servicio y la racionalizacin: esta actividad consta de tres partes: la refactorizacin de los servicios, las pruebas de fuego de los servicios (Service Litmus Test SLT), y la racionalizacin. Los servicios en la jerarqua son rediseados de tal manera que los servicios de nivel inferior que tienen algn tipo de afinidad lgica se agrupan en un servicio de nivel superior. Posteriormente, se aplican una seria de cuestionamientos (Pruebas SLT) sobre el conjunto de servicios candidatos, para obtener un conjunto de servicios expuestos. Los servicios que han fracasado en los SLT sern implementadas como una funcionalidad ordinaria. Tenga en cuenta que no todos los servicios se llevarn a la implementacin, pero pueden ser aplazados en una versin posterior de lanzamiento. Un plan de lanzamiento incluir las dependencias entre los servicios, componentes, flujos, de informacin y reglas. La racionalizacin consiste en una revisin del modelo de servicio con los actores comerciales para verificar la pertinencia de los servicios que han sido seleccionados para la exposicin y, posteriormente, planificadas y financiadas a ser construida en la prxima versin. 3.4.1.4. Fase de Especificacin En la fase de especificacin de SOMA, se realiza un diseo de alto nivel, as como partes importantes del diseo detallado de componentes de servicios. Durante la fase de especificacin, aprovechamos los activos existentes para elaborar los servicios, los flujos y componentes que se identificaron en la fase de identificacin de forma iterativa e incremental, para ayudar as en la realizacin. El modelo de servicio est ms desarrollado en trminos de dependencias de servicios, los flujos y la composicin, eventos, normas y polticas, operaciones,mensajes, requisitos no funcionales, y las decisiones de la administracin del estado.

En esta fase se llevan a cabo dos actividades inciales antes de elaborar y determinar los servicios, los flujos y subsistemas (lmites de componentes): en primer lugar se debe elaborar y especificar los modelos de informacin, y en segundo lugar se realizar los anlisis adicionales de grano fino sobre la especificacin de los activos existentes. En esta fase se cambia el modelo de datos conceptual en un modelo lgico de datos, donde se rellenan los atributos que deben aplicarse y estas deben ser definidas en trminos de sus dominios o tipos de datos lgica (por ejemplo, el carcter, nmero, fecha, y la imagen).En esta fase tambin se centran en el diseo de mensajes de servicio que incluyen entrada, salida, y mensajes de error. Especificacin de Servicios: La especificacin de servicio es el ncleo de la actividad de servicios de modelado y se centra en la elaboracin del diseo detallado de los servicios. Las dependencias de los servicios con otros servicios, componentes o aplicaciones, la composicin de los servicios y el flujo de los servicios en conjunto a definir la realizacin y la coreografa de servicios que permitan las funciones y procesos de negocio. Las operaciones de servicio son designados sobre la base de granularidad de servicio, la afinidad funcional, y la cohesin de los servicios en la jerarqua de los servicios. Los servicios expuestos y las operaciones del servicio se asignan en la aplicacin de TI como uno de los siguientes tres escenarios y se ilustran en la figura 3.9: - Operaciones de servicios expuestos sin tener el servicio expuesto. - Tanto el servicio como sus operaciones expuestas. - Tanto el servicio y las operaciones de servicio estn expuestos, pero el padre de los servicios expuestos es un rea funcional en la jerarqua del servicio.

Figura 3.9: Tres escenarios diferencies de la exposicin de los servicios [Arsanjani 2008]

Anlisis de Sub-Sistemas: Subsistemas significan los lmites lgicos para las funcionalidades empresariales. Los subsistemas son identificados por la descomposicin funcional de las reas funcionales. Las reas funcionales y los subsistemas que existen en las reas funcionales son refinados en componentes de servicios que son responsables cada uno de un aspecto funcional del subsistema. Un resultado importante de esta tarea es un diagrama de dependencia de subsistema, que muestra las dependencias de todos los subsistemas y sus interfaces entre s y se identifican los activos subyacentes existentes. Por lo general se aplican OOAD (Diseo y anlisis orientado a objetos) dentro del lmite de los subsistemas. En la figura 3.10 podemos apreciar un ejemplo de la composicin de un subsistema.

Figura 3.10: Composicin de un sub-sistemas orientado al servicio [Arsanjani 2008]

Especificacin de componentes: Durante la especificacin de los componentes se explora el uso de patrones que nos pueden ayudar a estructurar los componentes de servicio en un conjunto de componentes funcionales (apoyo a las capacidades de las empresas) y esperamos por los componentes tcnicos encargados de la prestacin de apoyo auxiliar, desde la perspectiva de la tecnologa y la infraestructura. Al realizar OOAD dentro de un subsistema, podemos especificar los componentes del servicio, con lo cual nos permite definir el comportamiento del modelo esttico y dinmico de los componentes de servicio mediante la definicin de interfaces de componentes de servicio, el desarrollo de esquemas de componentes, la identificacin de las dependencias de los componentes funcionales y tcnicos, y la determinacin de los flujos internos de los componentes. En la figura 3.11 podemos apreciar un ejemplo de especificacin de componentes de servicio.

Figura 3.11: Especificacin de componentes de servicio [Arsanjani 2008]

3.4.1.5. Fase de Realizacin Esta fase nos permite validar las decisiones de realizacin, mediante la realizacin de la exploracin de viabilidad tcnica, que trata de ejercer las decisiones de arquitectura y los factores de riesgo ms alto de proyectos a travs de prototipos extensibles diseados y desarrollados desde el principio. La seleccin y creacin de instancias de los patrones de integracin es fundamental para el xito y despliegue de SOA (actualmente es muy utilizado el bus de servicios empresariales ESB como patrn de escenarios de integracin). De exploracin de viabilidad tcnica y realizacin de las decisiones: la exploracin de la viabilidad tcnica es una manera de evaluar, planificar e implementar prototipos claves del ejercicio de la arquitectura, esto expone las decisiones que tienen el mayor potencial de impacto y riesgo en la solucin funcional de los requisitos basados en SOA. En la exploracin de la viabilidad tcnica, tenemos los referentes de los factores de riesgo y los desafos tcnicos centrados en los requisitos no funcionales. En esta etapa se recomienda que la exploracin de la viabilidad tcnica se realice para cada uno de los patrones de interaccin de servicio elegido en la solucin basada en las capas de la arquitectura de referencia SOA. La exploracin de viabilidad tcnica designa los patrones de interaccin que son seleccionados en base a varios factores, como la madurez de la organizacin en la adopcin de SOMA y de su infraestructura tecnolgica subyacente. Capas de la arquitectura SOA de referencia: SOMA permite descubrir los elementos clave y producir productos de trabajo, que poco a poco rellenar una arquitectura de referencia que proporciona una visin instantnea de nuestra implementacin SOA. Esta visin facilita la comunicacin y proporciona una representacin de los avances y la evolucin de la SOA en un diagrama de alto nivel.

La arquitectura de referencia SOA, se empieza a cubrir desde la fase 3 de SOMA, que produce los primeros artefactos para la arquitectura de referencia, en la figura 3.12 podemos apreciar una arquitectura de referencia SOA, construida en funcin el proceso de SOMA.

Figura 3.12: Arquitectura de referencia SAO construida a travs de SOMA [Arsanjani 2008]

3.4.1.6. Fases de Implementacin, Despliegue, monitorio y gestin En la fase de implementacin, se construyen, se generan, y se montan los servicios funcionales, los componentes tcnicos que realizan los servicios, los componentes y flujos. En algunos casos, los activos existentes son rediseados y refinados de manera que puedan ser usados para realizar un servicio. En la fase de implementacin se lleva a cado la integracin y pruebas del sistema de servicios, componentes y flujos. La herramienta SOMA de IBM utiliza una variedad de plantillas de soluciones que incluyen soporte para el desarrollo personalizado, empaquetado integracin de aplicaciones, integracin de sistemas legados y de la transformacin, el diseo y el uso de ESB, y de los servicios empresariales compuestos. La fase de implementacin se extiende por las actividades y tareas de solucin de estas plantillas para diferentes tipos de solucin en la solucin global. Dependiendo de los tipos de solucin, las actividades y tareas adicionales de la solucin de las plantillas correspondientes se ejecutan para crear y actualizar los artefactos necesarios. En la fase de despliegue, seguimiento y gestin, nos centramos en los envases, el aprovisionamiento, la ejecucin de pruebas de aceptacin por el usuario, y el despliegue de

servicios en el entorno de produccin. Al igual que en la fase de aplicacin, la fase de despliegue se extiende tambin por las actividades y tareas de solucin de plantillas para diferentes tipos de solucin en la solucin global. Adems, la herramienta SOMA de IBM ofrece apoyo en la supervisin y gestin de procesos de negocio y seguimiento de resultados en el entorno de produccin. SOMA tambin ofrece vnculos a la supervisin en tiempo de ejecucin y la gestin, como en el sistema, la infraestructura y la gestin de la red.

Service Oriented Unified Process (SOUP)

Como el nombre sugiere, este enfoque definido en [4] por K. Mittal se basa principalmente en el Rational Unified Process. La SOUP es un enfoque de seis fases de desarrollo de software: Inicio, definir, disear, construir, implementar y apoyar. Cada una de estas etapas representa un conjunto distinto de actividades crticas para el xito de una implementacin SOA. Por supuesto, como en cualquier proyecto, es necesario adaptar el proceso a su propia organizacin, Sin embargo, la SOUP carece de documentacin detallada y deja espacio para la adaptacin. La figura 1 muestra el proceso de SOUP. No hay nada particularmente radical en esto: Todos los proyectos de desarrollo de software bajo la visin de SOA se definen de una manera similar.

Figura: Ciclo de vida de SOUP

Se utiliza en dos versiones ligeramente diferentes:

- SOUP para la implantacin inicial de SOA basado en de RUP. - SOUP para mantenimiento de implantaciones de SOA ya existente el cual se basa
en XP. SOUP para la implantacin inicial de SOA: Se ver cada fase de SOUP y como se aplica para implantaciones iniciales de SOA, la figura x muestra la relacin entre las fases de SOUP y el modelo RUP.

Figura: SOUP y el modelo RUP

A continuacin de detallara cada fase con mayor profundidad Inicio En esta fase, se establece la necesidad de un proyecto SOA en su organizacin. Se puede aplicar el modelo de madurez de SOA para determinar el nivel de su organizacin de la madurez arquitectnica y determinar los factores bsicos de la conduccin hacia una arquitectura SOA. Adems, en este punto se explican los conceptos bsicos del concepto de SOA a todos los equipos de proyectos al servicio de la empresa y planear una estrategia para un proceso de retroalimentacin y sugerencias. Los principales resultados de esta fase son los siguientes: Visin de SOA y mbito de aplicacin: Este es un documento que resume la visin general del proyecto. Tambin ofrece algunos lmites que establecen el alcance del proyecto, que deber incluir al menos un par de lneas de negocio o proyectos. Estrategia SOA: Este es un plan de alto nivel que explica cmo el proyecto ser ejecutado. Anlisis del ROI: Este documento resume todos los gastos y el ahorro que este proyecto traer. Plan de comunicacin: Este documento explica cmo el equipo de SOA se comunicar con otros equipos del proyecto y los usuarios de negocios.

Los Clientes (los accionistas de la empresa) no siempre entienden los beneficios de nuevos productos de software en sus negocios. Los equipos de la empresa que definen la estrategia de SOA necesidad de aprovechar la experiencia de dominio de los equipos de proyecto para ayudar a identificar problemas de negocio y los medios para agilizar las operaciones. Multi-funcional analistas y gestores de proyectos analizar el negocio de los clientes para determinar las ventajas de una solucin basada en SOA. Los factores clave son los analistas examinan las operaciones de los clientes internos, la interaccin con sus socios, proveedores y consumidores, y su modelo de negocio en general. stos ayudan a los analistas de desarrollar y recomendar una estrategia SOA. En esta etapa, tambin es necesario hacer un anlisis de retorno de la inversin completa de la estrategia SOA que le recomendamos que el cliente compre o han construido. Este anlisis muestra claramente la relacin costo-beneficio de la organizacin - en el corto, mediano y largo plazo. En mi opinin, la entrega ms importante en esta etapa es el plan de comunicaciones. En ltima instancia, los equipos de proyecto y los actores de negocios conocen el negocio mejor que los equipos de arquitectura y analistas. El plan de comunicacin asegura que estos grupos de inters internos entienden y estn involucrados en el proceso. Definir

Esta fase es de lejos la ms crtica del proyecto SOA. La participacin de las empresas y del equipo del proyecto determina el xito del proyecto. Los miembros del equipo deben comprometerse a participar en la definicin de los requisitos y casos de uso desarrollados como parte del lanzamiento inicial de SOA. Esta fase del ciclo de vida del proyecto consiste en actividades tales como: La recopilacin de requisitos Anlisis de las necesidades Definicin de los requisitos no funcionales Creacin de un plan de proyecto con plazos y estimaciones Definicin de la infraestructura tcnica Utilice la definicin de casos y la realizacin Definicin de la arquitectura en general y la documentacin

Los principales resultados de esta fase son los siguientes: Documento de requisitos funcionales: Esta es una descripcin detallada de todos los procesos de negocio que la SOA ser la superficie como los servicios empresariales. Documento de requisitos no funcionales: Los requisitos descritos aqu se incluyen las consideraciones de rendimiento, los acuerdos de nivel de servicio (SLA), las necesidades de infraestructura, y as sucesivamente. Los casos de uso y el uso de las realizaciones de casos: Estos son casos que se detallan el uso de todos los servicios a las empresas que se estn construyendo. Documento de arquitectura SOA: Esta es una descripcin de la arquitectura general del proyecto, incluidos los componentes de hardware y software. Documento de aplicacin SOA: Este documento explica qu proyectos entran dentro del mbito del proyecto SOA y cmo los proyectos en curso se puede construir en la parte superior de la SOA. Documento de definicin de la infraestructura: Este documento incluye detallados diagramas de despliegue de infraestructura, destacando los servidores y la ubicacin de las conexiones entre los servidores necesarios para aplicar la SOA. Plan del proyecto: Este plan detallado para la totalidad del proyecto incluye los hitos y dependencias. Modelo de apoyo y de gobierno: Esta es una descripcin de cmo la SOA contar con el apoyo y los gobernados. Incluye consideraciones tales como el monitoreo y la gestin de SLA.

Diversos estudios (ver Recursos para los enlaces) han demostrado que los requisitos relacionados con los temas son la principal razn del fracaso de los proyectos de software, proyectos de SOA no son diferentes. La calidad del software a veces se define como la conformidad del software a sus necesidades. Sin embargo, la calidad del software es probablemente mejor medible por la calidad de los requisitos que se rene, y no slo por el nmero de requisitos que cumple. la metodologa SOUP recomienda requisitos formales de proceso de recopilacin y gestin. XP en realidad no define un proceso formal para recopilar y documentar los requisitos, sino que los desarrolladores crear historias de usuario XP (ver Recursos para ms informacin

sobre los mismos) y tratar de poner estas historias en un orden lgico para proporcionar una secuencia con los requisitos.Para esta etapa de desarrollo, como un proceso no es suficiente. En RUP, el proceso es ms detallado y utiliza las tcnicas ms formales para asegurar que las sesiones de los requisitos estn completas, documentado y validado. Se recomiendo el uso de un repositorio de requisitos que en ltima instancia, se unir a los casos de uso, diseo y cdigo que proporciona trazabilidad a travs del proyecto. Este repositorio puede ser la herramienta IBM Rational Requisitos Pro, o cualquier otra herramienta de gestin de otros requisitos que la organizacin opte por el uso. A change management process is also important. Un proceso de gestin del cambio tambin es importante. Diseo En esta fase, ms detalles sobre los artefactos de diseo de la fase de definicin. Las realizaciones de casos de uso y el documento de arquitectura de software se traduce en documentos de diseo detallados. En este momento, los arquitectos SOA (por lo general un subconjunto de los arquitectos de la empresa) necesidad de involucrar a los arquitectos del proyecto para asegurarse de que el diseo presentado por el equipo de SOA funciona para proyectos especficos. Los arquitectos SOA, incluso puede optar por hacer un par de pequeas pruebas de concepto de proyectos para demostrar la visin de SOA. Los principales resultados de esta fase son los siguientes: Documento de diseo detallado: Este documento pone de relieve cmo los servicios son diseados y construidos. Aplicacin del modelo de programacin: Este documento proporciona directrices sobre cmo el desarrollo se estructurar. Los temas tratados incluyen el proceso y tecnologas que se utilizan, la codificacin de las normas, procedimientos de implementacin, y as sucesivamente. Modelo de base de datos: Esto incluye un diagrama entidad-relacin de las bases de datos utiliza la SOA. Las pruebas y el plan de control de calidad: Este plan incluye detalles de las pruebas y los planes de control de calidad y se incluyen los casos de prueba.

Construir Durante la fase de Construccin, bsicamente se puede utilizar cualquier mtodo iterativo de construccin que quiere construir su SOA. Esta fase implica el desarrollo de nuevos, as como actividades de integracin. Sus actividades no se limitan al software, pero tambin puede incluir los subproyectos relacionados con la infraestructura, tales como proyectos de consolidacin de hardware o los esfuerzos por centralizar el alojamiento de servidores. El esfuerzo en general se maneja en un plan nico proyecto SOA, pero con toda probabilidad, varios pequeos sub-equipos estarn trabajando en las actividades de construccin diferentes. Esta fase de un ciclo de vida del proyecto consiste en actividades tales como: El desarrollo iterativo

Iterativo de control de calidad y pruebas User documentation Documentacin para el usuario

Los principales resultados de esta fase son los siguientes: Base de cdigo: El cdigo debe ser almacenado en una especie de repositorio de cdigo fuente de control. Resultados de las pruebas: Los resultados de la ejecucin de los casos de prueba y los planes de control de calidad deben estar disponibles para examen. Documentacin: La documentacin debe incluir la documentacin detallada en el cdigo y los cambios a los documentos de diseo.

Desplegar En esta fase, en realidad desplegar el SOA. Que se extienda a los equipos de proyectos individuales, que comienzan a utilizar la arquitectura SOA en sus proyectos en un entorno de produccin. Tal vez la clave ms obvia entrega de esta fase es su aplicacin en la produccin. Sin embargo, ms importante an es el plan que establece los proyectos que pondr a prueba la SOA. Esto conduce al siguiente paso de la metodologa de sopa, que determina cmo los proyectos en curso a utilizar la nueva arquitectura. Los otros resultados clave de esta fase son los siguientes: Modelo de implementacin: Se establece el despliegue de la estructura general de la SOA. Modelo de uso: Este proporciona directrices sobre el uso de la SOA. Este modelo se convierte en importante como los diferentes equipos de proyectos y lneas de negocio comienzan a utilizar la nueva arquitectura. Los niveles de apoyo continuo del modelo: Este modelo codifica todas las actualizaciones del apoyo y modelo de gobierno que se desarroll en la fase de definicin.

Apoyo Aunque este es el paso final del ciclo de desarrollo de software, sin embargo es una fase muy importante. En esta fase, se asegura el apoyo continuo de SOA, correcciones de errores, y el desarrollo de nuevas funcionalidades. Esta fase de un ciclo de vida del proyecto consiste en actividades tales como: Mantenimiento Bug fixes Correcciones de errores Training Formacin Continuous project buy-in Proyecto continuo de buy-in

En este punto, la SOA est en produccin. Pero, cmo los equipos de proyecto se benefician de la arquitectura? Es que ahora tenemos que seguir todos los pasos descritos anteriormente en detalle en la construccin de aplicaciones que consumen los servicios existentes o en el diseo de nuevos servicios que hacen uso de una ya existente SOA?

Como vers en la siguiente seccin, se pueden beneficiar en la realidad de una metodologa ms ligera.

Servicio de modelado orientado a la arquitectura (SOMA)

IBM ha anunciado Service-Oriented Modeling y Arquitectura (SOMA) como el primero anunciado pblicamente SOA relacionadas con la metodologa en el ao 2004. [1] SOMA se refiere al mbito ms general de modelado de servicios necesarios para disear y crear SOA. SOMA abarca un mbito ms amplio y pone en prctica orientada a los servicios de anlisis y diseo (SOAD) a travs de la identificacin, especificacin y realizacin de servicios, componentes que realizan esos servicios (tambin conocido como "componentes de servicio"), y los flujos que pueden ser utilizados para componer los servicios. SOMA incluye un anlisis y un mtodo de diseo que se extiende el anlisis tradicional orientada a objetos y basado en componentes y mtodos de diseo para incluir las cuestiones pertinentes y el apoyo de SOA. Se compone de tres fases principales de la identificacin, especificacin y realizacin de los tres principales elementos de SOA, a saber, servicios, componentes que realizan esos servicios (componentes tambin conocido como servicio) y los flujos que pueden ser utilizados para componer los servicios. SOMA es un mtodo de extremo a extremo SOA para la identificacin, especificacin, realizacin y ejecucin de los servicios (incluyendo servicios de informacin), los componentes, los flujos (procesos / composicin). SOMA se basa en las tcnicas actuales en reas como el anlisis de dominio, que agrupa a las reas funcionales, anlisis de la variabilidad orientada (VOA) modelado de procesos, desarrollo basado en componentes, anlisis orientado a objetos y el diseo y el modelado de casos de uso. SOMA introduce nuevas tcnicas como el modelado de metas de servicio, la creacin del modelo de servicio y una prueba de fuego de servicios para ayudar a determinar el nivel de detalle de un servicio. SOMA identifica los servicios, los lmites de los componentes, los flujos, composiciones, y la informacin a travs de tcnicas complementarias que incluyen la descomposicin de dominio, el objetivo del servicio de modelado y anlisis de los activos existentes.

[ editar ] La vida SOMA actividades de modelado del ciclo

Orientada a los servicios de modelado y arquitectura (SOMA) se compone de las fases de identificacin, especificacin, realizacin, implantacin, despliegue y gestin en el que los bloques de construccin fundamentales de SOA se identifican a continuacin, refinado y aplicado en cada fase. Los bloques de construccin fundamentales de SOA consiste en servicios, componentes, flujos y relacionados con ellos, la informacin, la poltica y los contratos.