Domain Logic & Distribution Patterns Chapters by Martin Fowler

Discussions

News: Domain Logic & Distribution Patterns Chapters by Martin Fowler

  1. Two chapters from Martin Fowler's 'Patterns of Enterprise Application Architecture' have been posted. 'Domain Model Patterns' looks at the Transaction Script, Domain Model, Table Module, and Service Layer patterns. 'Distribution Patterns' looks at the Remote Facade, and the Data Transfer Object. The usage of each pattern is explained through sample problems and code examples.

    Read Domain Logic and Distribution Patterns

    Threaded Messages (20)

  2. The book is great and it’s a good reading. If only more people would consider the fist rule of distributed programming by Fowler – "do not distribute"...

    Regards,
    Nikita Ivanov.
    Fitech Labs.
  3. do not distribute...[ Go to top ]

    I would prefer "do not distribute phisically"... but "distribute logically"... ;-)

    Cheers,
    Lofi.
  4. Available online[ Go to top ]

    On a lark I checked http://safari.oreilly.com to see if they had this book and they did: http://safari.oreilly.com/0321127420 .

    I'll definitely be adding it to my bookshelf. I don't know about anyone else but safari is like crack for me.

    In browsing the book I noticed a similarity to other Fowler books: concepts are explained with good examples without talking down to the reader.
  5. I am a big fan of Martin Fowler and this book is great. The whole discussion on domain models and database mapping strategies is very well done. He also talks about a classic discussion for me which is "Where do you put the business logic?". I can not recommend this book enough.

    On a side note I have also read his book on Refactoring and the chapter called "Bad Smells and Code" is a must for any serious developer.

    David
  6. PS.

    It was also good to hear at JavaOne that the Core J2EE Patterns group and Marting Fowlers group had been working together a lot more. Coming up with a common vocab is an important part of pattern work.

    Keep up the good work.

    David
  7. Confuses me a little when the topic is domain model. I know Entity EJBs
    with version 2.0 can have bi-directional relationships. Wouldn't this
    allow another Entity EJB to call the called-from EJB via the relationship?
  8. Just because something this "allowed" (will compile) does not mean it is legal (will run). The EJB specifications state that Entity beans should not be reentrant. This means that if you do have bi-directional relationships, you should be careful to make sure that for any given method execution, you only navigate your relationship in one direction.

    I would like to add that I think Martin Fowler's book is the single best design guide for Enterprise Development I have seen. I especially like the fact that he includes certain simple approaches (like Transaction Script) that others would call anti-patterns. Sometimes the simple approach works best. Other books on this subject often give the impression that only elaborate, uber-pattern designs work, but in some cases they can be overkill.
  9. I have not had time to read the two chapters in their entirety, but after reading certain comments in this thread, I took a look at pg 118 of chapter 9. The following extract surprised me:

    "Entity beans can’t be re-entrant. That is, if you call out from one entity
    bean into another object, that other object (or any object it calls) can’t call
    back into the first entity bean." (Patterns of Enterprise Application Architecture, pg 118)


    I was surprised further by the fact that no one, who has commented on this forum, has disagreed with the above statement. In fact, to the contrary:

    "The EJB specifications state that Entity beans should not be reentrant." (Message #90086)


    I can only assume that this is due to inexperience with CMP 2.0.


    The fact is that the EJB 2.0 specification does support re-entrancy, and it surprises me that Mr Fowler would not know this. Please examine the following extracts, from the EJB 2.0 specification:

    "The functionality of some entity beans may require loopbacks in the same transaction context.
    ...
    Re-entrant entity beans must be programmed and used with caution. First, the Bean Provider must code the entity bean with the anticipation of a loopback call. Second, since the container cannot, in general, tell a loopback from a concurrent call from a different client, the client programmer must be careful to avoid code that could lead to a concurrent call in the same transaction context.
    ...
    Concurrent calls in the same transaction context targeted at the same entity object are illegal and may lead to unpredictable results."


    (EJB 2.0 Specification, pg 267)

    My understanding of the above extracts are as follows:

    - Re-entrancy is legal. Note that re-entrancy is not concurrent, ie. A talks to B - B talks back to A (single thread of execution).

    - Concurrent calls, within the same transaction context, are illegal.

    - Developers must be aware of the potential risks involved in using re-entrancy - namely that a container may not be able to determine an illegal concurrent call within the same transaction context, from a legal loopback.


    Another point I should make, which anyone who has experience with working according to a specification should appreciate, is that not only does the EJB 2.0 specification state that re-entrancy is allowed, but I have been involved in the development of a project which makes extensive use of re-entrancy (It works in practice).


    However, that said, EJB CMP is far from perfect. It is important to remember that it is a relatively new technology and much maturing still needs to take place. Some of the current weaknesses of EJB CMP (off the top of my head) are as follows:

    - EJB QL is functionally weak. The EJB 2.1 specification, to be released soon - addresses this to some extent.

    - The is room for much improvement in current container implementations. However I can sympathise with container providers, as it is not an easy task to develop a good CMP implementation.

    - No natural support for inheritance (specialisation). Initially I was quite disappointed to discover this. However it is not a major drawback. Bean developers are able to achieve code 'inheritance' and are able to design in a way which minimises the areas of an application which are aware of the specialised types.

    - Development can, at times, become tedious due to all the layers which must be managed (Local Home, Local Interface, Bean Implementation, ejb-jar, containers configuration files). More and more tools are being developed which ease this pain, by automatically maintaining the various layers.

    - etc.


    EJB CMP 2.0 is not for every project. In fact I would even caution developers from rushing into using EJB CMP 2.0 on a project. Developers need to consider what is they are trying to achieve and choose the most appropriate tool for the job.
  10. I questioned it[ Go to top ]

    I questioned it in message 90074. I have a CMP2.0 domain model
    implemented and working. Was not smart enough to disagree though.
    So basically if A calls B, method A has to be finished before B can
    call A???
  11. I questioned it[ Go to top ]

    Apologies, I thought that you were questioning why bi-directional relationships were put in the CMP 2.0 specification, since (assuming re-entrancy is illegal) bi-directional relationships could allow developers to code re-entrancy.

    As for your question, I'm not sure I understand it correctly. Are you asking about a legal loopback or concurrent access within the same transaction context?
  12. A legal loopback[ Go to top ]

    I am trying to understand what, exactly, a legal loopback is vs. a concurrent
    call in the same transaction context. Since a transaction is probably the duration
    of the method in A that called B, and concurrent calls in the same transaction
    are illegal, and re-entrancy is not concurrent. At this point I am changing my
    mind and saying that a legal loopback would be that method a on A calls method
    b on B, and method b on B calls any method on A, or would it have to be method
    a, if re-entrancy is at the method level, before method a on A finishes.
      That way the re-entrant call
    would not be concurrent, but it would be in the same transaction, so it would
    be a legal loopback?
  13. A legal loopback[ Go to top ]

    Really what it boils down to is that EJBs are meant to be used in a single-threaded manner.

    Perhaps the easiest way to differentiate between a legal loopback and concurrent access within the same transaction context is by example.


    Example of a legal loopback
    ---------------------------

    Assume that all of the following occurrs within a single transaction (how a transaction is started and how long it lasts, depends on a number of things). This represents a single thread of execution.

    1. A session bean method invokes a method on entity A.
    2. Entity A's method then invokes a method on entity B.
    3. Entity B's method then invokes some or other method/s on entity A (any such calls are re-entrant).
    4. B's method returns.
    5. A's method returns.
    6. etc.


    Example of concurrent access within the same transaction context
    ----------------------------------------------------------------

    Again, assume that all of the following occurrs within a single transaction.

    1. A client application starts a new thread (T2).
    2. The new thread (T2) accesses an entity bean A.
    3. The client application's original thread of execution (T1) continues and also accesses entity bean A (concurrently).

    This can lead to unpredicable results.
  14. TopLink Patterns?[ Go to top ]

    Dunno whether Martin Fowler worked with TopLink and named his patterns after it, or the TopLink developers implemented Martin Fowler's ideas, or whether they all worked together this... Anyhow, exactly 100% of the O/R patterns listed in the book are present in TopLink, down to the name. Uncanny. See http://www.martinfowler.com/eaaCatalog/.
  15. The same could also be said of OJB (Object Relational Bridge), db.apache.org/ojb. I think the O/R space is pretty well defined at this point, and people have a good idea what is needed. So most of these patterns should be found in any O/R tool worth it's salt. That being said, it seems like most Java developers I see are (sadly IMHO) still rolling their own DAOs even though there are good open source and commercial options out there. Perhaps folks have been too badly burned by the over-complexity of CMP EJBs...
  16. Book Available Online[ Go to top ]

    Hello Everybody,
    wanted to ask you , whether the book is available online in softcopy as is the case with all the books that manning publications publishes.
    If yes then please give me the URL of the site for the same.
  17. IMO[ Go to top ]

    After taking a glance to both chapters, my conclusion is that I don't see any value added for J2EE developers to read that book (Maybe for .NET developers? Because he is using also C# as examples. Maybe there is no such a book in .NET world?).

    Everythings are already explained in Floyd's book and J2EE Patterns book. Just saying "I would prefer to call this X instead of Y" is not enough to give a value add to that book, I think.

    Don't understand me wrong, I have read many of Martin Fowler's books like Analysis Patterns, UML Distilled, eXtreme Programming and Refactoring and I love them.

    What do you think?

    Regards,
    Lofi.
    http://www.openuss.org
  18. Well, the real value that this book have for J2EE developers is to make them understand that J2EE is not the only platform for enterprise development. Fowler's book value is that the patterns are presentied in a platform neutral way. These patterns work either you use J2EE or .NET or CORBA/C++ or even COBOL. And there is a very good chance that they will work for the platforms that will come in the future.

    Just like the OS platform neutrality is one of the greatest Java strengths, the developer platform neutrality is the main strength of Fowler's book.

    Regards,
    Mileta
  19. Re: IMO[ Go to top ]

    "After taking a glance to both chapters, my conclusion is that I don't see any value added for J2EE developers to read that book..."


    I agree, this book seems more like a review of well-known patterns with a .NET twist.

    I also, enjoy most of Martin Fowler's books, but this one doesn't stir up any revelations. I think this book was introduced for the new (late?) comers of software developers for business applications.

    I know a certain market of developers wants to buy technical books with recent publishing dates. Also, other markets for books having the latest buzz words as well.

    My comments are for those developers, which are already in the trenches of applying patterns for "distributed" development.

    For those with no or little patterns backgrounds should consider this book...
  20. He can open J2EE eyes.[ Go to top ]

    I can definitely sense a negativity toward EJB, but just Entity Beans. His
    style is priceless though, along with his knowledge of OO. His take on
    Domain models, split into simple and rich, along with scripting for apps
    that do not require a domain model opened my eyes to things in the
    Entity EJB world and JDO. The main problem with Entity beans is that
    it cannot support a rich domain model according to Martin. That has
    been the crux of EJB business logic container acceptance. I can see a demand
    for EJB2.2 to support rich Domain models. I can see why Sun wants to
    keep problematic language constructs like threading and inheritance out of
    your mission critcal or core business software, thus a persistence solution
    which doesn't support Martin's rich Domain model. I like both concepts
    but lean toward Sun's Philosophy.

    I can't wait to read the transfer objects chapter.
    As a J2EE developer I think Martin Fowler's book can fill in some
    important holes, and open you eyes to better J2EE designs.

    He doesn't seem to grasp the philosophy of simplified Core business
    logic though, provided by a container, or ignores it due to his deep
    OO knowledge. Floyd, on the other hand, seems to be working with
    the Simplified, container approach, but still seems to be leaning
    toward a Rich Domain model also.

    Martin slips in another priceless OO tidbit. That the objects are hard to
    follow to debug, but the gain is elimation of conditionals in your code.
  21. I saw this book in the bookstore. I was very impressed by the converage and ideas for business layer patterns.

    Many of the J2EE pattern books focus on EJB patterns and give the business layer a lower priority. The obsession is persistance and distributed computing. Only other book I've seen that covers business logic very well is Bitter Java.

    Most J2EE programmers are putting biz logic into struts action classes or are using session bean/POJO facades. Not good for code reuse. Lots of conditionals. So much for OOP if you do things that way.

    Maybe if the spotlight gets put onto biz layer frameworks some popular standards will emerge. Like Struts + (your favorite biz layer) + hibernate.