Announcement Announcement Module
Collapse
No announcement yet.
Best practice for distributing interfaces for use with remoting Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best practice for distributing interfaces for use with remoting

    Hi,

    I wonder what is the best way to distribute my interfaces for use with remoting ACCORDING to the Spring philosophy.


    For example, I have the following interface with corresponding implementation:

    net.valudo.manager.AddressService (interface)
    net.valudo.manager.AddressServiceImpl (implementation)

    Now I decide to make the interface AddressService accessible for remoting. With Spring I just have to change the code in my XML-files to make a remote interface out of AddressService.

    But now the remote client application has to know about this remote interfaces. So I have to copy AddressService to the remote client application.


    1) I can copy the remote interface AddressService separately to the client. But in bigger projects, I would have to copy a lot of separate interfaces from different packages to the client. Pretty tedious!!!

    2) I can move the remote interface AddressService (and all other remote interfaces) to a new package (for example: net.valudo.remoting.AddressService) Then I make a JAR out of this package and copy this JAR to the client.

    But then I "hard code" into my package structure, which interfaces are intended for remoting. Wich is, as far as i know, AGAINST the Spring philosophy.


    I hope, you got my "little" problem.

    So what is the best practice to distribute interfaces for remoting - according to the Spring philosophy?

    thx
    chris

  • #2
    My experience with Spring is that Spring rarely invents anything. I'm not saying this as a criticism or as something negative. Its the nature of Spring. Spring is mostly built about sound design patterns like IoC, Template, Service Locator, Strategy, MVC, et. al. and principles like Domain Driven Design, Test Driven Design, etc. It uses all of this (and anything I may have missed) as guiding principles. They are not quite a single philosophy, more like guidelines. As a result they are not always complete, or they rely on other established philosophies, or intend to fit into an organization's philosophy. Spring doesn't replace anything, meerly enhances it.

    I put such a fine point on this, because I don't feel Spring has a philosophy per se, other than to use the principles that it sprung from. You can do pretty much everything Spring espouses without actually having to use Spring. The reason you use Spring is because it makes fitting everything together easier.

    Package organization is one of those things I don't see covered by Spring at all. Spring itself seems to use a package structure that reminds me of Java. That isn't surprising since its a framework, a library. Applications often have different considerations (like remoting) so their package structure often differs. And because package structure differs according to the need of the application, Spring probably leaves it to the user to figure out what's best for them.

    I can give you my take on it, which is strongly influenced by Spring principles. I think your concern about having some components being grouped by how its called is valid. But I think making a split between implementation and interface is okay because you are basically expressing that your application may be called some other way than locally. That its potentially a remote API. It doesn't dictate which interfaces are remote or local. Meerly that any of them can be. What DOES dictate which ones are remote and local is the configuration files. You basically will have 2 sets of files: the server side and the client side. The server side really also covers the "local" side. By having two sets you can even name your beans in both sets the same, so in case you convert your remote code to local you really only have to make build changes.

    As a side note: You don't have to put ALL interfaces in the client package. In some of the code I've developed, some of my interfaces and associated classes were created for the implementation of another service. Not meant to be used externally. So I put all of these files in the "implementation" part of my packages, since that is what they are used for: implementation.

    HTH

    Comment


    • #3
      Hi Bill,

      thanks for your detailed explanation. I think I got the point.

      thx
      chris

      Comment


      • #4
        Just a quick note. If you expose your services through SOAP your clients can generate the client libraries from the service descriptor and you dont need to distribute anything.

        In the application I am working on I also generate a client.jar which simply contains my interfaces (excluding anything internal to the server) and my domain objects, exceptions etc..

        Comment

        Working...
        X