Discussions

EJB design: Only local EJBs without value objects ?

Bookmark and Share Get thread feed

  1. Only local EJBs without value objects ? (7 messages)

    Hi community,

    in our project we have a deep object graph, besides our JSPs use some kind of bad predictable pulling from it. So i would like to get advise whether is it appropriate to retrieve from a local facade only local ejbs (without bothering of the replication their state to value objects)and render them on a JSP inside UserTransaction.

    Thanks
    Alex
    Reply to this

    Threaded Messages (7)

  2. Only local EJBs without value objects ?[ Go to top ]

    I am not sure that I fully understood you, so I need to know what is the nature of your local EJBs? What arguments are passed in and what result type is returned?

    Anyway, I would be very careful with user transactions in presentation layer in your case, I presume that using interlayer transactions could be a serious push towards loose coupling - one of the main axioms of n-tier development.
    Reply to this Reply to original

  3. Only local EJBs without value objects ?[ Go to top ]

    They are just local EJBs, nothing more but very overloaded with cmr-fields ones. Entire application is packed in the one ear archive, so only local things live there. Some of local entity beans are good-known WL readonly ones (no transaction at all) and some are not. Using struts I'm pushing top-level domain entities to JSPs and JSPs are pulling the rest. In a struts' action a transaction will be started and there is some servlet filter which plays at the end of request trying to commit (otherwise rollback) the transaction. Is it dangerous design ?
    Reply to this Reply to original

  4. Only local EJBs without value objects ?[ Go to top ]

    are you using Struts Actions and calling directly to Entity Beans? have you thought about using a Stateless Session EJB to call the Entity EJBs?
    Reply to this Reply to original

  5. Only local EJBs without value objects ?[ Go to top ]

    Noway. I'm still using the old good stateless facade. But instead receiving plain value objects from i get local EJBs wrapped as business interface objects. Those local ones represent my root domain objects. Then I push them to JSPs and a JSP digs deeply in domain object graph exploiting cmr-fields.

    My scenario:
    1.
    <some struts action>
    UserTransaction.begin()
    SomeBusinessObject bo = facade.getSomething(); // actually it is a local ejb
    request.setAttribute("xyz",bo);
    return findForward("success"); // no commit here
    </some struts action>

    2.
    <some jsp>
     <logic:iterate id="firstLevelElement" name="xyz" property="someCollectionOfFirstLevelElements">

      ....an so on for secondLevelElements...
     </logic:iterate>
    </some jsp>

    3. The servlet filter (say TxFilter) is responsible for commit/rollback of a transaction which was started at the previous struts action.

    That stuff works (on WL 6.1) but i'm not sure about design considerations.




    Reply to this Reply to original

  6. Only local EJBs without value objects ?[ Go to top ]

    Well, if you really do not want to bother with value objects, this design could work in case if you're 100% sure that you will never be planning to decouple presentation tier from logic tier more deeply (i.e. with changing local facades to remote ones, and what is even worse - putting them to the another machine).

    My personal opinion is that this design has a right to live, but only in this specific occassion.

    Alex.
    Reply to this Reply to original

  7. Only local EJBs without value objects ?[ Go to top ]

    Hi Alex,

    thank you for consideration of my design issues. What you could recommend for replication of a rich hierarchy of ejbs to the value objects if there are many nested collection-based levels and jsp rendering logic very depends on n-level element instance ? I see only two options: to produce huge pool of value objects (in my case that does not help) or implement a value object with some kind of an embedded proxy communicating to a related cmr-based bean home. But once again if one badly need a consistent view of a object graph it will be difficult to manage without client-side transaction.

    What you think about ?

    Regards

    Just another Alex
    Reply to this Reply to original

  8. Only local EJBs without value objects ?[ Go to top ]

    Hmm... Could you explain me why could you need such complex value objects? May be XML could be better solution for representing such a structured data?

    Alex.
    Reply to this Reply to original