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.
Comments