Utilizing a Service-Oriented Architecture provides the opportunity to choose a Artifact: Service Provider based not only on the functionality it provides, but on the Qualities of Service (QoS) that it may guarantee. One of the reasons for changing a Service Provider may often be a result of a change in non-functional requirements, necessitating a new level of QoS not currently supported by an existing provider. It may also result from the degradation in QoS expected by the Service Consumer. A Service-Oriented Architecture allows this agility at a lower cost, in general, than other architectural styles.

QoS can be viewed from two perspectives: that of the Provider and Consumer. The Service Provider guarantees to provide and maintain a quality of service for each of its services or group of its services. The Service Consumer, on the other hand, “shops around” for the desired QoS and chooses a Provider based on QoS. It is also important to note that in commercial settings where the Consumer and Provider enter into a legal contract over the use of the service, these quality of service guarantees are reified in Service Level Agreements, frequently with penalties associated with the failure of a Provider to meet such agreements.

Therefore, it is very important to clearly specify the non-functional requirements required by the consumer (e.g., cost of transaction, performance, availability, security, etc.) for a service or set of services. In this task of Service Specification, we identify the non-functional requirements for the desired QoS. The non-functional requirements will be used to commit resources for service components that offer the services and to fund the realization and maintenance of service components that will ensure the delivery of the QoS over time. Key architectural decisions must be made to ensure that the promised quality of service based on the non-functional requirements is achieved.

The manner in which Non-Functional Requirements are attached to the Artifact: Service Specification is not defined by this guidance. Neither are there bounds set on what constitutes such a requirement, obviously QoS, Security have been mentioned above, examples might include:

• Availability (i.e. mean time between failure)
• Operational window (is there ever a time when the service is not expected to be used?)
• Response time (how quickly does the service need to respond to a request)
• Peak throughput (how many requests for the service can arrive per unit of time – e.g. per second, per minute, per hour)