Building a Web Service - Start with the Design

Issues to Ponder

Before getting into the detailed design of the service, it is important to be aware of some of the potential roadblocks that we might face. That allows us to make sure that our initial design decisions don't take us down a deadend path. The main problem areas that we face are:

Authentication The purpose of authentication is to identify the person who is accessing our web service. This means having the user provide a login id, a password and any other information necessary to validate the credentials. The problem here is determining who (the database, the operating system or both) is responsible for performing the validation.
Authorization Once a person has been allowed into the system, you may have functions that need to be restricted to the responsible personnel. The issues here are more implementation oriented than technical. Along the lines of how we manage and utilize the permission hierarchy.
Encryption Trying to keep prying eyes from viewing and access our service and the information contained within will be behind many of the implementation choices that we make. We need to be aware of the fact that some sensitive information will be transmitted across a public network. As such we should look into what is required to encrypt the data so that it will take more than a casual glance to see it. As well, need to make sure that any important data that we store is protected. In my experience with creating commercial sites, this is one of the more overlooked areas. Mostly because most people don't want to make decisions based on that fact that someone could crack into system to the point where the data is exposed.
Transactions A transaction is a group of functions that must either succeed as a group or all fail. In the client/server world, this is not a difficult thing to accomplish. For the most part, the multiple requests will occur along the same connection to the database. But the stateless nature of the Internet makes this approach impossible. Each web service request stands on its own, so in order to build a transaction containing multiple requests, we must find a way to maintain state that is both flexible (supports all browser types and common user configurations) and fast. Nothing like a challenge to top off our day.

The next few chapters in this series will cover these areas in detail. The biggest problem that we face is that standards about how to address these particular issues are notoriously lacking...er...evolving in the SOAP specifiation. So we're on our own, at least at the moment.

You might also like...

Comments

About the author

Bruce Johnson Canada

I am the owner of a small application development consulting company that specialized in the design and implementation of Internet-based applications. While there are others who can make a web ...

Interested in writing for us? Find out more.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why.”