|< Day Day Up >|
The pundits, purveyors, and snake oil salesmen of web services describe a world in which nearly every process is handled seamlessly by a variety of different web service technologies and options. Automated agents, interconnected by wired and wireless technologies, will use web services to solve global economic crises, find you the best deal on toasters, and restock your refrigerator with fresh milk before you've even noticed that the expiration date has passed.
This deeply interconnected world assumes that the underlying web services work very well. In particular, such broad-reaching automation leads to basic questions about responsibilities. For example, let's say that an error leads to your refrigerator ordering 500 gallons of milk or none at all. Where did the problem occur? This issue affects you both as a user and provider of web services.
To manage questions of reliability, you must determine what sort of uptime you provide (or demand) for your web services. How do you characterize the performance and security restrictions? What are the implications of a service failure?
It can be helpful to build a brief worksheet when working with web services that can be used as a check list. It can include:
Here are some questions to ask yourself:
Notice that there is no mention of the programming language used, the application server, the database, the server hardware all critical to the internal development conversation, but (in theory, at least) not part of the overall web services conversation between two different organizations.
Because of the complexities of interdependence, when you're working with web services, you need at least a basic understanding of the underlying networking principles, which are discussed in the next chapter.
|< Day Day Up >|