1.3 Planning for Interdependence

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:

• Number of web service methods exposed or used

• Frequency of access allowed (e.g., one method call per second at most for methods a( ), b( ), c( ), and one call of method d( ) per minute)

• Expected performance of specific methods

• Time expected to restore service (e.g., if there is a failure, how long until it's fixed?)

• Bandwidth and latency expectations

• Scheduled downtime

• Data management and backup responsibility

• Logging

• Security auditing

Here are some questions to ask yourself:

• What are your internal plans for migration if the service fails?

• What is the involvement of your legal representation in drafting or agreeing to your service agreement?

• What tools or systems will you use to monitor your services? (If you promise to deliver or receive a given level of service, how will you really know?)

• What is the expected level of tech support access? How are users expected to contact support? How long until a response is sent?

• How will minor bug fixes and upgrades be handled? Will users of the web services be able to test their application against a test server before the changes are pushed to the production system?

• How often will new functionality be added? What is the procedure for migrating web service users to new systems?

• How long will session data be preserved? (In other words, if I begin a transaction, how long does the remote system maintain that state data before expiring it?)

• What are the remedies (refunds or credits) if service fails?

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.