rmi an interface or an abstract class ?

[luc ndabaneze]

hi everyone
i have a client class that i want to access objects remotely from several sources (client java class slave)
as those sources are doing different things they cannot shares the same interface from which the client can ask for service , because they would have to implement all the methods declared in the inteface.
so i 'd like to know one thing
can i create more than one interface and bind the server to each or should i create an abstract class that implements the interface and child classes for each service i want?

[Nathan Pruett]

You could do either one... I think I'd need more specifics to give any opinion on if one or the other would fit the situation more, though.

[luc ndabaneze]

hello Nat

thr reason why i wanted to create more than one rmi server is because i want to control the amount of job sent to a processor, so i partitioned job into small chunks and sent to differents processors. i guess my question is if a abstract class implements the interface and its children instantiated depending on the method you calling
would work on rmi?
or
in the alternative way does RMI support registering more than one server at the time?
thanks

[Nathan Pruett]

It sounds like the problem you are having deals more with the partitioning of the job among multiple servers rather than the abstract class/interface issue. In RMI only one server can be registered under any one name. Jini would fit much more with what you want, because you work more with groups of services that fit an interface you are looking for, more than looking for a specific service using a name it is registered under.

If you use RMI, though, it sounds like you would need to do something like this... have one or more "client"s and one or more "processing server"s, and one "controller server". The "processing server"s deal with actually doing whatever process you need to do, but the client doesn't deal with them directly. "processing server"s register with the "controller server" to be put into use, and the "controller server" keeps track of all of them, which are busy, which are available, etc. "client"s only connect to the "controller server", the "controller server" then either uses multiple threads to delegate processes out to the "processing server"s and then passes results back to "client"s using callbacks, or it passes a remote reference to an available "processing server" back to the "client" and lets the "client" then call the "processing server" directly.