This is a few months old, but Werner Vogels republishes the Amazon.com Shareholder Letter. A summary of how the quintessential 21st century company views its competitive advantage:

1. Service Oriented Architecture
2. Distributed state management
3. Decision management

Regarding Service Orientation:

Our technologies are almost exclusively implemented as services: bits of logic that encapsulate the data they operate on and provide hardened interfaces as the only way to access their functionality. This approach reduces side effects and allows services to evolve at their own pace without impacting the other components of the overall system. Service-oriented architecture — or SOA — is the fundamental building abstraction for Amazon technologies. Thanks to a thoughtful and far-sighted team of engineers and architects, this approach was applied at Amazon long before SOA became a buzzword in the industry. Our e-commerce platform is composed of a federation of hundreds of software services that work in concert to deliver functionality ranging from recommendations to order fulfillment to inventory tracking. For example, to construct a product detail page for a customer visiting Amazon.com, our software calls on between 200 and 300 services to present a highly personalized experience for that customer.

Service oriented architecture centres heavily on the concepts of service providers and consumers. It’s easy with request/reply web services to fall into the lazy habit of thinking of the provider as being the “server” side of the request/reply interaction. The consumer requests information from the provider, which the provider – naturally – provides! But this is wrong.

What happens in an N-tier architecture where there may be many “servers” in the stack? What happens with JMS-based services using a one-way message exchange pattern (MEP)? If one application is using SOAP/JMS to send a message to another application, which is the consumer and which is the provider?

On the face of it, you might say the “sender” is the “provider” and the “receiver” is the “consumer”, but that ignores the fact that there are two types of one-way MEP – “one-way out” and “one-way in.” (Actually there are many types of MEP and they differ slightly depending on the version of WSDL you use, see the WSDL standard for more confusing details).

We really need to look beyond the technology to find the answer and the Web Services Glossary gives a clue. It splits the model into an “agent” (software or process) that operates on behalf of an “entity” (person or organization). Specifically a Provider Agent and a Requester Agent operate on behalf of a Provider Entity and a Requestor Entity respectively.

So the “provider” of a Web service is basically the person or organization responsible for that service. It is the person or organization that you contact to get permission to use the service, or obtain the WSDL, or give your credit card details for charging.

An example will help to clarify the relationship between provider and consumer in one-way MEPs. Suppose a service provides alert notifications. Multiple consumers subscribe to this service to receive alerts on subjects that are important to them. At the messaging level, the provider puts a message onto a JMS Topic and multiple consumers receive the message. This is a “one-way out” MEP.

Another service might be a central audit service where multiple agents send messages via a JMS Queue representing steps in a distributed process. This is commonly used for “track and trace” in distributed workflows. In this case, the message senders are not responsible for the audit system, they are “users” or “consumers” of the service. This is a “one-way in” MEP.

In summary, service providers and consumers can be confusing in an N-tier architecture or with one-way MEPs. The fundamental consideration is more “business” than “technical”. Who is the organization or person responsible for the service? Then the way consumers interact with them determines the MEP that is being used.

In a recent comment on my Architectural Characteristics posts, Andy astutely observes that I may be “shoe-horning”. By this I assume he means that I’m taking a large and rather lumpy concept and trying to squeeze it into a smaller and more uniformly shaped container while risking some distortion in the process. I’ll admit that in this respect I’m probably guilty as charged.

But I should clarify my purpose in doing this. I’m trying to cut back the various architectural styles under consideration to a simpler form where the essential characteristics can be discerned without confusion from some other non-essential characteristics. So rather than shoehorning, I’m trying to setup a strawman model which can be used as a starting point for discussion. Or maybe like a physicist I’m trying to model a very complex phenomenon using linear approximations which explain the broad outlines of the phenomenon at the risk of falling short on some of the details.

To extend this latter metaphor, I don’t think it is too much of a stretch to say that the architectural styles I’m considering could be likened to “fundamental” architectural styles and that real-world architectures could be viewed as “superpositions” of those fundamental architectures.

