Lean Service Architectures with Java EE 6


News: Lean Service Architectures with Java EE 6

  1. Lean Service Architectures with Java EE 6 (1 messages)

    Although Java EE 6 is far less complex than previous platform versions, it can still be misused to create exaggerated and bloated architectures, writes Adam Bien, as he delineates the essential ingredients of a lean service-oriented architecture (SOA), then explains how to implement it without sacrificing maintainability.
    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. 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.
    This detailed, step-by-step tutorial guides you through a complete service implementation using JEE 6 that's mean, lean, and fast.
  2. Several issues[ Go to top ]

    I have several issues with this article. First of all, the title is misleading. This article really focuses on the design of an individual service. It does not address leanness at the architecture level. If you really think about it, the bloat in SOA comes from what happens between the consumer and provider: serialization, data/protocol transformation, message enrichment, application of quality characteristics etc. And from how services are defined, described, stored, retrieved and developed. This article doesn't go into any of that. So, it should really be titled "Lean service design with Java EE 6." Another problem is right here
    A service resides behind the facade, so it can never be accessed directly by the UI or other presentation components. A service is stateless and can be only called by the facade.
    Looks like the author is confusing the atomic functions e.g. computePrice, computeVat etc. with a service. The quoted statement violates the very definition of the service, which author gives as,
    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,
    You don't want to hide a service and you do want to make it accessible to any client. Now, about the service's reliance on facade and all the features that come with it - transactions in this case. To me, a service should be as much self contained as possible. You may have to [re]use the service in multiple situations. If the service always inherits REQUIRES_NEW via its facade, how would it participate in, say, WS-AT transactions? To change this transaction behavior, now you have to change the source code or redeploy the service with a different configuration. When you do that, you have to worry about the existing clients that may have been relying on the transactional behavior provided by the facade. Finally, it would have helped if author had clarified what he meant by lean. Lean from development perspective? Then yes, Java EE 6 does have some value there. But that too applies only in the simplest scenarios. The moment you need things like security or need to use web service headers etc. you need to generate and maintain WSDL. Just my $0.02 C http://ChintnRajyaguru.com