Saturday 25 August 2007

QoS requirements for web services development project

Many a times a question comes up about which Quality-of-Service (QoS) requirements should be gathered for web services development project. Let me share my answer to this question.

QoS requirements are not so much different from the non-functional requirements that we gather for any typical software development project. Let me list them down with some explanation:
  • Availability in terms of probability of service being available
  • Accessibility in terms of probability of success in accessing the service
  • Performance in terms of throughput (number of successful service requests made per given time period) and latency (aka response time)
  • Reliability in terms of failures per give time period
  • Security (this requires a detailed explanation as given below)
Security Requirements come as a top requirement for web services. I
have come across many people who believe that web services are
inherently insecure. It's far from true! With a release of WS-Security
specification from OASIS and subsequently release of Basic Security
Profile from WS-I should help eradicate this wrong perception. Now, gathering security requirements for web services is a tricky job. Everybody wants to have web services to be
as much secure as possible and no less. But then there are trade-offs
to be considered with other QoS requirements, particularly the
performance requirements. So it makes sense to ask for only essential
security requirements. Further the security requirements for web
services should be broken down into the following:

  • Authentication
  • Authorization
  • Message Integrity
  • Non-repudiation

A note should be made that all security requirements except
non-repudiation requirements can be met by using the WS-Security
specifications. If there are non-repudiation requirements then a
non-standard way will need to be adopted.

A good news is that service development per se need not take into account these QoS requirements. These QoS requirements can very well be externalized and can be handled independent of service implementation. However, if there are some very peculiar or critical QoS requirements then the high-level design of the service implementation needs to get influenced.

Any comments?

No comments: