2 Replies Latest reply on Nov 21, 2006 9:45 AM by Chris Odom

    newb EJB 3 Design Pattern question

    Jason Wood Newbie

      My question revolves around remote interfaces and using the persistence API. An example might give more insight into my question?

      I have 3 tables Customer, Order, LineItem with the corresponding object associations:

      class Customer {
       long id;
       List<Order> orders;
       public long getId() {};
       public List<Order> getOrders(){};

      class Order {
       long id;
       List<LineItem> lineItems;
       public long getId() {};
       public List<LineItem> getLineItems() {};
       public Customer getCustomer() {};

      Class LineItem {
       long id;
       public long getId() {};
       public Order getOrder() {};

      When using a session bean that implements a remote interface I make a call similar to the following?
      class OrderBean implements RemoteOrder {
       public List<Order> getOrders(long custId) {
       return em.createNamedQuery(?order.findByCustomerId?)
       .setParmater(?custId?, custId)

      Now this would work great in a Servlet/JSP that was running in the same JVM, but I am accessing this from a web service. I am wondering what is the ?standard? way to return the persistent data to the web service client? Is it off load everything into value objects? Something has to be done otherwise I will always get exceptions when trying to access the lazy children of Customer. Even if I do a FETCH JOIN for Customer.orders then the problem nest down to Order.lineItems, should I FETCH JOIN this to?

      What about the cyclic call during marhsalling from Customer.getOrders() then Orders.getCustomers()? I have yet to find documentation ?anywhere? ;) that defines a standard way to handle this or should we still develop the J2EE way and use Transfer Objects (J2EE design Pattern), but I thought the persistence layer and POJOs was supposed to remove this extra layer from the enterprise application.

      If the Order Pojo had some header information an thats all I needed for a particluar web service request, meaning I do not want the lineitems, should I create another pojo object mapped to the table but with only the fields that represent the header? Should I create a Transfer Object/Value Object?

      I guess I am some confused of when or if I should use the Pojo when returning data for remote calls. I have read the J2EE Design Patterns and maybe those Patterns still apply I just thought that pojos where supposed to take place of value and transfer objects.

      Thanks for any help :)

        • 1. Re: newb EJB 3 Design Pattern question
          celer celer Newbie


          I am new to EJB3 as well, and struggling with the same issue. From what I can tell it is the way the system is designed.

          You many want to start by reading this:


          So my take on it is that you may not want the client modifying the collections on your POJOs outside the scope of a transaction.

          I have a post on the EJB3 forum here that ask the same question, except my example is a tree that supports recursion. My issue was that I wanted to be able to modify the tree nodes directly.

          See: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=87956

          But if you think about it in a more transaction oriented light, it doesn't make sense to modify the entity directly. Instead you would want the server controlling the whole transaction. For example moving tree nodes from one part of the tree to another is something you really want backed by a transaction.

          No don't get me wrong, I am not thrilled about the design, but it sure seems to be better then EJB 2.0


          • 2. Re: newb EJB 3 Design Pattern question
            Chris Odom Newbie

            Falling back to the J2EE design patterns and using Stateless Session Beans as a Session Facades you have the ability to expose methods with security constraints as WebServices end points using a broker. With this in mind you now are able to use the JAXB bind objects as transfer objects which simplifies the marshalling of responses back to the Client.

            This type of implementation also allows for re-use of the Session Facade method calls by Business Delegates. Interfacing your Session Facades you can create 2 constructs for both Local (Business Delegates) and Remote (Web Services calls). This allow you to annotate your security framework for the particular calls that are being made.

            The EJB3 implementation does not the J2EE patterns but has only simplified the Containers implementation making the Bean Context a more managable and flexible framework. Please do not disregard your thoughts on using J2EE patterns these are still valid with the new EJB3 paradigm.