If we consider the simplified forms of EAI and SOA that I describe, each style falls short of representing a real world architecture, but the upside is that the EAI and SOA styles as I describe them are distinct and easily differentiated. So we have a model which provides a way of distinguishing between different styles (via the characteristics I’ve discussed) but falls short of exactly matching a “real-world” architecure.

If we look at any real-world architecture in recent years, I think we can see a superposition of EAI and SOA concepts. This probably reflects an evolutionary path between the two styles. EAI as practiced in the early noughties had already developed the idea of a normalised data model and technology independent interfaces. These were not standardized, but some of the characteristics of SOA were apparent in what was then called EAI.

Similarly, EAI was not always about data integration. There was (and is) a distinction between data integration and process integration. EAI techniques could be used to orchestrate processes across multiple systems. This is even closer to the concept of SOA which has at its core the notion of an independent process layer seperate from the service layer.

Even if we don’t superpose EAI and SOA into one solution, there are still legitimate ways in which EAI, SOA and EDA coexist within any particular architecture. We can easily imagine a solution in which a business process is orchestrated via SOA services, reference data is synchronised using EAI and overall process state is monitored using EDA techniques such as Event Processing.

So real-world solution architectures exhibit some overlap between the different architectural styles – EAI, SOA and EDA. Some of this is due to evolutionary legacies, or due to plain-old confusion between the different styles (e.g. JABOWS as really being EAI). Some of it is also due to legitimate mixing of different styles for different aspects of a solution.

I think that real-world architectures can benefit from seperating out the “essence” of each architectural style and being explicit about how those styles are being applied. Reducing architectural styles to simplified forms clarifies the stucture of a real-world architecture. Not very different from Design Patterns, really.

Taking a leaf from the Agile playbook, a group of SOA thought leaders has put together the SOA Manifesto, a succinct list of SOA principles and preferences to guide Service Oriented Architecture. Great work!

(I could comment further, but it speaks for itself).

Go visit and find out.

My last post explored some distinguishing characteristics of three common architectural styles in an attempt to understand better how they differ and therefore how they may apply in different contexts. A fourth distinguishing characteristic of these architectural styles is the way in which state is managed during the execution of a business process.

There are three aspects of state that I want to consider:

• Management – how state change is initiated or managed through a business process.
• Monitoring – how state is monitored or accessed or derived during the execution of a business process.
• Consistency – how state is made consistent across different systems involved in a business process.

A summary of the state characteristics of the different architectural styles is listed in the following table along with the other characteristics discussed in my last post.

In EAI, state is managed within one application and then synchronised to other applications, usually after the business process has completed. This means that in some cases state may be inconsistent across the organisation or its systems. That may or may not be a problem (see ‘Eventually Consistent‘) but is a common side effect when a business process is executed within one system rather than across systems in an independent process layer. During the execution of an EAI process, there is often no monitoring of the state. I.e. the process may simply replicate data changes to other systems without explicily tracking state. A limited form of state monitoring may exist in the sense that the local application or associated middleware may check the status of data synchronization and error out in the event of an exception. I refer to this as ‘local’ state monitoring. So under the EAI architectural style, state is managed locally, monitored locally (if at all) and is eventually consistent.

Under SOA, the driver of a business process is BPM orchestration in an independent process layer. In this case, we can say that state is managed centrally (in the BPM layer) and monitored centrally (also in the BPM layer). State in end-systems is updated progressively through the business process (via service calls) and so we could say that state is ‘progressively’ consistent as opposed to ‘eventually’ consistent.

Under EDA, there is no central or even local management of state. Instead, events signify distributed actions which together may be used to infer the state of a system. To the extent that any ‘management’ occurs, we could say that state is managed in a distributed fashion – one or more agents each acting on their own. Perhaps  it is more accurate to say that state is manifested globally. Converesely, state is monitored centrally within an Event Processing (CEP) layer which correlates events to infer system state. Under EDA, state is progressively consistent because the system is progressively reacting to events which are a by-product of a hidden or implicit business process.