Browse DevX
Sign up for e-mail newsletters from DevX


The COR Pattern Puts Your J2EE Development on the Fast Track : Page 2

Find out how the "Chain Of Responsibility" pattern can rein in your beans and facades to meet evolving business requirements. Route client requests transparently to EJB server components without hardwiring client/server interactions or worrying about low-level plumbing issues.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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.

Figure 2: Using COR in J2EE

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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date