Modular service architecture [ was Re: xml-rpc messages ]

[Kevin Ross]

BTW, one GREAT advantage to a common service interface, is the ability to create on JUnit tests once for both the client and the server component.  In addition, based on configuration, the 'Service' interface could be instantiated as a local or remote service based on configuration.  Going down this road, they could also be pooled!

Oh yeah, did I mention, the iverticalleap java.core project already does this for you (@see http://www.iverticalleap.com/java.core/index.html)?  There isn't much documentation, but the project has been in production use as is for a while, and the codebase has been around for years.  At least take a look at my configuration doc with particular attention to services, it my give you some ideas (@see http://www.iverticalleap.com/java.core/configuration.html).  Of course, this project was built with business systems in mind, not server systems, but I think the issues we are attempting to tackle (modularity) are common.

-Kevin Ross

FYI- if your interested, go for the cvs version @see http://www.iverticalleap.com/cvs.html

Kevin Ross wrote:

For the most part, I agree.

For example:

- xindice    
    - core // all real code not interfacing with outside protocols goes here.
         - supporting server classes
    - service
         -XPathQueryService // interface
         - xmlrpc
             - XPathQueryService // xmlrpc implementation implements top level interface, calls core classes
    - client
         - xmlrpc
             - XPathQueryServiceClient // xmlrpc implementation implements top level service interface, calls service implementation
    - util

-Kevin Ross

John Wright wrote:

What bothers me a little is that in a class placed in the client
    

package, > you
  

will have to import org.apache.xindice.SERVER.rpc.* classes.  Should a
    

client
      

_import_ server classes, that's my question?  I don't particularly
    

like this
  

idea, but it's maybe me.  
    

That's the reason why I thought of moving the server.rpc classes into
client.xmlrpc.  And since I don't have many classes left in the server
package, I thought of removing the server package and define the
    

"accessor"
  

(name to be changed) hierarchy.
    

Is XML-RPC similar to Java's RMI as far as the general usage structure
(define interface, locate service/object, call methods using stubs)?

If so, the cleanest and most modular way to write this is to have 2
packages.  The first is the server package, which consists of the
interface, the interface implementation, and the server binding class.
The second consists of the interface and the client.  Then, the client
only needs to import the necessary classes for XML-RPC and the
interface, providing a package level separation between the client and
the server with the interface bridging the parameter marshalling gap.

(A similar design was discussed by the writers of "Core Java", in which
they are using RMI to provide the client/server binding)

John