start

Cuando nos enfrentamos a la adopción de SOA en la empresa, nos sentimos desbordados… y con razón. Como siempre, todo depende del caso en concreto, pero por lo general, cambiar el modo de diseñar el software tradicional por uno orientado a servicios conlleva cambios a todos los niveles (no sólo técnicos), y todos sabemos la dificultad que implica cualquier tipo de cambio en un empresa… y cuanto mayor es la empresa, mayor es la dificultad.

Así que una la pregunta recurrente para las personas que tienen que aplicar SOA en la empresa, es ¿por dónde empezar?.

Creo que un buen consejo sería que lo primero de todo… nos olvidemos de las cuestiones técnicas. Con frecuencia el perfil de las personas a las que se nos encarga este cometido es técnico, normalmente analistas o arquitectos de desarrollo de aplicaciones… pues bien, lo primero creo que sería que dejemos de pensar en web services, buses, registros de servicios y protocolos varios…

Lo primero es responderse a las preguntas más básicas… preguntas cuya respuesta no hace falta ninguna cualificación técnica. ¿Y que tipo de preguntas son estas?… que tal si empezamos por ¿Qué servicios tengo que hacer?

La identificación o “levantamiento” de los servicios es una de las tareas más difíciles e implica sobre todo conocimiento de negocio aunque también es necesario tener unos conceptos (pocos pero muy claros) de SOA.

Los servicios a hacer deben cumplir los siguientes criterios, esto debería darnos una pista sobre los servicios a diseñar primero:

  • Tienen sentido para el negocio, es decir, responden a una necesidad concreta de negocio. Por ejemplo “dar de alta asiento contable” o “consultar ficha de paciente”.
  • El servicio tiene que ser modular, tener cohesión (cada servicio se dedica a una cosa) y exponer al consumidor únicamente la información que necesita (bajo acoplamiento)
  • Cada uno de los servicios tiene el interfaz (el contrato con el cliente) claramente definido
  • Tiene que poderse securizar de manera independiente a otros servicios
  • Tiene que ser distribuible. Cada servicio se puede desplegar en una máquina diferente
  • Se debe poder sustituir un servicio por otra implementación sin afectar al resto.
  • Se debe poder invocar cualquier aplicación dentro o fuera de la organización.
  • Debe permitir el que se pueda fácilmente construir (componer) un nuevo servicio más complejo a partir de los servicios anteriores.

Creo que con esto ya tenemos trabajo de sobra para empezar con SOA. Y si fuereis una pequeña pista sobre como identificar los servicios, podéis releer este post al respecto y este otro sobre cómo identificar servicios.

Y tú ¿por dónde has empezado o por donde empezarías tu proyecto SOA?

Anuncios