Discussions

News: Tech Talk with Floyd Marinescu on EJB Design Patterns

  1. In this interview, Floyd discusses various patterns from his book, 'EJB Design Patterns' (2002 John Wiley & Sons), such as the Session Façade, the EJB Home Factory, and the Data Transfer Object (DTO). He looks at EJB 2.x's effects on design patterns, the role of entity beans in EJB 2.x, suggests Java Data Objects as an alternative to entity beans and addresses the challenges of writing a book.

    Watch Floyd's Interview Here

    Threaded Messages (16)

  2. I read Floyds book last year. I found it really nice.
    However, I think most of the so called "design patterns for J2EE" don't really deserve the name "design pattern", they should better be named "performance workarounds" since that is their only purpose.
  3. Indeed, some of the design patterns in my book and elsewhere are workarounds to problems with entity beans.. however, others (such as session facade, data transfer object, etc) really are patterns required for building distributed systems.

    Floyd
  4. Indeed, some of the design patterns in my book and elsewhere are workarounds to

    > problems with entity beans.. however, others (such as session facade, data
    > transfer object, etc) really are patterns required for building distributed
    > systems.

    Both examples you mention are to a certain extent related to problems with EJB. For example, I've built a large distributed system that works just fine without session facades and data transfer objects, i.e. they are not required either. They're just very useful if you happen to be building distributed systems using EJB.
  5. <Rickard>
    Both examples you mention are to a certain extent related to problems with EJB. For example, I've built a large distributed system that works just fine without session facades and data transfer objects, i.e. they are not required either. They're just very useful if you happen to be building distributed systems using EJB.
    </Rickard>

    Certainly both, Session Fa&#231;ade and Data Transfer Objects have to do with EJB's, hence the title of Floyd's book - "EJB Design Patterns". However, the applicability of these patterns (and of many others depicted in the book) can easily spread beyond EJB. Session Fa&#231;ade’s goal is to allow a client to isolate complexity of a business transaction into one network trip and to promote loose coupling between service consumer and implementation details of service provider. Many variations of Data Transfer Objects, in addition to minimizing network trips, serve to decouple client-side view on data from persistence view on the same data. I strongly believe that any reasonable distributed application (EJB or non-EJB) must acknowledge these, by now matured, design idioms and utilize them in one way or another.

    As a more general note, most practical applications of design patterns that promote loose coupling and reusability fall under common denominator of Service Oriented Frameworks (SOFs). SOFs (which are mostly based on SOA) allow to achieve a high degree of reusability for many system level services not covered by J2EE spec. By plugging the holes left open by J2EE, SOFs can provide same reusable implementation across various projects for many common services such as configuration, workflow or any other service not covered by J2EE spec. A developer empowered by SOF should get accustomed to reusing services as opposed to reinventing the wheel over and over again with every new project. It would be nice to see a set of design patterns built around SOF that specifically address the issue of reusability.

    Sincerely,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
  6. "design patterns for J2EE" don't really deserve the name "design pattern", they should better be named "performance workarounds"


    Looks like we're quoting Rod Johnson verbatim from his book "J2EE Design and Development" p. 21 where he comments on Floyd's book.

    > Both examples you mention are to a certain extent related to problems with EJB.

    There is nothing inherently related to EJBs about these problems (DTO and Facade). The problem lies in the qualitatively different nature of distributed programming and single address programming. These problems were present long before EJB came out - in CORBA and others.

    For a timeless and seminal exposition of this, see "A Note on Distributed Computing" Waldo et. al at http://research.sun.com/technical-reports/1994/abstract-29.html. This paper should be MUST reading for any modern day distributed programmer/architect. Certainly EJBs have introduced EJB-specific issues(entity beans, CMP), but many of the other issues are not EJB-specific. Rather, they belong to the broader category of distributed computing. The distinction is important, and should not be ignored.

    -- Andre
  7. "The problem lies in the qualitatively different nature of distributed programming and single address programming."


    Absolutely, and only developers building such systems before EJB can appreciate EJB now. Is EJB the silver bullet? No, but It's sure a lot nicer to have this specification to work with, rather than dealing with proprietary vendor APIs.

    The TSS threads are filled with posters perplexed with the challenges of building distributed systems. I think most "mainstream" developers are not ready for the nature of distributed programming. When developing distributed systems with other developers, I find most are still in the Client/Server box. For example, it's still difficult to conduct domain layer design discussion without somebody bringing up user interface concerns. In fact, it's rare to find development shops recognizing the domain layer as important as the presentation layer.

    Usually when asked: "The design is too complex - why are all these layers needed?"

    I reply: Well, it sure has worked for TCP/IP for all these years...


    So, it's not about Sockets, CORBA, COM, EJB, and .NET, it's about people...
  8. Usually when asked: "The design is too complex - why are all these layers needed?"

    >
    > I reply: Well, it sure has worked for TCP/IP for all these years...

    Then what about OSI? It has more layers.
  9. "The problem lies in the qualitatively different nature of distributed programming and single address programming."

    >
    > Absolutely, and only developers building such systems before EJB can appreciate EJB now. Is EJB the silver bullet? No, but It's sure a lot nicer to have this specification to work with, rather than dealing with proprietary vendor APIs.
    >

    True. I still think that often problems with EJB are only seen as problems because EJB wasn't the right technology for the project. Once I have verified I need Transcations and the system has (for any reason) to be a distributed one, all technologies I could choose have their drawbacks, including but not limited to EJB. It's simply not a lightweight technology.
  10. Looks like we're quoting Rod Johnson verbatim from his book "J2EE Design and Development" p. 21 where he comments on Floyd's book.

    > There is nothing inherently related to EJBs about these problems (DTO and Facade). The problem lies in the qualitatively different nature of distributed programming and single address programming. These problems were present long before EJB came out - in CORBA and others.

    Developing applications with distributed objects is hard. Certainly the DTO problem isn't EJB-specific. As Floyd points out, the EJB-specific workarounds primarily concern entity beans.

    EJB has, however, encouraged people to distribute their objects where it's not appropriate, because it's the one thing that EJB makes much easier to do. This isn't a problem with EJB itself, just how it tends to get used. I agree with Martin Fowler's vigorous arguments against distributing objects in Patterns of Enterprise Application Architecture (great book, by the way). The chapter on object distribution should be required reading for all J2EE developers.

    In my view, remote access should primarily expose services; only in rare cases is it beneficial for calls within applications to be made on distributed objects. Object distribution is usually very bad for performance. And even with local call optimization for colocated EJBs, designing against remote interfaces tends to hamper OO by forcing the use of DTOs. Anything that's just a data carrier isn't a true object.

    So yes, the challenges of distribution are not EJB-specific, but EJB is often a cause of what I call "eager distribution": getting into all that complexity without good reason.

    To my mind the best thing in EJB 2.0 wasn't the entity bean changes but the ability to use local interfaces for session beans. This enables us to choose to use EJB transaction management, threading etc without getting into the object distribution game.

    Regards,
    Rod
  11. EJB has, however, encouraged people to distribute their objects where it's not appropriate


    EJB: Old wine in new bottle? As Kendall, Waldo, Wollrath and Wyant wrote 9 years ago:

    We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.

    We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.

    -- Andre
  12. Both examples you mention are to a certain extent related to problems with EJB.


      I guess that depends on what you mean by 'a certain extent'. Whether you are building apps with .NET remoting, web services, plain old RMI, spirit of the Session Facade/DTO patterns still applies. That is, reduce network chattyness by creating a coarsegrained business services layer (Session Facade), and use well defined custom 'envelopes' of data to ferry data across remotely located tiers (DTO).

      It is true that I explain all these concepts in the context of EJB, but they are certainly not EJB specific patterns.

    >>For example, I've built a large distributed system that works just fine without session facades and data transfer objects, i.e. they are not required either. They're just very useful if you happen to be building distributed systems using EJB.

       That sounds really cool. If you didn't use SF/DTO equivelents, how did you reduce chattyness? Was it with a command pattern?

    Floyd
    ps - at TSS Symposium now; have infrequent email access...

  13. I think even session facades and DTOs are workarounds for shortcomings in EJB based architecture. The main purpose of DTO is to work around the performance prblems asociated with chatty RMI. Improperly done session beans always reming me of monolithic database stored procedures.
    </p>

    The main problem is that in distributed systems it is difficult to colocate data and behaviour. Distributed systems are seldom seamlessly object oriented through the tiers; rather they use more of a service based aprroached where orthogonal services may be implemneted as components that obey object oriented patterns and idioms.
    </p>

    BTW, Rickard, what patterns did you use in your system to avoid the performance issues associated with distributed communication?
  14. The main problem is that in distributed systems it is difficult to colocate data and behaviour. Distributed systems are seldom seamlessly object oriented through the tiers; rather they use more of a service based aprroached where orthogonal services may be implemneted as components that obey object oriented patterns and idioms.

    >

    Yes, that is true. You can look at this detailed treatment of this subjct at this link. http://www.objectwatch.com/issue_28.htm

    Roger Sessions used rather non-objected oriented VB6 code to demonstrate the how-tos of objects and components.

    Best Regards
    Narayana Pakala
  15. are you kidding?[ Go to top ]


    > Yes, that is true. You can look at this detailed treatment of this subjct at this link. http://www.objectwatch.com/issue_28.htm
    >
    > Roger Sessions used rather non-objected oriented VB6 code to demonstrate the how-tos of objects and components.
    >

    Is this a joke? Would you really call this oversimplified Starbucks story a detailed treatment? Or is this an attempt to drive some traffic to the Object Watch site?
  16. \Narayana Pakala\
     
    Roger Sessions used rather non-objected oriented VB6 code to demonstrate the how-tos of objects and components.

    \Narayana Pakala\

    Actually, I think the article mis-stated the basics rather badly. For one thing, the article basically comes down to saying objects = state, components = stateless. A big crux of his argument is:

    "The distributed nature of a component, for example, dictates that you design a small number of methods each of which take a large number of parameters. The in-process and data centric nature of an object, on the other hand, dictates a large number of methods, each taking very few parameters. Quite the opposite. A good object design is invariably a disastrous component design, and visa versa."

    Apparently, the author doesn't believe that components can have a stateful conversational state. Personally, I think he's extrapolating HTTP out to everything else :-)

    He also seems to believe that components are always distributed. ????

    The article also reads a bit like a manager three-times-removed from actual development describing objects and components. Like this....

    "You communicate with a component instance through a well defined interface. The interface defines the operations that the component instance can do for you. The definition of one of these operations we call a method. Any instance of a StarbucksEmployee can respond to any number of methods, many of which are downright silly. Who in their right mind, for example, would request the MakeIcedWhiteChocolateMocha method? I mean, really"

    I find it highly unlikely that a real distributed service system would have seperate methods for something like what is described above. Your "drink order" (or, more likely, a List of order items) would either use something like an enum, or object, or identifier, or even a plain old string to identify what was being ordered.

    My point is not to nit-pick the article to death, but rather to point out that the entire premise is highly artificial, and doesn't even make sense to anyone who's implemented real component-service systems.

         -Mike
  17. I tried opening the videos on Mozilla/Red Hat Linux 9. It asks for a Windows Media Player plugin. Can't we have videos that are Linux friendly and not go the M$ way?