Announcement Announcement Module
Collapse
No announcement yet.
Which remoting protocol to use in 3-tier architecture Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Which remoting protocol to use in 3-tier architecture

    hi All,

    I'm a spring newbie and investigating some of the Spring remoting interfaces.. which remoting protocol would you recommend when going from presentation to data tier. The architecture is simply:

    Presentation <- [which protocol]-> Business <- jdbc -> Data

    My JSF pages need to retrieve data to display to the user. In order to retrieve that data it has to go through the Business tier which in turn makes calls to the Data tier via JDBC. What protocol goes inbetween Presentation and Business: hessian, burlap, httpInvoker, jax-rpc?

    All components in each tier are java systems.

    For example in doing pagination in the presentation tier, the data sets are very tall skinny tables (4 columns, with 100 rows). The target base for the first release is a worst-case 20 concurrent users making these data retrievals.

    Thanks.
    SM

  • #2
    It depends on what sort of requirements you have:

    - Are you trying to limit the number of EJB servers for each tier? If you'd rather just use a servlet engine, you should use one of the Http based protocols
    - Do any of the remote calls participate in a transaction. If so, EJB is pretty much the only option for this. (Since your remote calls are coming from JSF, my guess this isn't an issue)
    - Do any of the machines cross a firewall with stict restrictions on what kind of data passes through them. Some firewalls are configured to not only let through port 80 traffic, but require strict adherance to HTTP protocol. I'm not sure which protocols fit this requirement, you'd need to do some research.

    It sounds like your system isn't going to have a lot of users, nor is a lot of data going to come back from any of the requests. So performance and network bandwidth don't appear to be a problem.

    My guess any of them would fit your needs, given the small amount of users and data. It depends on what you find easier to configure. Unfortunately I am not familiar enough to make that judgement. The wonderful thing is you can switch protocols and your business objects and your JSF code won't have to change a bit. Just the remoting wrapper, business tier configuration and your Spring config files.

    Comment


    • #3
      Thanks for insights

      We won't be using any EJB servers in the architecture. All servers will be Tomcat Application servers.

      The remote calls do participate in a transactions (CURD operations). Are you sure that "EJBs are the only option for this."??

      There will be firewalls inbetween the three tiers. Good point, this makes going with httpInvoker or JaxRpc more compelling.

      The system will initially have 20-50 concurrent users. Some of the calls from the presentation to business will be "chatty" like pagination. This chatty nature makes me think the httpInvokerProxy is the way to go since its has lower network overhead. According to the jpetstore I found the following results:

      -----------------------------------------
      ms % Task name
      -----------------------------------------
      00312 011% hessianProxy
      00500 018% burlapProxy
      00281 010% httpInvokerProxy
      01750 062% jaxRpcProxy

      I know that httpInvoker uses the standard java serialization algo so as long as I stick to a pure java network we're OK.

      I guess for the kind of requests (pagination requests, user administration, browsing files as defined in the db schema) we'll be doing, is the httpInvokerProxy the right protocol to use when crossing presentation <-> business tiers?

      thanks for any input!

      Comment


      • #4
        Re: Thanks for insights

        Originally posted by silly_me
        We won't be using any EJB servers in the architecture. All servers will be Tomcat Application servers.

        The remote calls do participate in a transactions (CURD operations). Are you sure that "EJBs are the only option for this."??
        Yes. What I'm talking about you would start your transaction on the web server, making sure that any operations (EJB, JMS, direct JDBC) all participate inside the same transaction. So if the JMS or direct JDBC operation failed, the EJB operation would rollback as well.

        I don't think that applies to you. I imagine you are using standard Spring transaction that starts and ends on the remote machine which manages the business tier, not the web server.

        Comment


        • #5
          Re: Thanks for insights

          Originally posted by silly_me
          -----------------------------------------
          ms % Task name
          -----------------------------------------
          00312 011% hessianProxy
          00500 018% burlapProxy
          00281 010% httpInvokerProxy
          01750 062% jaxRpcProxy
          I'd love to hear how these figures stack up with using Lingo

          http://lingo.codehaus.org/

          along with ActiveMQ as the JMS provider!

          Comment

          Working...
          X