Results 1 to 3 of 3

Thread: Convention over configuration

  1. #1
    Join Date
    Nov 2007
    Location
    Netherlands
    Posts
    36

    Default Convention over configuration

    I am designing the dao/service layer plus remoting layer of our app; trying to adhere to the DRY principle by using convention over configuration.

    I can already automatically instantiate all service beans in one package using component-scan and autowiring for injecting the DAO's.

    I am exposing the service like so:
    Code:
      	<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
    		<property name="service" ref="personServiceImpl"/>
    		<property name="serviceName" value="PersonService"/>
    		<property name="serviceInterface" value="nl.huizemolenaar.obliprototype.service.IPersonService"/>
    	</bean>
    And at the client side create them like this:
    Code:
    	<bean id="personService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
    		<property name="serviceUrl" value="rmi://${remote.server}/PersonService" />
    		<property name="serviceInterface" value="nl.huizemolenaar.obliprototype.service.IPersonService" />
    	</bean>
    Is there an easy way to automatically expose all services in the package, and being able to automatically use them by their name at the client side?

    Example: I create a new ReservationService on the server side. I make a GUI bean that expects an IReservationService. I can directly inject the remote service by injecting the bean with the name "reservationService" without having to adjust the xml files.

    Related question: I may create a lot of services; in the worst case one for each domain entity. Should I expose a new RMI Service for each of them, or should I make a single service for them all?
    How can I still inject them by name on the client if I go this way?

    Finally, I will probably also use both service/client side transparent caching with ehcache or jcs; it would be nice if this was done automatically too so I can still inject them by name.

  2. #2
    Join Date
    Nov 2006
    Location
    Calgary
    Posts
    15

    Default

    For doing caching transparently you can use Spring Modules and ehcache ( that seems to be the combination people have had the most luck with - me included). You can set it up so it creates a proxy of your service (on client or server) and then tell it which methods get cached and which methods flush the caches, etc.

    I don't know of a way to automatically create RMI services from your beans. Perhaps it would be possible to create a custom Annotation to do so (I have no experience in this area - so just guessing).

    Not sure of a best approach - we went for a monolithic single service initially out of convenience but it has a number of downsides. We would get weird (weird in the sense that they were resolvable before doing AOP on the service) circular dependency issues when we set up caching using AOP. In the end we split into a few services to break the circular dependency issue. We do plan on breaking things up further once its clearer about which functionality belongs together - but I highly doubt we will break it up to the domain level.

  3. #3
    Join Date
    Nov 2007
    Location
    Netherlands
    Posts
    36

    Default

    Thank you, we already found the caching part.

    I found a way to create extra beans in a Spring context by implementing a custom BeanFactoryPostProcessor and using the factory.registerSingleton method. I could use some custom reflection code to automatically add beans. Not sure if this is the correct way to do it though.

    To automatically add a caching/rmi proxy to a Spring instantiated bean I could write a custom BeanPostProcessor.

    (Maybe this is automatic for caching if we add caching with annotations.)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •