Announcement Announcement Module
Collapse
No announcement yet.
Separate Web Tier and Business Logic tier. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Separate Web Tier and Business Logic tier.

    Hi all,

    I'm trying to understand how I might put together an application where I have a number of web applications which all need to reuse common business logic. Rather than place the logic in each web application, I would like to create a separate tier (which could run on a separate machine).

    Using spring in my web tier (inside Tomcat) is quite well documented and straightforward. My concern is how to run Spring in the middle tier, where ideally there won't be any Tomcat? How can one instantiate a Spring container in a standalone mode (and I'm not talking rich client here, I'm talking about on the server side). How could I, for example, construct a Spring container, which handled all my business objects and their persistence and ran as an NT (windows) service?

    Has anyone constructed an architecture such as this? Which remoting protocol would be the most efficient for communications between the web tier (tomcat + spring) and the middle tier (spring standalone)? RMI?

    Thanks for any assistance,
    Dominic.

  • #2
    I can't give you an advice about which remoting-communication protocol
    to chose - i'm only doing 'small-systems',
    but to create an application in 'standalone-mode' simply
    use a FileSystemXmlApplicationContext.

    To use your java application as daemon(*nix) or service(windows),
    take a look at this project http://wrapper.sourceforge.net/

    chris

    Comment


    • #3
      You can put your business logic in a seperate WAR and deploy that in your servlet container. In this WAR you can expose your services with HTTP invoker.

      Your client applications (web application, rich clients, ...) can access the business logic using HTTP invoker.

      Comment


      • #4
        Why do you want to run the business tier on a seperate machine? Initially you can design your business objects so they run locally, and when you later want to scale the system you can move the business objects to another machine without having to redesign your web tier.

        Comment


        • #5
          Originally posted by wpoitras
          Why do you want to run the business tier on a seperate machine? Initially you can design your business objects so they run locally, and when you later want to scale the system you can move the business objects to another machine without having to redesign your web tier.
          I'm not agrueing to run business logic on a separate machine although this is entirely feasible. Running your business logic centrally through remoting instead of in each deployed client locally offers a guarantee that there is only one version of your business logic deployed.

          Comment


          • #6
            There is difference between "sharing the same codebase", and "sharing the same physical deployment". I'd like to understand why it is worth all the remoting cost and extra architectural complexity to share one single physical deployment of the business tier, vs. sharing the same code base by including th same jar in every web app - how often do we redeploy a production web app in real world, like, three times a year?

            Comment


            • #7
              Originally posted by manifoldronin
              There is difference between "sharing the same codebase", and "sharing the same physical deployment". I'd like to understand why it is worth all the remoting cost and extra architectural complexity to share one single physical deployment of the business tier, vs. sharing the same code base by including th same jar in every web app - how often do we redeploy a production web app in real world, like, three times a year?
              I'm not saying this is always a requirement. If you have N client deployments depending on a single business logic tier accessing this business logic through remoting instead of local executions allows you to re-deploy the central BL deployment once instead of updating N clients as long as the client side API does not change. This can be an important feature, for example to fix bugs in a short timeframe.

              Comment


              • #8
                This can be an important feature, for example to fix bugs in a short timeframe.
                Arn't there solutions available for distributed updates? Just wondering... .

                Comment


                • #9
                  Originally posted by tentacle
                  I'm not saying this is always a requirement. If you have N client deployments depending on a single business logic tier accessing this business logic through remoting instead of local executions allows you to re-deploy the central BL deployment once instead of updating N clients as long as the client side API does not change. This can be an important feature, for example to fix bugs in a short timeframe.
                  Mmm, I still don't buy it. :wink:
                  I admit it's more convenient, but my question is whether it's worth the performance and architectural complexity penalties. Especially when you consider that whenever you deploy a new version of this central BL, chances are you will need to run all the client apps through regression tests anyway (and lots of other release preparation work), so is the time spent on repackaging client apps with a new version of the BL jar really that significant?

                  Comment


                  • #10
                    Originally posted by tentacle
                    You can put your business logic in a seperate WAR and deploy that in your servlet container. In this WAR you can expose your services with HTTP invoker.

                    Your client applications (web application, rich clients, ...) can access the business logic using HTTP invoker.
                    Effectively, this is the other scenario that I was thinking about. In this case, though, if the business logic tier was running in the same tomcat instance (asame JVM) as the web applications, it would seem to be a pity to use a remoting protocol for the communications.

                    My question in this case would be:

                    Is there any way to use Spring with Tomcat at a lower level than at a web application level? Can you get Tomcat to load Spring using a lower level classloader so that any services, beans, etc. could be made available to all the web applications running within the specific Tomcat instance?

                    Comment


                    • #11
                      Originally posted by manifoldronin
                      Originally posted by tentacle
                      I'm not saying this is always a requirement. If you have N client deployments depending on a single business logic tier accessing this business logic through remoting instead of local executions allows you to re-deploy the central BL deployment once instead of updating N clients as long as the client side API does not change. This can be an important feature, for example to fix bugs in a short timeframe.
                      Mmm, I still don't buy it. :wink:
                      I admit it's more convenient, but my question is whether it's worth the performance and architectural complexity penalties. Especially when you consider that whenever you deploy a new version of this central BL, chances are you will need to run all the client apps through regression tests anyway (and lots of other release preparation work), so is the time spent on repackaging client apps with a new version of the BL jar really that significant?
                      The other reason to not want to repackage common business logic in each web app is for performance reasons: imagine a situation where creating a particular object is very costly. In this situation, it would be much better for all the web applications to share the same (expensive) object rather than create their own copies.

                      Comment


                      • #12
                        Originally posted by dcioccar
                        Is there any way to use Spring with Tomcat at a lower level than at a web application level? Can you get Tomcat to load Spring using a lower level classloader so that any services, beans, etc. could be made available to all the web applications running within the specific Tomcat instance?
                        I suppose you could always put it on the tomcat server classpath. All the web apps would see the same copy now. I still think it's a can of worm if you ask me...

                        Comment


                        • #13
                          Originally posted by dcioccar
                          The other reason to not want to repackage common business logic in each web app is for performance reasons: imagine a situation where creating a particular object is very costly. In this situation, it would be much better for all the web applications to share the same (expensive) object rather than create their own copies.
                          Do you have a concrete example for that? Remember we are talking about one instance per client application, not one instance per end user - how many applications do you have to have to make any significant difference?

                          Besides, if this object is so expensive to create, it is very likely something stateful , which means access to it must be serialized. Are you sure you want all the client apps to be serialized in front of this one single object?

                          Comment


                          • #14
                            Besides, if this object is so expensive to create, it is very likely something stateful , which means access to it must be serialized. Are you sure you want all the client apps to be serialized in front of this one single object?
                            If they are simply reading the object state, there is no need for serialization (also transaction's atomacy is a helper here). But this is a transactional issue. Also mostly a single huge object sometimes gets distributed itself. Meaning a certain server owns just a little part of the big picture and if it comes to manipulation there are plenty of solutions for synchronization out there (transaction manager services / server, databases, update events / messages etc).

                            A good example for this one may be the index of web pages / search services - one huge index is split up but yet every piece of index is centralized (10000+ servers in case of google). Or application transaction scenarios / document workflows - one place to store the documents but many places to retrieve the documents. (Caching solutions).

                            Never the less back to the update in case of bug-fix stuff. I still don't buy this also. Most of all there are remote components out there using automatic updates in a pull fashion. Checking in a periode if something has to be updated. Also this can be scheduled, so there is a timely fashion for broad synchronization in it. So updating servers can be done in a timely short periode. Or in case of redundant servers, a half of the server updates while the other half still satisfies the consumers. After that the other servers gets updated... .

                            If the updated part is very important you will have a recovery solution as well (in case of a system crash). So there is no problem with data / information loss even in case of a rude update (kill the process, update the files)... . So for me this isn't a strong point for the Pro of centralisation in sense of servers.


                            Cheers,

                            Martin (Kersten)

                            Comment


                            • #15
                              Originally posted by dcioccar
                              Originally posted by tentacle
                              You can put your business logic in a seperate WAR and deploy that in your servlet container. In this WAR you can expose your services with HTTP invoker.

                              Your client applications (web application, rich clients, ...) can access the business logic using HTTP invoker.
                              Effectively, this is the other scenario that I was thinking about. In this case, though, if the business logic tier was running in the same tomcat instance (asame JVM) as the web applications, it would seem to be a pity to use a remoting protocol for the communications.

                              My question in this case would be:

                              Is there any way to use Spring with Tomcat at a lower level than at a web application level? Can you get Tomcat to load Spring using a lower level classloader so that any services, beans, etc. could be made available to all the web applications running within the specific Tomcat instance?
                              You can put your business logic in the lib directory of the tomcat server which is loaded by a parent classloader shared by each deployed WAR. This is however clumsy since you have to restart your server if you re-deploy your BL. This would mean applications that do not use your BL would experience downtime all the same.

                              Comment

                              Working...
                              X