|
|
Sponsored Links
-
Speed-up HPC Grid Apps - FREE Download
FREE Download 1- 13 Distributed caching eliminates data bottlenecks. ScaleOut StateServer®
Lean service architectures with Java EE 6
Elements and patterns of a lean SOA
- Feedback
- Discuss
Although Java EE 6 is far less complex than previous platform versions, it can still be misused to create exaggerated and bloated architectures. In this article, Adam Bien delineates the essential ingredients of a lean service-oriented architecture (SOA), then explains how to implement it without sacrificing maintainability. Level: Intermediate
The complexity and bloat often associated with Java EE are largely due to the inherent complexity of distributed computing; otherwise, the platform is surprisingly simple. As I discussed in my last article for JavaWorld, Enterprise JavaBeans (EJB) 3.1 actually consists of annotated classes and interfaces that are even leaner than classic POJOs; it would be hard to find anything more to simplify. Nonetheless, (mis)use of Java EE can lead to bloated and overstated architectures. In this article, I discuss the essential ingredients of a lean service-oriented architecture (SOA), then explain how to implement one in Java EE without compromising maintainability. I'll start by describing aspects of SOA implementation that lend themselves to procedural programming, then discuss domain-driven (aka object-oriented) design.
SOA: The essential ingredients
The crucial artifact in any SOA is an exposed service. A service can be considered as a contract with significant business
value. A clear relationship should exist between the service contract and a business requirement, a use case, or even a user
story. A service can be realized as a single action or a set of cohesive actions. For example, an OrderService might comprise a single action that performs the actual order, or a group of related operations that also include canceling
the order and receiving the order status. An SOA does not reveal any details about how a service must be implemented; it aims
for services to be technology- and even location-agnostic.
SOA principles can be mapped to Java EE artifacts. The most important ingredients in a Java-based SOA implementation are interfaces and packages. Everything else is only a refinement, or design. Only one artifact in the language -- a plain Java interface -- meets the requirements of a service contract. It is often used to decouple the client from the service implementation. It can also be used to expose the functionality of a component.
Component based design (CBD) is SOA's evolutionary predecessor. Component contracts are comparable to SOA's services, except for their heavier dependence on particular technology and general lack of operations-related metadata -- such as service-level agreements (SLAs) -- or strong governance principles. A component is built on the maximal cohesion, minimal coupling principle. A component should be highly independent of other components, and the implementation should consist of related (cohesive) elements. In a Java EE SOA implementation, a component is a Java package with these strong semantics. The package's functionality is exposed with a single interface, or in rare cases a few interfaces.
- Feedback
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.
Sponsored Links
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2010 Infoworld, Inc. All rights reserved.
goodBy Choiyex on January 29, 2010, 6:17 amhow do you introduce this to newbies like me?
Reply | Read entire comment
Generic DAO is not developer friendlyBy Anonymous on January 29, 2010, 2:00 amI feel that we should have specific DAO instead of Generic DAOs. With specific DAOs such as OrderDAO, BidDAO, CustomerDAO. This is more convenient to the service...
Reply | Read entire comment
Agreed!By Anonymous on December 16, 2009, 2:12 pm"No single approach fits all apps" - totally agreed! But there are some _proven_ practices that make your code more maintainable and testable in the long run. This...
Reply | Read entire comment
DDD is not the end all solution...By Anonymous on December 15, 2009, 4:19 pmIn response to the "lol" commenter, I'd just like to point out that no single approach to architecture fits for all applications. This includes "Domain Driven"...
Reply | Read entire comment
lol :)By Anonymous on December 11, 2009, 8:47 am"Since services implement the actual business logic, and the facade cares about the cross-cutting concerns, there is no more functionality left to be implemented...
Reply | Read entire comment
View all comments