Architecture: what comes after SOA?

Answer: Web Oriented Architecture (WOA)

What is WOA? The Basic Tenets

• Information in a WOA is represented in the form of resources on the network and are accessed and manipulated via the protocol specified in the URI, typically HTTP.
• Every resource on the network can located via a globally unique address known as a Universal Resource Identifier or URI complying with RFC 3986.
• Resources are manipulated by HTTP verbs (GET, PUT, POST, DELETE) using a technique known as Representational State Transfer or REST.
• Manipulation of network resources is performed solely by components on the network (essentially browsers and other Web servers).
• Access to resources must be layered and not require more than local knowledge of the network.
• It is the responsibility of the components to understand the representations and valid state transitions of the resources they manipulate.
• The service contract of WOA resources is implicit; it's the representation that is received.
• WOA resources contain embedded URIs that build a larger network of granular representative state (i.e. order resources contain URLs to inventory resources).
• WOA embodies Thomas Erl's essential Principles of SOA, though in often unexpected ways (such as having a contract, albeit implicit).

Source: http://hinchcliffe.org/archive/2008/02/27/16617.aspx

Another depiction of what WOA is (will be):

Differences between SOA vs WOA:

One of the more helpful ways of understanding WOA is to see how it's different than SOA since there is considerable overlap between these two models of using the network to integrate, interoperate, and collaborate. While both approaches leverage HTTP, self-describing data formats such as XML, are concerned about the use of open standards, and can be used to build systems of arbitrary complexity, much of the similarity ends there. Here are some of the most significant contrasts between the two approaches:

• SOAs tend to have a small and well-defined set of endpoints through which many types of data and data instances can pass. WOAs tend to have a very large and open-ended number of endpoints; one for each individual resource. Not an endpoint for each type of resource, but a URI-identified endpoint for each and every resource instance.
• Traditional SOA builds a messaging layer above HTTP using SOAP and providing unique and sometimes prohibitive constraints to the Web developer, while WOA finds HTTP and related transfer mechanisms to be the ideal layer of abstraction for most applications.
• SOA was designed from the top-down by vendors to be tool friendly, while WOA was emerged form the bottom up from the Web naturally and has the best support in simple procedural code and an XML parser.
• SOA uses WS-Security and other sophisticated standards for security, while WOA tends to just use HTTPS.
• SOA must contend with the vagaries of XML Schemas for service contracts, while WOA largely ignores the issue and lets Web services naturally represent whatever formats are desired.
• Traditional SOA is fairly cumbersome to consume in the browser and in mashups while WOA is extremely easy to consume just about anywhere