Everything is a service

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

  • Inventory at http://inventory.mycompany.local
    • /SKU# - GET current stock level for SKU#, PUT to reset stock level for SKU#, DELETE to remove SKU#
    • /SKU#/Reservations - GET list of reservations on stock for SKU#, POST new reservation with CustomerID, DELETE to cancel a reservation
    • /SKU#/Demands - GET list of stock demands (withdrawals from inventory), POST a new demand with PO#
  • Accounting at http://accounting.mycompany.local
    • /Accounts/Account# - GET outstanding balance for Account#, POST a ledger entry to Account#, PUT an update to a ledger entry, DELETE a ledger entry
  • Orders-2-Cash at http://orders.mycompany.local
    • / - GET (with parameters) to query for orders, POST new order
    • /Order# - GET details of Order#, POST new line items, PUT changes to order, DELETE to cancel Order#
  • CRM at http://crm.mycompany.local
    • / - GET (with parameters) to query for customers, POST new customer
    • /Customer# - GET name and address of customer, PUT change of name or address
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.