Sponsored Links
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.
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.
architectures serviceBy Anonymous on November 10, 2009, 5:37 amI like that you explain the facade & service dependency and if the one is needed.
Reply | Read entire comment
hardBy Anonymous on September 14, 2009, 1:04 pmI need to read more articles to understand, it's hard, thanks.
Reply | Read entire comment
hiBy Anonymous on September 8, 2009, 6:22 amtest
Reply | Read entire comment
More ExamplesBy Adam-bien.com on July 2, 2009, 11:53 amHi, I'm aggregating some examples at: http://kenai.com/projects/javaee-patterns/ I'm going to check in several projects next time. And my book is out as well:...
Reply | Read entire comment
I really never knew much about SOAs, thanks for the well writtenBy MMO on July 2, 2009, 3:35 amI really never knew much about SOAs, thanks for the well written article. You're one of my favorite authors on Javaworld :)
Reply | Read entire comment
View all comments