Problem: Data storage mechanisms are frequently updated to handle scaling, security, cost needs, etc. Certain aspects of the operation need to be scaled or changed more than others, and developers are having difficulty comprehending the entire system as it grows in complexity.
Pattern: Major components of the system are exposed to each other as REST services supporting GET, POST, PUT and DELETE for a small number of relevant resources. Underlying storage models are orthogonal to the service interfaces
Discussion: Service Oriented Architecture (SOA) treats major functions of a system (also called business domains) as either a set of services (SOAP style), or as a set of resources (REST style) that encode all of their data in XML. The above example describes a simple REST architecture for a mail-order company, but the approach can be adapted to any kind of large system. What unifies them is a standard way of referring to entities and resources (by URI) as well as well-documented interfaces. Those resources are then served to client applications over standard HTTP, using the four major HTTP commands (or verbs): GET, POST, PUT and DELETE.
The point of using HTTP, a limited set of verbs, URIs (or URNs) and XML is to get away from protocols and encodings that would tie a service to a particular platform, so that developers could throw-away and re-implement a service on a better foundation without breaking all of the client applications.
By contrast, a system that used a query language native to a particular SQL DBM and a binary format peculiar to one kind of language or platform would be tied to that platform, even if it couldn't scale to fit new needs.
The services themselves could be written from scratch to speak their REST interface natively, or they could be wrappers around an existing component. In fact, building wrappers is the easiest way to get started when you already have a lot of existing software and don't want to re-write everything over from scratch.