Here I make good on my previous promise to define a place in architecture for CarrierWave.
In short, if you could break up an orchestrated enterprise into one pattern, it would look alot like MVC. CarrierWave is the container for the Model, the 'system of record'.
Here's the long of it.
CarrierWave is a container for adaptive object models.
Why adaptive instead of the normal kind?
Well, why bother with CarrierWave if you are going to build brittle abstractions.
With brittle abstractions you are going to have brittle interfaces, and how better to employ brittle interfaces than to build a system using EJB interfaces.
Consider the concepts 'system of record' and 'system of process' (and 'system of decision').
You may have data all over your enterprise, but one location is the system of record for a given type (SAP for purchase orders, for example). Of course this leads to islands of data that integration vendors have been trying to solve by offering tools for integration.
Functions and rules have been historically co-located with their data. For example, a bug tracking/trouble ticketing system knows who to contact in case of an escalation in priority of an issue.
Now at the dawn of service orchestration and choreography, we are seeing systems responsible for managing these processes externally. Instead of one application storing bugs and sending events on rules, we will see a system of record for bugs and issues, and a system of process for the event notification rules.
CarrierWave would be used to build a system of record.
The premise here is that OO principles allow developers to create and manage entities with complex relationships with less effort (than one would with just a SQL database).
Consider:
JMX container + CarrierWave + POJO + persistence
Where 'persistence' is JDO, Hibernate, or whatever.
CarrierWave exposes both graphs and services (or invocable actions on the graphs).
Either/Both a vertical and horizontal client (JSP or SWING) would be used by humans to make changes to the object relationships and values.
The services would be exposed on the back-end to the ESB or BPMS (Business Process Management System).
That is, systems need to integrate with humans and with each other. Process rules live in the system of process and the data lives in the system of record.
Typically RDBMS's are great for systems of record without a layer of absraction.
But when/if a system will benefit from OO (POJO) for whatever reason, you are going to want a container that exposes interfaces almost as expressive as a RDMS (a POJOMS).
Leave a comment