why not combine servlet with session bean into 1 thing

Discussions

EJB design: why not combine servlet with session bean into 1 thing

  1. why not combine servlet with session bean into 1 thing (5 messages)

    i have been working on prototyping a project that involve
    a lot of entity changes through times... some ideas
    just popup in my head..

    it's a pain to do "request.getParameter(...)" or even
    put a <jsp:setProperty name="somebean" property="*"/>
    in a jsp page, then send over this parameters or
    javabean (as a data value object) to the session bean
    to process.

    problem:
    1) session bean api is set.
       e.g.
           SomeSessionBean.updateReport(String reportName, String reportDescription...)
       or
           SomeSessionBean.updateReport(ReportObject object)

    once there is a changes need to be made on the report object,
    then i need to:
    1) update the jsp / html form to add more attributes
    2) uddate the report object (the javabean)
    3) update method calls the session bean
    4) update proper logic and business rules changes in the session bean.

    ah. a pain. why i need to do 2) and 3)?
    why can i pass the entire HttpServletRequest object to the session bean,
    and let it do the proper data retrieval and processing?

    think of if you have those "BusinessDelegate", thing of how many API you have to update?..

    how about wrapping all the http headers / parameters / additional data to a hashtable, and send it over to the session bena like this:
        
    SomeSessionBean.updateReport(Hashtable request, Hashtable header, Hashtable session)

    i love servlet's doGet / doPost / request / response
    why can we have the similar thing in the EJB world?
    ..
  2. SomeSessionBean.updateReport(Hashtable request, Hashtable header, Hashtable session)


    You could certainly do that. I believe there is a pattern called Hashtable Data Tranfer Objects that propose not having any real data structures for DTOs, but using hashtables, so you don't have to change APIs so much.

    That creates all kinds of trouble though, because you realistically have to keep a central store of all the key names in your hashtables, and when that changes, everyone involved needs to know about it.

    Theoretically, Data Transfer Objects proper are a good compromise. Your mean method would always be:

    SessionBean.updateReport(ReportDTO)

    and so, if you needed to change something, your bean interface doesnt' change. YOu just change ReportDTO.

    Note that there's no way around changing your bean implementation or UI, because you are changing business logic to handle new data collected by the user.

    So, the issue is really, do you want to change ReportDTO, or (if you are using all Hashtables), do you want to change KeyConstants.java or whatever it is.

    Furthermore, using hashtables can come back to haunt you because it makes it all too easy to bastardize your datastructures, and unless you do frequent audits of what goes in those structures, your system can become very hard to understand and difficult to maintain.
  3. thanks..

  4. mm i just don't like DTO...
    another question... are there any way we can have both Remote and Local interface for an EJB at run time?

    what i mean is we can only specify the bean either as local or remote on the deployment descriptor. if a setup one bean with the remote, and then aother bean with a local, will the data get synchronized? (they both map to the same table..)

    i want to setup some the "getXXX" methods for the entity bean in the remote interface, but have the "setXXX" for the local interface. that way i can use a session bean as a "Guard" to vertify everything before it call the local interface and do the update.

    The reason to have only "getXXX" method for the remote inteface because i just want the servlet container to do direct data lookup .. and can only "READ" the data...

    any clue?...

    sometimes i just don't know why we have so many difference interface while the programmer is writing the *almost the same* EJB interface ( extends EJBLocalObject / EJBObject).

    why can't we just need to specify that in the deployment descriptor syaing we want the bean to be local / remote?
    and don't have to write so many thing?....
  5. I thought you could deploy both, but I have never tried it. At the very least, you could deploy two beans that use the same bean implementation class (or 100 beans, I guess). So, you could make a "Read-Only" version of your remote interface and publish that to your presentation layer, and then make the full-fledged on local only.

    As to why you have to do a local vs. remote, I agree it's kinda lame. Seems like the app server should "do the right thing" and detect whether or not to use local. What might be better is to specify that a particular interface passes objects by reference or by value. For example:

    in some EJB:
    public Object someBeanMethod(Object o)
    {
      return o;
    }

    In client code:

    Object o = new Object();
    Object returned = myRemoteBean.someBeanMethod(o);
    // returned != o
    Object returnedLocal = myLocalBean.someBeanMethod(o);
    // returnedLocal == o

    which I think is the motivation behind local interfaces.
  6. just read the free JDO book and i think by using JDO i may solve the problem of having the *REMOTE/LOCAL* headache from the entitybean.

    in the J2EE integration chapters, there is a key advantage that with using JDO you can retrieve the DAO from running a query within the session bean, and you can return the *SAME DAO* object back to the client.

    this bring up another thought. why would you carry business logic in the entity bean? if not then what is the point to have the RMI interface for the client if they won't be accessing this RMI interface directly? if we need DAO does that mean this is kinda dumb for having this?

    one bad thing IMHO of JDO is that we have to compile the code with the vendor engine, so the vendor can *add some code* in the DAO class.

    why the vendor can't do that at runtime rather than *before* deployment?...

    i don't think anyone would like to compile their code 2 times before running it..