Los principios de diseño de la Arquitectura Orientada a Servicios:

Los principios de diseño de la Arquitectura Orientada a Servicios:

Si la teoria no se aplica correctamente durante el analisis de un proyecto en muchos casos se presentan retrabajos y problemas en los sistemas algo muy claro y necesario es entender de SOA y para esto cito a Mary E. Shacklett, creo que define el concepto de forma clara y amigable en buen crcistiano.

"SOA es una técnica que ha surgido del desarrollo de software orientado a objetos que fue evolucionando hacia la creación de servicios web que encapsulan piezas de software de negocio usadas en la web para coordinar procesos de negocio de empresa."

Estos principios o al menos los mas relevantes vistos en clase son:

1. Contratos de servicio estandarizados: forma parte de la esencia misma de un servicio. Para que se considere un servicio,  su interfaz de entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos  que forman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de los estándares como WSDL y XSD, el contrato del servicio está autodescrito.
   Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a su vez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicio web, a pesar de que parece que son los que más abundan.
2. Servicios con bajo acoplamiento: hace referencia al nivel de dependencia entre servicios, entre el proveedor y el consumidor. Cuanto menos acoplamiento se logra una mayor independencia para el diseño del servicio y su posterior evolución
3. Abstracción: este principio pone el enfásis en ocultar los detalles internos del servicio, tanto como sea posible. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo
4. Reusabilidad: como es conocido, la arquitectura SOA no busca la sustitución de las lógicas de negocio actuales sino que proporciona una forma de reaprovechar todos estos activos encapsulandolos en servicios para que a su vez puedan ser reutilizados por otros servicios.
5. Autonomia: Este principio indica que el servicio tiene un alto grado de control sobre su entorno de ejecución y sobre la lógica que encapsula
6. Sin estado: el tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar provienen de los parámetros de entrada.
7. Capacidad de descubrimiento: al servicio se le dota de meta datos, gracias a los cuales puede ser descubierto de manera efectiva. Estos meta datos pueden ser interpretados de manera automática pudiendo ser reutilizados. Para ello es necesario disponer de un mecanismo de descubrimiento (llamado registro de servicios) como por ejemplo el UDDI.
8. Composición: define la capacidad de un servicio para formar parte de un servicio más complejo. A medida de que la arquitectura SOA se consolide, los nuevos servicios (de más alto nivel) podrán implementarse a partir de los servicios de más bajo nivel ya existentes. La implementación de nuevos servicios se reducirá al mínimo y que los nuevos se crearán a partir de otros ya pre existentes.
9. Interoperabilidad: este principio no formaba parte de los 8 principios originales ya que en realidad es una propiedad que forma parte de todos ellos.  Cada uno de los anteriores contribuye a la interoperabilidad de alguna manera. En las arquitecturas SOA, el problema de la falta de esta cualidad es uno de los más importantes. Hay que tener en cuenta que muchos de los servicios que intervienen se implementan con una tecnología diferente, incluso con un sistema operativo distinto.
   Por ejemplo, se puede tener un servicio realizado en Java ejecutándose sobre Linux que invoca a otro implementado en .net corriendo en una máquina con Windows. Históricamente las especificaciones que dan forma a los servicios web (como WSDL, SOAP, etc.) eran tan ambiguos que las dos partes estaban prácticamente condenadas a no entenderse. Iniciativas como el Basic Profile 1.0 han contribuido a eliminar estas ambiguedades, simplificando estos estándares, logrando que el consumidor y el proveedor del servicio puedan comunicarse entre sí.
   
   
   Durante nuestro proyecto aplicamos Autonomía y Abstracción.