El uso de la arquitectura orientada a servicios ofrece la oportunidad de elegir un Artefacto: Proveedor de servicios basado no sólo en la funcionalidad
que proporciona sino en las Calidades de servicio (QoS) que puede garantizar. Uno de los motivos para cambiar un
proveedor de servicio puede a menudo ser resultado de un cambio en los requisitos no funcionales, necesitándose un
nuevo nivel de QoS no actualmente soportado por un proveedor existente. También puede derivar de la degradación de la
QoS esperada por el cliente de servicio. Una arquitectura orientada a servicios permite esta agilidad a menor coste, en
general, que otros estilos arquitectónicos.
La calidad de servicio se puede observar desde dos perspectivas: la del proveedor y la del cliente. El proveedor
de servicios garantiza proporcionar y mantener una calidad de servicio para cada uno de sus servicios o grupo de
servicios. El cliente de servicio, por otro lado, "compara" las calidades de servicio deseadas y elige un proveedor
según éstas. También es importante observar que en valores comerciales en los que el cliente y el proveedor entran en
un contrato legal sobre el uso del servicio, estas garantías de calidad de servicio se ejemplifican en acuerdos de
nivel de servicio, frecuentemente con penas asociadas con el no cumplimiento de un proveedor de dichos acuerdos.
Por tanto, es muy importante especificar claramente los requisitos no funcionales necesarios para el cliente (por
ejemplo, coste de transacción, rendimiento, disponibilidad, seguridad, etc.) de un servicio o un conjunto de servicios.
En esta tarea de Especificación de servicio, identificamos requisitos no funcionales para la QoS deseada. Los
requisitos no funcionales se utilizarán para asignar recursos para componentes de servicio que ofrecen los servicios y
para financiar la realización y el mantenimiento de componentes de servicio que garanticen la entrega de la QoS a lo
largo del tiempo. Deberán tomarse decisiones clave sobre arquitectura para garantizar que se conseguirá la calidad de
servicio prometida basada en requisitos no funcionales.
La forma en que los requisitos no funcionales se relacionan con el Artefacto: Especificación de servicio no se define en esta
directriz. No hay límites establecidos en lo que constituye dicho requisito, obviamente QoS, la seguridad se ha
mencionado anteriormente, entre los ejemplos están:
-
Disponibilidad (por ejemplo, tiempo medio entre anomalías)
-
Ventana operativa (¿hay algún tiempo en el que no espere utilizar este servicio?)
-
Tiempo de respuesta (¿con qué rapidez responde el servicio a una solicitud?)
-
Rendimiento en hora punta (¿cuántas solicitudes de servicio pueden producirse por unidad de tiempo, por
ejemplo , por segundo, por minuto, por hora?)
|