Aplicaci N

Soa Aplicación
Se deben considerar 11 pasos para lograr la adopción de SOA los cuales describiremos:
1. Planificación de la adopción de SOA:
En este paso todavía no se tiene el alcance que se le va a poner a SOA, cuántos servicios se tienen ni cómo se van a gobernar. Normalmente en esta etapa se trata de hacer ver a la gente de Negocio de las bondades que tiene para lograr una mayor agilidad yreducción de costes en el desarrollo de software de negocio.
2. Análisis del inventario de servicios:
En esta etapa se identifican aquellas piezas de software reutilizables que puedan llegar a ser servicios. Se trata de ajustar su “grano” de detalle para que sean lo suficientemente genéricos para que toda la empresa los puedan usar pero lo suficientemente concretos como para servir para algo.
3.Análisis orientado a servicios:
Esta etapa se da la dentificación de los servicios candidatos. ¿cómo identificamos a los servicios de negocio? tal vez estaentrada pueda resultar  de ayuda.
4. Diseño orientado a servicios y a contrato:
Se define el contrato o interfaz del servicio. Qué parámetros de entrada, que parámetros devuelve, qué es lo que hace (que tenga sentido para el negocio). Se empiezatambién a fijar quién es el propietario del servicio y qué nivel de servicio debe proporcionar. La propiedad del servicio es una de las decisiones que de hondo calado que van a tener repercusión durante toda la vida del servicio (de dónde sale el dinero, con qué equipo se va a contar, qué plazos, qué prioridades, etc. etc.)
5. Diseño de la lógica del servicio:
Es el diseño técnico del mismo. Eneste punto ya debería estar categorizado. Por ejemplo, como servicio de núcleo (expone directamente una lógica de negocio del núcleo o backend de negocio), servicio compuesto (creado a partir de otros servicios más sencillos), etc. Esto ayuda en el diseño del mismo.
6. Desarrollo del servicio:
la implementación del propio servicio. En casi todas las grandes empresas de banca-seguros, esto se haceen la plataforma Java (JEE). Si usamos un ESB, se puede aprovechar las herramientas gráficas que suelen acompañar este tipo de Middleware para componer servicios y procesos de manera visual (claro que no es oro todo lo que reluce). Normalmente la implementación se basará en web services
7. Test de los servicios:
es necesario disponer de herramientas que permitan la prueba de servicios de maneraaislada, sin depender del resto de servicios. Esto es más importante en una arquitectura SOA, donde se promete que dejaremos de desarrollar programas para “componer” servicios basándonos en otros servicios ya existentes. Si esto es así, en potencia, para probar un único servicio necesitamos que todo el resto esté desplegado y funcionando.
8. Despliegue del servicio y mantenimiento:
el despliegue deuna solución basada en SOA suele ser varias veces más complejo y con más riesgo que una aplicación “tradicional”. Por un lado, los suites de desarrollo de los fabricantes más importantes, basadas en herramientas gráficas, generan código automáticamente que suele implicar varios aplicaciones a desplegar (varios EAR de Java). Si a esto le juntamos una aplicación de frontal como interfaz de usuario yotra aplicación con la la lógica de negocio, no es extraño encontrarnos con más de una docena de EARS que hay que desplegar de manera coordinada. Si contamos además, que la consola de despliegue puede no permitir hacerlo en paralelo, el despliegue se puede demorar más de una hora.
Además es necesario que el despliegue se haga con un cierto orden. Una opción sencilla y efectiva en este caso, esdesplegar en orden, partiendo de lo que está mas cerca de la base de datos hasta el frontal (modelo de datos, lógica de acceso a datos, lógica de negocio, servicios, frontal)
9. Monitorización del uso del servicio:
No sólo se quiere conocer quién usa el servicio, que tiempo de respuesta se da, qué tipo de errores, etc. etc. También se quiere llegar más allá asignando prioridades según el tipo de...