Maintenance of service development is the last phase in the software lifecycle. The maintenance phase deals with changes that need to be made to the service over its lifetime because of new or changed requirements.
Dealing with change is particularly difficult in service-oriented architecture, because the interface contract initially agreed upon by the service producer and the consumer must be maintained throughout the service's life. Unless both producer and consumer agree to a contract revision, the contract is in force. It is necessary to provide new features and interfaces for new clients while maintaining previous contracts. A change may require a change to the request message. If this is necessary, the service must support a new contract for the slightly different service call.
Sometimes the request does not require a change, but the response is different. If this is the case, the service must sometimes use information about the caller of the service to determine which response to deliver. The best way to handle interface changes is to include the version of the interface the caller is requesting in the request message. In either case, handling interface changes is difficult.
The goal of managing these changes is to support new requirements for the service while maintaining the service's integrity. Making a change to a service is the same as for any software artifact. The process is described in the IEEE Maintenance Process Activities diagram, shown in Figure 3.9 (SWEBOK 2002).
Over the life of a service, the cost of maintenance will greatly outpace the cost of initial implementation. Therefore, it is necessary to have a process to ensure that the service's integrity is not compromised and that new requirements are supported in a timely fashion.