|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Lean service architectures with Java EE 6
Elements and patterns of a lean SOA
Page 4 of 6
- Dumb entities are easier to develop. No domain knowledge is required.
- Anemic JPA entities can be generated more easily. The necessary metadata can be entirely derived from the database. You can just maintain the database, and the existing entities can be safely overwritten by newly generated ones.
- The persistent entities can be detached and transferred to the client. Aside from the classic "lazy loading" challenges, there are no further surprises. The client will only "see" the accessors and will be not able to invoke any business methods.
Thinking about internal structure
I've already identified some key ingredients of a service-oriented component:
- Facade: Provides simplified, centralized access to the component and decouples the client from the concrete services. It is the network and transaction boundary.
- Service: The actual implementation of business logic.
- Domain structure: This is a structure rather than an object. It implements the component's persistence and exposes all of its state to the services, without encapsulation.
You will find these three layers in most components. The component structure manifests itself as internal packages named by
the key ingredients. The ordermgmt component consists of the facade, service, and domain packages, as shown in Figure 2.
Figure 2. Internal component layering with packages
This convention not only standardizes the structure and improves maintainability, but also allows automatic dependency validation with frameworks like JDepend, Checkstyle, Dependometer, SonarJ, or XRadar. You can even perform the validation at build time. If you do, the continuous build would break on violation of defined dependencies. The rules are clearly defined with strict layering: a facade may access a service, and the service a domain object, but not vice versa.
DAOs: Dead or alive?
The original context of a Data Access Object (DAO), as defined in the Core J2EE pattern catalog (the emphasis is mine), is:
Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation.
The motivation for this pattern was the desire to achieve greatest possible decoupling from the concrete realization of the data-store mechanics.
The question to ask is how often you've had a concrete requirement to switch among "relational databases, object-oriented
databases, flat files, and so forth" in a real-world project. In the absence of such a requirement, you should ask yourself
how likely such a replacement of the data store really is. Even if it is likely to happen, data-store abstractions are rather
leaky. JPA's EntityManager is comparable to a domain store and works with managed entities. Other data stores are more likely to use the "per value"
approach and so return a new copy of a persistent entity on every request in a single transaction. This is a huge semantic
difference; with the EntityManger, there's no need to merge attached entities back, whereas it is absolutely necessary in the case of a DAO with data-transfer
objects.
- Feedback
More from JavaWorld
Resources
- "EJB 3: From legacy technology to secret weapon" (Adam Bien, JavaWorld, October 2008) further argues that convention over configuration, annotations, dependency injection, and aspect orientation have made modern EJBs a lean alternative to XML-laden and JAR-heavy frameworks.
- Martin Fowler explains why the Anemic Domain Model is usually suboptimal.
- Explore the EJB 3.1 and JPA 2.0 specifications.
- EJBs are now so lightweight that they beg the question "EJB 3.1 - And Is There Still Room For POJOs?" (Adam Bien's Weblog, January 2009).
- Read "Should JPA Entities Contain Business Logic? ...Why Not?" (Adam Bien's Weblog, February 2009) for a discussion of putting business logic into persistent entities.
- For more on domain structures vs. domain objects, read "12 Tips On JPA Domain Modelling - With Existing Database - Thinking In Structs Not Objects" (Adam Bien's Weblog, February 2009).
- For a broader introduction to JPA and Java-based persistence see the two-part article "Understanding the Java Persistence API" (Aditi Das, JavaWorld, January 2008).
- Read an introduction to robustness diagrams at the Agile Modeling site.
- You'll find legacy J2EE patterns at the Core J2EE Patterns site.
- Interested in the evolution of service-oriented architecture? Visit JavaWorld's SOA & Web services index.
More from JavaWorld
- See the JavaWorld Site Map for a complete listing of research centers focused on client-side, enterprise, and core Java development tools and topics.
- JavaWorld's Java Technology Insider is a podcast series that lets you learn from Java technology experts on your way to work.
- Network World's IT Product Guides offer side-by-side comparison of hundreds of products in over 50 categories.