Discussions

News: Core J2EE Patterns Second Edition Released

  1. In this second edition, they have added 6 more J2EE design patterns in addition to the 15 patterns covered in first edition.

    The new patterns are: Context Object, Application Controller, Application Service, Business Object, Domain Store, Web Service Broker.

    Note that all the patterns have been fully revised and updated, including new implementation strategies with new code samples.

    Checkout the book here.

    What do you think of the new edition / new patterns?

    Threaded Messages (12)

  2. I went to the talk at Java One and was pretty happy to see that they had gotten together with Martin Fowler to discuss the patterns in the book.

    His book on Patterns is extremely good and although not J2EE based it is well worth a read.

    http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/qid=1055780661/sr=8-1/ref=sr_8_1/102-6215672-6310528?v=glance&s=books&n=507846

    David
  3. Download PDF file[ Go to top ]

    Will it be available to free downaload too ?
    Thanks,
    William.
  4. Download PDF file[ Go to top ]

    Not that I am aware off
  5. You know I am in India,I could not get it.
    So does anyone can give me a copy of the ebook about it?
    My Email:wprusty@fescomail.net
  6. In one of the sessions I went to, I'm pretty sure the speakers said that the new patterns would be documented alongside the existing ones on java.sun.com.

    Simon
     - blog
  7. PDF Download[ Go to top ]

    I thought I remember they said a free PDF download would be made available shortly after the conference.

    Mark
  8. Context Object is a great pattern. Definitely something I should be more disciplined about applying to my code.

    Application Service is a pattern that I have found very useful for MDB's, not so much for SLSB's. For an MDB the onMessage() method has a clearly defined responsibility, parsing the JMS Message object to retrieve the application data that will be passed into the Application Service method.

    But when I have attempted to apply Application Service to session facades, I just end up with a bunch of code that looks like this:

    public ResultObject facadeMethod1( String arg1 )
    {
      return ServiceObject.serviceMethod1( arg1 );
    }

    public ResultObject facadeMethod2( String arg1 )
    {
      return ServiceObject.serviceMethod2( arg1 );
    }

    ...and so on. Since the facade now performs no useful function, it ends up reducing the readability and maintainability of my code, and I just end up refactoring the Application Service into the Session Facade.

    The article claims this is a no-no, because "the business logic potentially gets duplicated among different facades." In practice, I have never found this to be a problem, since I refactor the facades as aggressively as I refactor code at the other tiers.

    The other argument I have heard against this sort of arrangement is that I have now bound my service logic too tightly to the Session Bean component model. But all in all, SLSB is a pretty lightweight component model, and converting a SLSB to a POJO is a pretty trivial task. With a refactoring IDE, I could do a few hundred of them in a couple of hours if I had to. To me, that's a small potential price to pay to improve my code readability now.

    What experiences have others had with this pattern?
  9. The Application Service pattern looks very similar to the 'Mediator' pattern (from GoF).
    The Mediator defines an object(service) that encapsulates how a set of objects interact. It promotes loose coupling by keeping objects from referring to each other explicitly and lets you vary their interaction independently.
    Any thoughts.
    Genri
  10. the intent of the Application Service pattern is not to have facades do nothing at all, it is to provide another layer of granularity in composing complex applications.

    If you use facades on top of a domain model, you have no place to structure reusable fucntionality that operates on multiple objects.

    basically, functionality that operates on multiple objects or object types typically should not be placed in the domain model (for various reasons). At the same time, if you include this functionality directly into a facade, it is not reusable in other use cases.

    Actually, i think this pattern fills a critical missing piece of J2EE structural architecture for large, complex projects.
  11. Worth Buying?[ Go to top ]

    I know that his was the top seller at JavaOne this year and was wondering if anyone has had a chance to read it yet. Is the second edition worth buying if I own the first edition already?

    -rjm
  12. Worth Buying?[ Go to top ]

    It'd be great if publisher could provide discount for those ppl that already got the first edition...
  13. Is it possible to download this document from web?