On BA Chapter Five (ROA architectures)

C. Brancusi: "Architecture is inhabited sculpture; we are forced to endure the choices that we make for quite some time".

In this fifth chapter, the authors not only describe another “beautiful” architecture, the resource-oriented architecture (ROA) and its close friend the Web, but also advocate a change in the way we should look at and design software architectures, that should provide us with more benefits in the long term.

With this new approach, the accent is put on designing architectures by focusing on information as a first-class citizen, as opposed to getting tied into specific bindings usually enforced by popular technologies (e.g. J2EE, .NET, SOAP), an approach that makes changes almost impossible without breaking existing clients. Their belief is that by connecting systems following the information-centric model, the user can only gain in efficiency, simplicity and flexibility, features that made the Web one of the most popular architectures.

In resource-oriented style, clients issue logical request for named resources, which are then resolved and transferred back to the requestor in one form or another by a resource oriented engine. Resolving the named request may be an action as executing a database query or in the case of RESTful web services, a bit of functionality in charge of managing information.

Resilience to changes is one of the notable features of the Web that is also inherited by ROA. Existing clients are not affected by changes performed on the resource oriented engine that are meant to accommodate new clients. This behavior is achieved by having resources retain their identity (e.g. URLs) and by picking the physical representation of the resource within the context of resolving a request. One other important concern addressed by ROA is obviously security. While many existing SOA restrict access to services based on identity or role, they rarely restrict access to data flowing through these services. In contrast to this, by making a clear distinction between identifying resources and resolving them for different contexts, ROA enforces security directly on the data. Information is passed across application boundaries as references and each context provides enough information for the ROA engine to decide whether or not to produce the information for a particular client. Last but not least, since it leverages on Web/REST, ROA is also achieving separation of concerns with all the abstractions describing the interaction with the clients, by isolating the resources, the actions performed by the clients on the resources and the representation of the resources when returned to the clients.

One last word on REST vs. SOAP: even though they are often compared when both perceived as means for manipulating information, they are essentially different. While SOAP is only a technology for invoking behavior, REST is all about managing information, not necessarily by invoking arbitrary behavior through URLs. Feeling that the CRUD-pattern implemented in Web based architectures by the four HTTP verbs is not enough, is a clear indication the architecture is focused on managing behavior rather than information.