Using the COR Pattern in J2EE
By combining COR with another popular pattern, the Command pattern, you can facilitate efficient, extensible component coordination (see Figure 2
). Subsystems do not reference each other directly. Rather, they request services via the COR Manager using commands. The COR Manager manages a set of services, routing commands to those services, managing transactions and remote boundaries, and returning replies. Requests may be modeled as Command data-transfer objects. Think of a command as a request for a service to perform a function or return data. A Service is a business-focused component (Java class) capable of processing one or more commands. In this approach, the COR Manager passes the command along the chain of services until the request elicits a reply. The service returns the results of the requested operation inside the command request and the command is passed back to the caller.
The COR Manager/Dispatcher transparently takes care of local or remote command execution and provides transaction demarcation. This coarse-grained control means that you don't have to worry about transactions or remote and locale interfaces initially. Business logic can be deployed as COR services and Plain Old Java Objects (POJOS), since the COR Manager handles your transaction rollbacks and commits for you.
Transactions on Demand
Your command can specify at run-time whether it will be executed locally in the requester's JVM or remotely inside the J2EE server. Some business operations (such as DBMS queries) do not necessarily require transactions. Such functions may be performed safely in the servlet tier. For commands requiring transactions (e.g., commands that involve database updates), the COR Manager routes the command via a Session Bean. The COR Session Bean is deployed using TX_REQUIRED. This guarantees that the command will be executed atomically; that is in one transaction.