Library tutorials & articles
Building a Web Service - Start with the Design
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 sit...
- Introduction
- Methods Exposed
- Issues to Ponder
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.
Related articles
Related discussion
-
Error Capture
by Slicksim (4 replies)
-
MOS Protocol - Anyone used it?
by alexnavarro38 (5 replies)
-
AJAX: SimpleWebServices is not defined
by Freon22 (2 replies)
-
Read HSQLDB data into a webpage
by joe90 (3 replies)
-
Dynamically Named Web Services
by dgiard (0 replies)
Related podcasts
-
Java Posse #202 - Newscast for Aug 22nd 2008
Newcast for August 22nd, 2008Fully formatted shownotes can always be found at http://javaposse.com Sadly, Java does not run on the Mars LanderThe Golden Gate Project http://research.sun.com/projects/goldengate/Space surveillance radar http://www.sun.com/aboutsun/pr/2008-04/sunflash Google has r...
This was a great tutorial as my basic doubts got cleared on reading your Article.It was an excellent one.Waiting for more like that
Good luck
This thread is for discussions of Building a Web Service - Start with the Design.