Announcement Announcement Module
Collapse
No announcement yet.
shared buisness component. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • shared buisness component.

    Hello,

    I'm examining an architectural proposition for an application plateform on J2EE. This plateform contains :
    - web applications (webapps).
    - buisness component reusable across many web-apps

    It is NOT required thah buisness components and webapps are deployed on different JVM ( webapps and reusable buisness component can be hosted in the same JVM).

    Someone made a first proposal by using EJB for implementing buisness component. That way the component could be reused by many web app.

    My point of view is that Spring/pojo is much more efficient approch than EJB and i want to introduce it on this plateform over EJB. To implement such a solution i need to :
    - implement the buisness components with spring+hibernate.
    - deploy this component in a way that it could be used by every webapp hosted on the same tomcat engine.

    I see 2 possible way for the deployment :
    1) pack the component in a jar and copy this jar, the appliicationContext-sharedBuissnedd.xml, every spring related-jar (spring.jar, hibernate.jar, ......) on every web-app that used it.

    2) put the above artefact in the shared libs of tomcat.

    My favorite way is the second one because i want to avoid to redeploy the buisness component on every webb-app each time the buisness implementation change.

    So my questions are :
    - Can spring.jar, hibernate jar be blundle in the shared lib ? (the documentation prone that every webapp embed their own spring.jar, hibernate.jar,...... )
    - If it's ok, need I embed spring.jar, hibernate.jar in the webapp that need it to implements their own buinsness components or the webapp can use the shared spring.jar, hibernate.jar ?
    - Will versions conflict occurs if my webapp embed a spring.jar that's not the same version that the one wich is in the shared lib ?
    - Can I reload the shared component without restarting tomcat (maybe a tomcat question :?)
    - Do you see a better way to achieve such a thing ? (using RMI,.ws,...)

    Thanks, for your comments. It is crucial for me to have more elements in order to recommend Spring over EJB in this relative important project.

  • #2
    Someone made a first proposal by using EJB for implementing buisness component. That way the component could be reused by many web app.
    IMO introducing remoting for such reasons is not a good idea. If you don't need remoting, local EJBs are the correct choice if using EJB at all.

    1. Can spring.jar, hibernate jar be blundle in the shared lib ? (the documentation prone that every webapp embed their own spring.jar, hibernate.jar,...... )
    2. If it's ok, need I embed spring.jar, hibernate.jar in the webapp that need it to implements their own buinsness components or the webapp can use the shared spring.jar, hibernate.jar ?
    3. Will versions conflict occurs if my webapp embed a spring.jar that's not the same version that the one wich is in the shared lib ?
    4. Can I reload the shared component without restarting tomcat (maybe a tomcat question )
    5. Do you see a better way to achieve such a thing ? (using RMI,.ws,...)
    1.spring.jar certainly can reside in shared lib. I've done this successfully in a Tomcat app. That app didn't use Hibernate, but I would assume the same is true of hibernate.jar and its friends.

    2. You wouldn't bundle those JARs in each web app.

    3. Depends on your web container. Normally according to the Servlet 2.3 spec, the one in the webapp would override the one in shared libs, but some containers interpret this part of Servlet 2.3 differently, and some even provide different config options.

    4. No, I believe you need to restart Tomcat. However a single upgrade will affect all apps.

    5. I would avoid remoting in this scenario, unless the performance/complexity are definitely not an issue. If the cost of remoting isn't going to be an issue, you could use any of these remoting technologies (or remote EJB).

    Rgds
    Rod

    Comment

    Working...
    X