App Server Independence

Discussions

General J2EE: App Server Independence

  1. App Server Independence (5 messages)

    Hello everyone,

    Last time when I need, I got the answers here. Here I am again. I have a couple of questions and do you folks have the answers for that?

    1. Can we make a truly app server independent application so that a client can choose its own app server?

    2. Why shouldn't we use statefull beans?

    TIA
    Ranjan

    Threaded Messages (5)

  2. App Server Independence[ Go to top ]

    You SHOULD use stateful beans if you have the need to maintain a user's state. Do you use the HttpSession to store user data/objects? A stateful session bean can be used to do the same on the app server.
  3. App Server Independence[ Go to top ]

    Thanks Jeff...We won't be using the HTTPSessions that's why I was thinking about statefull beans..

    What actually I meant by asking is what are the drawbacks we have with stateful beans in terms of scalability and connection pooling etc..

    Ranjan
  4. App Server Independence[ Go to top ]

    With stateless session beans the container can easily pool and reuse beans while in case of stateful session beans the container will need to passivate the stateful session ,which will the require the container to save the state to a persistant store from where it can recreated again when this passivated bean is requested by the client (in turn requiring the container to activate this bean).

    This might be a source of I/O bottlenecks.
  5. App Server Independence[ Go to top ]

    Thanks Chetan, but wouldn't be easier to use Entity Beans?

    Also, if we write our business logic in pure J2EE standards and then leave the deployment scripts to be generated for the different App servers, can we have choice of app servers? What will be the performance degradation, if any?

    Also, J2EE does not talk about connection pooling. Does it mean we have to include all those APIs in the beans, which makes it not portable?

    Ranjan
  6. App Server Independence[ Go to top ]

    Thanks Chetan, but wouldn't be easier to use Entity Beans?


    Entity Beans should be used when you want to persist data. While implementing a business functionality there might be a scenario where you need to interact twice or more times before you can save the changes to the databse. So in this scenario it is recommended that we use Stateful Session beans. Because if we try to persist data during each user interaction then the database is likely to have incorrect data or should we say inconsistant data (in Transaction jargon).

    >Also, if we write our business logic in pure J2EE >standards and then leave the deployment scripts to be >generated for the different App servers, can we have >choice of app servers? What will be the performance >degradation, if any?

    Ideally speaking Yes, you can write your beans which are J2EE compliant without using any properietery API's offered by various app servers (and thus making your component deployable in any J2EE compliant appserver). But there is one problem to that, you won't be able to exploit the true power of a particular app server, which I think in most cases is fine.
     
    >Also, J2EE does not talk about connection pooling. Does >it mean we have to include all those APIs in the beans, >which makes it not portable?

    I think Connection Pooling is taken care of by all major industry strength appservers like Weblogic/Websphere..
    Also, I went thru the EJB2.0 proposed draft's Goals section and they mention that one of the goals of EJB arch. is Application developers will not have to understand low level transaction management, Connection pooling details. So I guess it will become part of all app servers which are J2EE compliant.



    Ranjan