Architecture choice


EJB programming & troubleshooting: Architecture choice

  1. Architecture choice (7 messages)

    We have come up with a design for a web tool having the following components

    1> Presentation layer - Servlets or JSP pages
    2> Business layer - Java classes
    3> Database layer - Java classes and DB procedures

    We are looking for options where we do not have to go with J2EE and have our JSP pages call the Java classes directly. Can anybody answer some of the basic questions that we have

    1> Persistance - How to keep the objects persistent if we need to refer to that in another page.
    2> Beans - Do we have to use Java Beans? If yes, then what are the advantages in this scenario?. maintain the state of the bean between pages?
    3> Or are we going in a totally wrong direction and have to use J2EE.

    Extra information or reference documents welcome.


    Threaded Messages (7)

  2. Architecture choice[ Go to top ]

    You may end up reinventing the whole J2EE infrastructure and loose focus of your application. Unless your application is very simple, I would reccommend embracing J2EE now.

  3. Architecture choice[ Go to top ]

    IMHO you're probably going in the right direction. Unless you're web tool is very complex, I would recommend ignoring EJB. Note that JSP is J2EE too, but I'm guessing you were talking about the "heavier" J2EE, i.e EJB.

    However, there is still no reason you should reinvent the wheel. There are some nice frameworks out there to help you build Web applications with Servlets/JSP. One particularly useful framework that I would strongly consider is Struts.
    It is a pretty minimalistic framework that you can learn in a matter of days, and it provides a whole lot of common functionality for you. It's not a rocket science, expensive solution like EJB. Just some well-written code for addressing common problems. It also helps solving some of the questions you raised. If you want, you can check it out on

    Good luck :)
  4. Architecture choice[ Go to top ]

    BTW - don't be scared by the number of classes in the API. There are a lot of BeanInfo and TagExtraInfo classes there, and you actually only need to know a couple of simple classes.

  5. Architecture choice[ Go to top ]

    There's also Jakarta Turbine . Take a look, it's well worth it.

    It's heavy duty and takes a bit to get into it but once you do it's a great MVC compliant framework allowing you to work with JSP's (if you must) or other templating engines (Velocity (It rocks), Webmacro etc..).

    P.S. I've been investigating this whole 'to EJB or not to EJB' issue and my conclusion is: If you're not constructing a very large scale (And I mean VERY) distributed app then a MVC servlet framework-based app running under a decent load-balanced web-server can handle all but the most demanding of loads.)

    Just my 0.2 Euros ;)

  6. Architecture choice[ Go to top ]

    Thanks everybody. I will take a look at that.

    I guess I needed answer to a couple of more questions.

    1> Persistance of objects between pages in case I ignore EJBs. Are there some standards to follow?

    2> I wanted to devise a standard of passing the request object back to the java classes or EJB's from the JSP pages and return objects (with status). So basically all requests (data entered by the user) should go as one standard object to the business layer. Can I send the JSP request object to the java classes directly? I am not sure if I can do that. Hence I was wondering if there is a standard to follow. Also, when I return data back from the business layer I wanted to send back the status of the request (with error message in case of error).

  7. Architecture choice[ Go to top ]

    1) You have access to the HttpSession object which will allow you to maintain state between page requests. Things could get a little tricky if you are considering a clustered hardware solution. If so, let us know so that we can discuss that as well.

    2) A couple of recommendations on this thread suggested looking into some of the Apache Jakarta projects. If you have the time, I suggest you take that advice. If you don't, then I would define an interface for objects that execute your particular business functionality. This interface should define a method whose signature is something like

    public int performAction(HttpServletRequest request);


    public int performAction(HttpServletRequest request,
                             HttpServletResponse response);

    The return value can be your status code and the method implementations can use the request object to store information in the users Session object for later use by the appropriate JSP page. The point is to not make to many assumptions on what your Action objects are going to need from the HttpServletRequest object. Just pass it the whole thing. There's no overhead since you're just passing a copy of the object reference.

    It sounds like you may be POSTing to your JSP page(s). Consider POSTing to a servlet and just using the JSP page(s) for presentation.

    Finally, I'd recommend spending a few days looking at the Struts framework. It's simple and efficient and it'll provide a proper example of an MVC design application.
  8. Architecture choice[ Go to top ]

    1) Have you looked at CacheRowSet or JDO?

    2) Are you talking about HTTPRequest? If so, I would not recommend passing the request object to the java classes/EJB. IMO, it is mixing presentation with business tier. What should you do if your clients do not support HTTPRequest? How can they call your java classes or EJB?

    If you really want a standard object from JSP to EJB/java and vice visa.. The easy way is to pass either ArrayList or HashMap (or a Collection).

    Just my 2 cents