Understanding Service and Resource Oriented Architecture - Sling, the JCR, and AEM / CQ5

Real mastery of AEM requires understanding not just the technical frameworks at the code or API level but also the conceptual level.

At the core, AEM can be seen as two approaches layered on top of one another: A service/component-oriented framework with OSGI and a resource-oriented framework in Sling.
Service-Oriented Architecture

The OSGI framework is an enterprise-grade services oriented architecture framework. I won’t belabor the point when Wikipedia has a great article going over service-oriented architecture.

The short version is that in SOA you think about “making available” certain behaviors or functions in the form of an API. Services can, of course, make use of other services. SOA is an approach to the general OOP concept of encapsulation. Each service should be a self-contained (at least from the outside) piece of functionality with clearly defined capabilities, expected inputs, and expected outputs. While in OSGI a service will be represented and managed by a java object, SOA does not necessarily require OOP.

One of the advantages of SOA is that it lends itself to easy de-coupling/loose coupling of functionality. I’ve noticed that if I assign junior developers to develop a service then the service API itself (if not the underlying implementation) is more likely to be well factored and thought out. With SCR annotations building complex behavior out of self-contained services is relatively intuitive and requires a minimum of boilerplate.