Fulfilling nonfunctional requirements with patterns and best practices

When applications are developed properly using patterns and best practices, nonfunctional requirements tend to be an unintended benefit.

One of the great benefits of developing software properly the first time, using proven patterns and sound best practices, is the fact that while addressing the core requirements in the software, many of the nonfunctional requirements get preliminarily addressed as well. 

When applications are properly designed using patterns and best practices, many nonfunctional requirements take care of themselves.

Randall Nagy, Principle Engineer with Soft9000

A rocket scientist once patiently explained to a new software developer why a precise starting point is important. Pointing to an imaginary celestial body he said "even one degree of error will make us completely miss our target." In a like manner, someone else added, "when we do things exactly right, even unexpected things just seem to work out properly." And so it is with service orientation and security: when we design our services right, nonfunctional requirements, like security, often take care of themselves.

Unintended, yet beneficial, consequences

A standard best practice for service oriented software delivery is to provide multiple ways of representing a response unit to clients. Interestingly, this best-practice, which is intended to improve the quality of web service delivery, also has the unintended benefit of improving the security of the applications we develop.

Imagine application security from the point of view of a potential miscreant: understand that designing a simple, single, stateless request or response unit, classically call an RU, easily provides an all-in-one cypher to would be system attackers. Things can even get worse when a single-page key is used. While the interception of 100 HTTPS RUs might be tough to break, having 1,000,000 can make certificate reverse-engineering a lot easier.

Indeed, the first rule of cypher-cracking is to have common, recurring patterns to look for. Therefore, sending the exact same metadata to a requests over and over again might be something to avoid. All one needs to break a cypher, after all, are enough common keywords to look for in something like a anticipated, standard, SOAP envelope. Put enough of those tokens in the exact same location each time, and one might as well not encrypt anything at all.

So even from a security standpoint, providing two ways of representing an RU is far better than providing only one. Therefore, the practice of providing more than two ways of representing any single service request, even to the exact same service, should be considered a security best-practice. Providing multiple certificates does not harm anything, except perhaps caching and performance, either. In many ways, providing support for multiple, varying RU encodings is merely a simple extension of proper service version control (SVC).

Indeed, after we open ourselves to the prospect of submitting many RU versions to the same service, over time data transmission tends to become a tad more secure, demonstrating that when applications are properly designed using patterns and best practices, many nonfunctional requirements will take care of themselves.

Let us know about your strategies for handling nonfunctional requirements.

Dig Deeper on Software development techniques and Agile methodologies

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.