Discussions

Performance and scalability: Architecture guidelines Web/App server

Bookmark and Share Get thread feed

  1. Architecture guidelines Web/App server (5 messages)

    • Posted by: Ben Farr
    • Posted on: July 07 2004 18:44 EDT
    Hi,

    We are implementing a internet based system based on JSP/Tiles/Struts & TopLink O/R. We are required to use OC4J as an app server, but apart from this we are looking to deploy on a 3 tier architecture Web/App/DB servers.

    At the moment we have just been developing the application on a single instance of OC4J.

    We are at a stage where we are a bit uncertain of if we should just use the Web server for delivering static content (Apache) or implement Tomcat/Apache where we would actually split out our code so that all Struts logic/classes live on the Web server and they would access our business logic layer via RMI. At the end of the day it wont be up to us but I need to present some reccomendations.

    Does anyone have any opinions or could point me to the right direction for information regarding best practices.

    Thanks in advance

    Ben
    Reply to this

    Threaded Messages (5)

  2. Architecture guidelines Web/App server[ Go to top ]

    What about:
      What kind of load you are going to have to support? Number of users...
      Are thier any aditional clients other that the browser?
      Is this app data intensive?

    These questions need to be answered before you can make the decision.

    A good book on this topic is: http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html. The first three chapters.
    Reply to this Reply to original

  3. Architecture guidelines Web/App server[ Go to top ]

    Hi,We are implementing a internet based system based on JSP/Tiles/Struts & TopLink O/R. We are required to use OC4J as an app server, but apart from this we are looking to deploy on a 3 tier architecture Web/App/DB servers.At the moment we have just been developing the application on a single instance of OC4J. We are at a stage where we are a bit uncertain of if we should just use the Web server for delivering static content (Apache) or implement Tomcat/Apache where we would actually split out our code so that all Struts logic/classes live on the Web server and they would access our business logic layer via RMI. At the end of the day it wont be up to us but I need to present some reccomendations.Does anyone have any opinions or could point me to the right direction for information regarding best practices.Thanks in advanceBen
    When you say RMI are you inferring EJB?
    Reply to this Reply to original

  4. Architecture guidelines Web/App server[ Go to top ]

    We use exactly same structure in one of our projects on oc4j 9.0.2(Doesn't support local interfaces), with static contents separated on Apache. Performance wise, I would say it is ok. The architecture is good, but not the container. I think it is better to keep both web and ejb together in one container.

    Thanks,
    Senthil.
    Reply to this Reply to original

  5. Architecture guidelines Web/App server[ Go to top ]

    We use the same instances of the app server to execute both web and ejb code. It only makes sense to put the web code outside the app server, if this code is very slow and consumes a lot o CPU, for example the typical XSLT processing. If you divide he code in web and ejb, you can use inexpensive windows servers to run the XSL transformations, and use more expensive machines to run the business logic of the EJBs.
    We use exactly same structure in one of our projects on oc4j 9.0.2(Doesn't support local interfaces), with static contents separated on Apache. Performance wise, I would say it is ok. The architecture is good, but not the container. I think it is better to keep both web and ejb together in one container.Thanks,Senthil.
    Reply to this Reply to original

  6. Architecture guidelines Web/App server[ Go to top ]

    As posted in a reply before you really need to answer the questions of what will the load be used on the site, although there are also other questions that you need to answer:
    - Will you have dynamic contents?
    - how often will the site be updated?
    - Will the majority of your users just be viewing the site or editing the contents?

    If you have a site that does not get updated/changed very often or does not rely heavily on static content then it makes more sense to create static pages and then serve these up to users (this architecture is used in MoveableType Blogs as the content only changed every now and then). However if you site is constantly changing or you are building web applications where the users is changing altering and moving data then you will need to build a more dynamic site that accesses the data directly (eg. use tomcat/apache).

    You really need to provide more information about what you want to use the technology before you can make decisions about how you design the architecture that you will use. Remember requirements gathering is always before system design.
    Reply to this Reply to original