Cuando un servicio se implementa como un servicio web, se debe adherir (proporcionar) un contrato de comunicaciones explícitamente declarado y definido colectivamente por uno o más descriptores del servicio, en el cual debe figurar especificaciones como:
• Nombre del Servicio.
• Forma de accesos.
• Funcionalidades que ofrece.
• Descripción de los datos de entrada de cada funcionalidad que ofrece.
• Descripción de los datos de salida de cada funcionalidad que ofrece.
De este modo, todo consumidor de los servicios accederá mediante el contrato, logrando la independencia entre el consumidor y la implementación del propio servicio. Con esto se evita el manejo incorrecto de los datos, se evita trabajo innecesario en la invocación entre estos servicios y también se pone de manifiesto que la existencia de un modelo de datos a nivel de servicio es una de las primeras necesidades que se debe tener en cuenta.
Ver más detalles de este principio.
2.- Bajo Acoplamiento:
Este principio hace referencia a que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
- con la implementación de la lógica del servicio.
- con los recursos del ambiente de implementación
- con la tecnología del vendedor
- con el padre del proceso de negocio
- con los miembros del servicio
Ver más detalles de este principio.
3.- Abstracción:
El principio de abstracción permite encapsular el servicio y reducir el acoplamiento. 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.
El uso de estándares permite definir interfaces uniformes que esconden la lógica del servicio respecto del entorno que le rodea (sistemas proveedores y consumidores).
Este nivel de abstracción permite centrarnos exclusivamente en la especificación del servicio, sin incluir información tecnológica ni de ninguna otra naturaleza, más allá de la propia especificación estándar del servicio desde el punto de vista del negocio al que sirve, que queda recogida en su contrato.
Ver más detalles de este principio.
4.- Reusabilidad:
La reutilización es el principal principio de la arquitectura SOA, cada servicio debe ser analizado, diseñado y construido de manera que su uso pueda ser explotado al máximo, es decir, cada servicio debe ser de algún modo genérico con el fin de que pueda usarse en diferentes contextos y satisfacer distintos objetivos. De esta manera, los servicios podrán ser reusables dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.
Por otro lado, estos servicios reutilizables deben estar diseñados de maneratal que su solución lógica sea independiente de cualquier proceso de negocio otecnología en particular.
Con este principio se busca reducir las posibilidades de duplicación de lógica.Si un servicio que ya existe en un contexto funcional se ajusta a la nuevalógica reutilizable, en lugar de crear un nuevo servicio, dicha lógica debe formar parte del servicio existente.
Ver más detalles de este principio.
5.- Autonomía:
Este principio nos dice que todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizado desde el punto de vista de la plataforma de ejecución.
Transformación gradual reduciendo el acceso a recursos compartidos e incrementando el aislamiento físico.
Ver más detalles de este principio.
6.- No estado:
Un servicio no debe guardar ningún tipo de información. 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 deben provenir directamente de los parámetros de entrada. Esto maximiza la escalabilidad del servicio.
Tipos de estado:
- sesión
- contexto
- datos de negocio
Ver más detalles de este principio.
7.- Descubrimiento:
Todo servicio debe poder ser descubierto de alguna forma para que pueda descubierto, entendido y por tanto utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.
Ver más detalles de este principio.
8.- Composición:
Este principio nos dice que todo servicio debe estar construido de tal manera que pueda ser utilizado para construir servicios genéricos de mayor complejidad, el cual estará compuesto de servicios de menor nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).
El concepto de desarrollo de software a partir de componentes existentes independientemente fomenta el concepto de composición. Por ello el concepto de composición es heredado por la orientación a servicios, por lo que un proceso de negocio está automatizado mediante la combinación de múltiples servicios. Sin embargo, dentro de la orientación a servicios es mayor el enfoque en la creación de servicios que se pueden componer y recomponer dentro de múltiples soluciones para proporcionar la agilidad prometida por la SOA. Como resultado de este énfasis, algunas pautas son requeridas para el desarrollo de servicios que pueden ser efectivamente agregados en varias soluciones.
Ver más detalles de este principio.
Written by Orlando
We are Creative Blogger Theme Wavers which provides user friendly, effective and easy to use themes. Each support has free and providing HD support screen casting.
0 comentarios:
Publicar un comentario