Announcement Announcement Module
No announcement yet.
Spring, Remoting and Spring Rich Client Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring, Remoting and Spring Rich Client

    Hi Keith,
    Currently i am reading Expert One on One J2ee developement without EJB by Rod. In the book Rod clearly mentioned that in case your application requires rmi remoting you are better with using EJB rather than spring framwork, as EJB is better in this regard specially clustering etc. Most thick client application ( swing based ) usually are best with Rmi remoting due to performance concerns and it is very logical choice too. I know that spring provides rmi remoting but its purpose is not to build around a whole thick client app around it. Also it is not scalable (beacuse we are using rmi remoting of spring and how can it work with clustering, fail over stuff). So what are your comments about this remoting stuff also how do you view clustering stuff... i know about new http and jax-rpc remoting but thick clients ofetn need performance which will be reduced very much by using non clusetred rmi or http,web services ,.... Please give some vald arguments to convince me beacuse i am fanatic fan of spring and want to use that but Rod is advising against this.. tell me it is wrong i should use spring?

  • #2
    I think Rod's book was referring to the overwhelming minority of applications which require bean-to-bean remoting. Rod indicates most server-side beans are typically located within the same JVM, making such remoting unnecessary.

    If you do have a bean on Server A needing to talk to a bean on Server B, perhaps within the same transaction context, this is where a fully blown application server will help, and quite possibly via EJB over RMI. You can check with Rod but I don't think he said there is a reason for client-to-server communication to require EJB over RMI.

    Rod's book regularly refers to "evidence based" approaches and making up your own mind through proper benchmarking and vertical slice testing. Petclinic RCP is a working vertical slice if you want to evaluate a rich client approach not using EJB or RMI. You can easily switch protocols by editing the application context client proxies and server-side exporters. Just give it a try. The Petstore sample with Spring itself also offers a client-server application which you can benchmark.

    Going against RMI are the proxy server issues and additional server-side configuration required. I guess for intranet applications requiring lots of callbacks (high concurrency applications like reservations systems), RMI would be a better fit for client-to-server comms than the HTTP-based remoting protocols.


    • #3
      Ben, great points. Another advantage EJB+application server provides over a custom-built rmi solution, besides support for distributed transactions, is built-in thread pooling. This isn't as valuable in a web environment as pooling is generally taken care of by the web server. But I don't see myself rolling my own thread pool with a lightweight RMI server; maybe you could leverage commons-pool there, but still... if I needed that kind of scalability I'd probably be using an app server.

      I think Rod's main point was EJB is more appropriate when you require a highly transactional, concurrent client/server system and your client types are java-based and typically intranet-based (where use of direct RMI isn't an issue). When you have to support multiple client types (not often an requirement), or internet connectivity (more often one), one of the lightweight remoting protocols over HTTP such as Hessian or Burlap or Axis looks more attractive.

      Regardless, as Ben alludes to, if your client's' presentation tier works with business interfaces independent of a specific remoting implementation, as Spring makes possible, you effectively encapsulate your selection of remoting protocol and can swap out protocols without having to change client code. Both Petclinic RCP and the remoting sample in the code Spring codebase demonstrates this.


      • #4

        Thanks keith and ben for your valuable replies. But i think so that my mind is not clear yet. Most of the thick client swing application are used over intranet and rmi is best solution for that. To be more specific we are working on Electronic Medical Recoed System (for US Health care industry). We will be working on single database (no distributed transactions involve) and using swing based thick client over rmi with medium to large concurrent users at a time so our environment is medium to higly transactional. The point i see is that apart from this remoting stuff and performance over rmi .. spring is perfect for our use cases for all scenrios.. we are using hibernate and spring's wn jdbc abstraction. I do not want to use EJB for this application. But we need good performance and our application is co-located and we want to use clustering for performance reasons plus your answer you ignored clustering over rmi stuff.....may be you people can do it.Please take these thinks into account before answering my post. Also please do not mind but if it is not possible then i see little value in spring rcp project and also in most circumstances Spring though THE BEST framework but is only viable for web based solution not for thick clients.. As thick client have to work remotely mostly with RMI as it has very good performance (though server side is usually co-located). I think Rod can ive good arguments too i am confused..Please Help me...


        • #5

          I forgot one or two point that as Ben said in our application we need callback very often (for some jms based reasons). Also my server side beans are co located and do not need distributed transaction.Over current Http remoting i do not think it is possible and as Ben and you siad RMi is definetly best for thick client. The application will not be highly scalable if i use spring rcp and spring framework as clustering is the best way to scale up things and web base spring do support this but not your rcp project.. and i think this goes against the excellent philosophy of spring framework. Whats the point in making spring rcp ..... when it cannot scale up well for the domain (thick client) it is targeting?


          • #6
            First off, Spring and Spring rich client aren't in the business of developing clustering technologies, resource pools, load balancers, or remoting protocols. That's the job for specialized solution providers in those areas, who are experts at it, like for example, Tangosol Coherence, commons-pool, caucho, BEA, etc. Nor is Spring in the business of being an application server vendor or a full-fledge replacement for an application server.

            So because I feel the need to clarify: Spring is an application framework that makes it possible to define a consistent, well-layered architecture on both the client and server side, and scale up or down that architecture in different deployment environents easily. It provides abstractions that address common application problem areas (all building on its core IoC container which can be leveraged in any environment), typically by fostering integration with existing technologies, with the goal of making it easier to build well-layered applications faster.

            Spring rich client shares a similiar goal, focusing on a Swing-based rich client, and IMO makes it considerably easier to develop a Swing app with good separation between UI/domain with considerably less client code you have to maintain in house. There is a lot of value in just that, IMO.

            You seem upset that we didn't give you an alternative to clustering that doesn't involve use of an application server. I'm sorry, I just can't recommend any other solutions in that area outside of that. I personally haven't experienced the war-stories I've read regarding direct use of RMI, but I've tried to outline some of the concerns there (e.g thread pooling.) As I mentioned, you might want to look at a product like Coherence and ask around and see how people are using it to scale their distributed applications. Whatever you go with, you'll still be able to use spring and spring rich client for configuring, bootstrapping, and managing your rich client app and providing a general framework for layering your application and connecting data in domain objects to your GUI controls. That's our focus right now, and I think that's the right focus.


            • #7
              I believe in KISS (keep it simple). The KISS option for most Spring/Spring-RCP solutions needing to scale is multiple HTTP servers with all beans co-located and a load balancer sitting in front of them.

              It seems you'd have two issues with this, given distributed transactions aren't such a problem:

              1. Performance of remoting protocols themselves. Have you actually done some RMI vs HTTP-based remoting protocol benchmarking? Particularly with say the new remoting protocols developed recently by Juergen and Ollie (in Spring Core and RCP respectively)? You could use the Petstore sample application as I mentioned earlier to get some initial idea of the overheads.

              2. A callback or other concurrency management strategy. We don't know your actual requirements. You may be able to simply go for an optimistic concurrency approach if high concurrency is not an actual business issue. Sure, as engineers it's technically interesting to address everything, but doing so imposes considerable additional technical requirements, which translate into money not only with initial development but also maintenance as well as deployment options.

              As mentioned, the trade-off is more a business decision of lower costs throughout the application lifecycle + easy Internet accessibility (web app with web remoting) versus better concurrency handling (RMI with application server). Perhaps your client should be involved in the decision.


              • #8

                I have a swing based client witch interracts with a server via spring rmi, it works greatlly, but when I'm using this solution in a mutli client envirenment, I have some problems, not in tha application but in the dadas stred in tha database witch is a sample derby database, and I'm using iBatis as an ORM, and all my beans implements the Serializable interface, and all by DAO methods are serializable,

                I wanna to know what I must to do ?

                any open source solution, API, or framework, if possible can you give me some small and simple solution just for insperation ?

                thanx from advance !

                best regards !!


                • #9
                  I have some problems, not in tha application but in the dadas stred in tha database witch is a sample derby database
                  pretty vague, not sure what your actual problem is. I would guess this says you have a problem in the data threads in the database? Are you using something like dbcp or c3p0 in order to mange your database connections?

                  say something like this:
                  <bean id="dataSource"
                        class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
                    <property name="driverClassName" value="${jdbc.driverClassName}"/>
                    <property name="url" value="${jdbc.url};databaseName=${jdbc.databaseName}"/>
                    <property name="username" value="${jdbc.username}"/>
                    <property name="password" value="${jdbc.password}"/>
                    <property name="testOnBorrow" value="true"/>
                    <property name="validationQuery" value="select 1"/>
                  with so little to go on its hard to tell if this will help though.


                  • #10