10 Replies Latest reply on Apr 30, 2004 8:03 AM by itchyoinker

    Design Question

    itchyoinker

      Hello,
      I'm new to JBoss, so I'm hoping that some of you can give me some general advice on setting up my system.

      Currently, I have a webapp that runs on Tomcat 5, but I'd like to add an application server. My initial thoughts are to use JBoss' integrated web container (either Tomcat or Jetty) to host my webapp and the app server to host POJOs wrapped in Session Beans. The POJOs would handle business processing and database activities via Hibernate.

      Here are some additional considerations...

      Security:
      We have a dual firewall with DMZ. The outer wall would have a port (port 80, for example) designated to access the web server from a browser. The web server would then access the app server via a different port (8080, for example). This port would not be accessible from the browser. The web/app server is on one computer and the database would sit on a second computer.

      Performance:
      Since the web server and app server would sit on the same computer, I would run both from the same VM. That way, they would run in the same process, thereby enabling interprocess calls between web server and app server.

      Future plans:
      With JBoss 4, would possibly change over to an all-POJO solution and possibly use the AOP...although I don't know much about it yet.

      Questions:

      1. Does my security model make sense, considering that the system needs to be accessible from the Internet?

      2. I have a P4 on Asus board, 1gig RAM, dual disks on IDE RAID controller, and Win2K. Based on this configuration, does the performance model that I mentioned above make sense? Distributing to other computers would be bad due to remote calls, right?

      3. What about wrapping POJOs in Sessions Beans for database access? Also, any thoughts on Hibernate?


      Your experiences and ideas would be of great value to me. Also, if any of these issues are covered in the docs or other articles, then please point me there. I would appreciate anything that would save me unnecessary searching and reading. I look forward to your comments--thanks in advance!

      Itchy

        • 1. Re: Design Question
          darranl

          Do not cross post.

          • 2. Re: Design Question
            jonlee

            A rather long and widespread list. I'll attempt to answer with broad brush strokes and I won't guarantee these as absolute answers.

            The security architecture you have proposed is in-line with a standard configuration practice. Your connection protocol between the web server and the app server can either be AJP1.3/JK(2) or proxy forwarding such as that supported by Apache. The WIKI covers the basics of that I think. AJP1.3 is probably preferable in terms of performance and load balancing.

            Performance is not as clear cut as you might think. The model you propose is adequate but also depends on the load. Should the load be too much for one CPU, the queueing times for requests may outweigh the additional cost of remote calls. A multi-CPU (SMP architecture) would probably be the fastest deployment model. YMMV so all options are viable but the choice ultimately depends on the application requirements.

            POJOs are probably fine although normally I would be inclined to deploy the business logic in session beans to properly take account of pooled database connections (datasources) and the performance model associated with that configuration. Should you be so inclined, I would look at J2EE design patterns - in particular, the session facade and the DAO and couple that with the business delegate for the client-side/presentation layer support. It's not necessary to delve heavily into design patterns as through practice and refactoring, you come to these architectural arrangements anyway. However, it does save you time in understanding some sound structural concepts.

            Hibernate is fine unless you have to consider migration to other J2EE application servers. In this case, you may want to stick with the ratified standards for portability. YMMV.

            • 3. Re: Design Question
              itchyoinker

              Thanks a bunch jonlee,
              Your post is a big help for getting me started in the right direction. I downloaded JBoss and hot-deployed my webapp. So far I like what I see.

              I'm still a bit confused by the connection pooling aspects of JBoss vs. Hibernate. I think they both seem to have pooling capability, if I'm not mistaken.

              I'm also confused about your comment on using "session beans to properly take account of pooled database connections (datasources)." If I'm not mistaken, wouldn't this only apply if I were using Entity Beans with Session Bean controllers? I wasn't planning on using Entity Beans, if that is the case.

              I haven't read the session facade and the DAO pattern descriptions yet, so sorry if those were dumb questions.

              By the way, I like your website. Judging by its content, I'd say it is safe to assume that you know a thing or two.

              Cheers,
              Itchy

              • 4. Re: Design Question
                jonlee

                Pooled connections are supported by both Hibernate and JBoss but interchanging them in JBoss 3.2.3 can cause some grief. This will be improved as they better integrate Hibernate into JBoss.

                Pooled connections provided by JBoss are managed as a resource by the EJB container and are rolled into the EJB transactions. That is; if you allocate a connection from the JBoss datasource within an EJB or EJB transaction chain, the operations performed using that connection will be enrolled in the transaction chain as well. Should the EJB transaction fail, all operations over the connection will be rolled back. Similarly, when the EJB (or EJB chain) successfully completes its operation, the transactions over the connection used during that EJB operation chain will also be committed. So if your POJOs require a database connection, obtain them from the JBoss datasource.

                Obtaining connections is an expensive operation. So is closing a connection. It takes time to authenticate a connection and set up the physical over-the-wire connection, and similarly to close a connection. The memory resources consumed by connections and their associated SQL operations can also be quite high.

                Pooled connections are semi-permanent connections and therefore when the pool-size is tuned correctly for the standard load of the application, avoid the initial connection setup cost and the connection termination cost every time a connection is required. Your EJB will request the connection from the pool, use it and then release the connection back to the pool. The connection reuse just saves time and resources. The trick is to be very quick about using a connection - don't hog the connection. That way it is possible to support an application with thousands of users with perhaps a connection pool with one hundred connections or less.

                That is a very brief run down but hope it conveys the gist of things.

                • 5. Re: Design Question
                  itchyoinker

                  jonlee,

                  I understand how connection pooling works, but my biggest challenge was determining which off-the-shelf components to combine. So I greatly apreciate your advice of using JBoss' connection pooling instead of Hibernate's. Otherwise, I would have to find out via costly experimentation.

                  Incidentally, I couldn't connect to my database directly via a JDBC connection. The JDBC code is written in a servlet. This works fine with standalone Tomcat, but doesn't work with JBoss' integrated Tomcat. Is this because the internal Tomcat runs inside a larger JBoss process that restricts direct access to the outside world?

                  Also, eventually, I'll need to access our existing C++ programs (via JNI perhaps). Do you know if this is possible using the JBoss' app server? Or will I again be restricted from accessing the outside world directly?

                  I appreciate any comments you have, but I don't want to waste your time by asking you to provide detailed explanations. A short reply would be more than very helful...then I'll figure out the details from there.

                  Again, many thanks...
                  Itchy






                  • 6. Re: Design Question
                    itchyoinker

                    In reference to my above post, I guess I should have searched through some of the other posts regarding JNI and C++ before hitting send. I now understand that there seem to be two methods for connecting to .dlls:

                    1).placing .dlls in bin directory and accessing via JNI directly.

                    2).using JCA/CORBA to access the .dlls.

                    My guess is that the first method would provide the best performance, but placing .dlls in the bin seems kind of sloppy. Another issue is portablity from JBoss to another app server, which might not support running .dlls this way. Just some thoughts...

                    Itchy

                    • 7. Re: Design Question
                      jonlee

                      The JBoss runtime environment doesn't really stop you from doing too much. So you should be able to get a JDBC connection as long as the driver is loaded in the environment - usually just put the JDBC driver in the JBOSS_HOME/server/default/lib directory. Unless your problem is that the application was using the Tomcat connection pool - which isn't implemented within the JBoss integration as JBoss has its own connection pool implementation. In this case, you should be able to create the JBoss datasource and "re-point" the application datasource references to the JBoss datasource. (I'm guessing here as I don't know what your application is really doing.)

                      The EJB spec advises against the use of JNI. Most application servers will still allow you to do it though but it isn't good practice. If you still want to go the JNI route, probably it is safest as an RMI/JNI implementation. In JBoss, you can also probably wrap the dll access within a JMX service, I guess.

                      Hope that helps.

                      • 8. Re: Design Question
                        itchyoinker

                        No, I wasn't using Tomcat's connection pool.

                        The class files for the jdbcodbc bridge are included in rt.jar within the jsdk. If I'm not mistaken, that is what my standalone Tomcat uses. I tried copying the whole rt.jar file into JBOSS_HOME/server/default/lib and also JBOSS_HOME/bin, but to no avail.

                        It's not really necessary for me to do this, but I just wanted to test the restrictions. Thanks for the suggestion though. It was worth a try.

                        Itchy

                        • 9. Re: Design Question
                          jonlee

                          My bad. I'd forgotten the the Sun jdbc-odbc bridge is now bundled in the runtime jar. Don't copy the rt.jar into the JBoss lib. The JVM should already load up the class. Nothing gets picked up from the bin directory unless it is specifically added to the classpath - e.g. modifying the start script for JBoss could achieve that.

                          You'd have to show the error for us to determine the problem. I had assumed that it would have been a class not found but since the bridge should already be there it may be something else.

                          • 10. Re: Design Question
                            itchyoinker

                            Hi jonlee,
                            Thanks for offering to help debug the driver issue. I haven't seen any messages in any of the logs, but I read somewhere (I think in the docs) that ALL connections are handled through the JCA, so maybe that is why it didn't work. Also I seem to have made a successful connection via the JCA, so using direct JDBC from Tomcat is no longer an issue for now. It was just a test for curiosityÂ’s sake anyway.


                            By the way, do you think that using XDoclet is absolutely necessary for generating scripts in SMALL projects? It's been about two days now and I still can't get it to generate my .hbm.xml files. although JBoss-service.xml DOES get created, so at least I know the hibernatedoclet task is being run.

                            My concern is that I will ultimately spend more time debugging XDoclet than if I would hand-write the files. I figure that you probably have some experience with both methods, so that is why I ask.

                            Regards,
                            Itchy