News »Browse Articles »
Lean service architectures with Java EE 6
0
Lean service architectures with Java EE 6
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.
Source:
http://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html
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.
Source:
http://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html
