Interview with Inderjeet Singh J2EE Blueprints Architect posted


News: Interview with Inderjeet Singh J2EE Blueprints Architect posted

  1. A hard core tech talk interview with Inderjeet Singh, J2EE Blueprints Architect has been posted on TheServerSide. Inderjeet has been involved with the J2EE BluePrints since its inception. In this interview, Inderjeet will talk about the J2EE Blueprints, where to store state (the database, servlet, client, or EJB layer), and the relationship between the MVC architecture and J2EE applications.

    Check out the interview with Inderjeet.

    Feel free to discuss this interview here.

    Threaded Messages (17)

  2. a very good one.. i hope these kind of interviews with key j2ee people will help us in doing better design and implementation of j2ee solutions.
  3. I agree!A good article to re affirm beliefs and a good reference point when architectural disagreements arise. [How long will it stay posted?]

    Well worth listening to.

    One answer did stop mid sentence though - maybe a one off.

  4.  Hi Alan,

         Inderjeet's video will remain the featured video at least for another week; however, the video will be archived. Click on the 'Recently Archived Videos' link on the Events page rightbar to view all the previous videos from Rod Smith (first interview) - Inderjeet Singh (latest).

        As for the questions being 'cut off' in mid sentence, that was actually done out of editing necessity and is not a flaw in the clips. :)

  5. According to the interview, one of disadvantages of keeping state in a servlet is that scalability is limited to one processor/JVM. At the same time, PetStore uses synchronized methods to prevent simultaneous access to SFSB. I find the above somewhat contradictory.
  6. The synchronized methods will make sure that the same SFSB is not accessed concurrently. It does not limit scalability at all, since each concurrently active user will have its own SFSB.
  7. You mention architecting MVC by having the bulk of the controller and the model on the EJB tier. Would this kind of approach not increase network traffic significantly due to the fact that typically the Web tier will be run on a separate server to the EJB tier ?

    For example just to display a JSP for a GET request would have to go via the EJB tier before returing back the page to display ?

    Are we likely to see this kind of approach appearing in current frameworks such as Struts in the future ?


  8. If the network traffic is a concern, consider using local EJBs in the web-tier. The Java Pet Store application version 1.3 demonstrates this approach. The primary benefit of the EJB-layer is a nice component model to work with.
  9. where in the ejb layer?[ Go to top ]

    Also in regard to the storing of session state: it's not clear whether you intend stateful session beans when you say "the ejb layer", as the other commentor intimated, but I guess that is what you meant; in a scenario where you have multiple clones of the ejb server, you would have to store the handle to the stateful session bean in the Http session for the particular client (wouldn't you?); now, if the stateful session bean is created on clone 1 in the first request from client 1, but routed to the clone 2 on the scond request, client 1's stateful session bean would have to be accessed via an oop rmi/iiop call, right? this is very likely to happen, very expensive; so, isn't it better to have the session in an entity bean (still in your ejb layer), but limiting the persistence of the enitity to only the durationof the session, i.e. deleting the db row at the end of the session? it seems the bigger issue is that the computing community doesn't consider the stateful session bean api to be viable, and thus it simply isn't used
  10. Definetly a good interview with concrete stuff.
    Regarding the discussion about where to store the session information, it is clear to me that the statefully session beans were designed for fat-client type of access and using them for web-based applications is a stretch. A proof of this statement is even the fact that you need to build a lot more around it to store your session - a web layer dispatcher to serialise the calls was given as an example. This means that if you don't need fat client access to your EJB application, the place to store the session is the web layer. All the commercial web containers support session fail-over and clustering, so the other arguments do not stand.

    In the light of the heated discussion regarding the best practices vs. performance (see the discussion about the .Net Pet Store), I think it should be made clear that there always are going to be trade-offs between flexibility, performance and maintainability. The blue-prints team should clearly state the main goal of their architecture. In my understanding this seems to be portablity and flexibility. Everybody should take the parts of the blue prints that suits them best. If people would not like to have a portable application but a highly performant one, they should still be able to use some of the design patterns. Clearly stating the goals would eliminate some of the confusion.
  11. I am using linux and feel left out :(
  12. First of all, if you have (for whatever reason) decided to not use EJBs, then web-layer is the best place to store session state.

    Some of the commercial web containers do support fail-over and clustering but the runtime costs for that are quite high (almost as high if not higher, than implementing SFSB). Moreover, they place a number of programming restrictions if you wish to use such features.

    I agree that everybody should take the parts of BluePrints that suit them the best. We certainly do not claim to provide best advice for all possible application design scenarios. We will look into making it more explicit on our website, if that was not already the case.
  13. Streaming format[ Go to top ]

    I find the format of these "interviews" fairly irritating. There is really no advantage to the streaming video since all you get is a "talking head".

    The utility of having each question indexed (good idea there) was offset by having to sit through 7 seconds of "server side" name placement at the beginning of each clip.

    Going through the process of watching each clip was much less productive than a transcript. (which would also avoid problems in deciphering various accents)
  14. Streaming format[ Go to top ]

    Yeah, bright idea EINSTEIN!
  15. Streaming format[ Go to top ]

    Excellent feedback Richie. Address the points and not my spam filter.
  16. Aye, found the format of these "interviews" barely irritating. There is willy know advantage to the screaming video since all you get is a "balking head".

    The futility of having each question indented (god id their) was putoff by having to set through 6 seconds of "usurper side" moniker placement at the beginning of each clip.

    Going through the pwocess of watching each clip was much more productive than a manuscript. (which would also avoid problems in de-icing various dialects)
  17. This interview is highly useful, as it brings out the various issues like Client state handling, etc. in a very organised manner. What I liked more is the emphasis on the design and architecture issues by talking on the MVC and Facade apprach in an architectural point of view. This interview alongwith the blueprints has played a critical role in one of our recent J2EE application architecture, which is presently under the design stage.

    Binildas C. A.
    mailto:binildas at ibsplc dot com

  18. I use completely opensourced products for a project I am working on. Is it wise for me to move to EJB development just for the sake of having "more OO and scalable"
    session management ? I know I can afford JBoss.

    Gavin Bong