aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI server interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RMI server interfaces" Watch "RMI server interfaces" New topic
Author

RMI server interfaces

Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

yes, i know, this was discussed A LOT here.
I've read some post about it and so far the best approach was this:
(i think it's roel's solution)



now since the same code is used in both local and remote server
you'll end up with two exact classes (with the only difference -
RemoteException in the declaration of every method) so i thought
about some code re-use:






another possibilty would be for local/remote server to use a HAS-A relationship
instead of the IS-A relationship:







this is just a scratch, i didn't even try to compile it, i just wanted some
advice/enlightenment from you guys....


SCJP 5, SCWCD 5, SCBCD 5
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Howdy, Jonathan!

Well champ, I personally don't like when an interface is empty because it really looks like a bad design. How about something like this:



I personally think this design is more flexible and cohesive. It is similar to your first proposal, but with less code and a bit more cohesive. If, in the future, you need to create an implementation for Sockets (for some reason) or any other thing, you can easily do it with the design proposed above.

What do you think, champion?

[EDIT]: BusinessException and RemoteException added to the BusinessModel interface. If RemoteException is not listed in the list of exceptions, then extending LocalBusinessModel class to implement Server won't work.

[EDIT2]: RemoteBusinessModel should extend LocalBusinessModel. A class extending an interface doesn't make sense.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

it's not really empty, it's just not adding any methods.
it act just as a marker (like the serializable and Remote interface)
i could add the method explicitly:



now to your suggestion:
in your design the local business IS-NOT-A server..

secondly (and the reason so much people had question about this topic)
methodA ans methodB doesn't throw RemoteException in BusinessModel interface.
(and if they do then it's almost the same as roel's solution with few naming changes.
also, in your design the local business would have to deal with remoteexception..).

anyway, at the end you'll have to code 2 implementation with exactly the same logic..
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Howdy, Jonathan!

in your design the local business IS-NOT-A server..


Exactly. It isn't a server... why should it be? Since it is supposed to be used only locally, then it shouldn't be a server anyway.

secondly (and the reason so much people had question about this topic)
methodA ans methodB doesn't throw RemoteException in BusinessModel interface.
(and if they do then it's almost the same as roel's solution with few naming changes.
also, in your design the local business would have to deal with remoteexception..).


I forgot to include RemoteException in the methods of the BusinessModel interface. However, this exception will only happen in the remote environment. It's not because you declare an exception in an interface that you have to throw it in the implementation: declaring the exception means that the method may throw the exception, not that it has to. So, where you have to deal with RemoteException (say, an ActionListener), then you handle it there... it will certainly only happen in the remote environment, never in the local environment.

anyway, at the end you'll have to code 2 implementation with exactly the same logic..


I believe that, with the design I proposed, you'll have less code. I think that, in your proposal, you have one more class, and two implementations that get overriden... right?
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

correct me if i'm wrong, but don't you have to implement two exact same find() methods, say, in both local and remote businessmodel?

what i tried to do is to separate the implementation (which is the same) and put it in CoreServer.
this way i wont have to do copy-paste any time i change a function...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

If you have 2 exact implementations depends on the interface of your Data class. For example in my case these implementations have some slight differences, but it really depends on your interface And I know people just created 1 implementation and used this implementation for local and network mode. So you'll need at least 1 interface and 1 implementation of this interface.

I would not create a seperate local business service, because that's quiet a useless interface. Your client will work with the Server interface and not with LocalServer and RemoteServer.

Roberto Perillo wrote:Exactly. It isn't a server... why should it be? Since it is supposed to be used only locally, then it shouldn't be a server anyway.

What's in a name? That's just an argumentation based on the name he gave that interface (and is not a valid argument in my opinion). If he would have called this interface BusinessService for example (instead of Server), it makes more sense because both locally and remote you want the same business service (and logic) implemented.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Jonathan Elkharrat wrote:correct me if i'm wrong, but don't you have to implement two exact same find() methods, say, in both local and remote businessmodel?


Well champion, that's the beauty of this design: with it, you only need one implementation of the business methods and they will work for both the server and client side!

Defining the methods of the interface with RemoteException allows us to create a class that implements the interface that extends Remote and extends the class that implements the interface. This way, when you want to use the local class, you just have to say somewhere new LocalBusinessModel(); and when you want to use the remote implementation, you start the server (that is, the class that extends the class that implements BusinessModel and implements the interface that extends Remote) and get it in the client side via Registry. The same implementation will work for both sides!
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

i know, but the find() logic will exist in 2 classes. suppose i find a bug while using a remote client, and i'm changing the
RemoteBusinessModel i must not forget to do the same changes in LocalBusinessModel, right?

or i'm missing something here...



if it depend oon me i would have used only one server, directly from the JVM or publishing it
through the RMI registry. all this workout is because of the Remote interface implementation
and the (mandatory) RemoteException that break the simple interface design...
it's not like in EJB local and remote, the publishing and exportation of the remote server is
done (well, at least it's my plan right now) outside the server. (e.g. the main method)


ROEL:
a local server interface may be used instead of the super-interface "Server" to avoid the
remoteexception. though in this specific exercise it's not useful, the same GUI client must
be used for both local and remote connection
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Jonathan Elkharrat wrote:i know, but the find() logic will exist in 2 classes. suppose i find a bug while using a remote client, and i'm changing the
RemoteBusinessModel i must not forget to do the same changes in LocalBusinessModel, right?

or i'm missing something here...


Well champ, I don't get it... the find() logic will exist in only 1 class, and thus, you'll be able to work in only one place... why would it exist in 2 classes
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roberto Perillo wrote:




no?

Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Howdy, Jonathan.

Well champ, I'm very much sorry for the typo The correct code would be:



A class extending an interface doesn't make sense. If your remote implementation extends the local implementation, then you'll just have to implement eventual methods that are related to the server (e.g. startServer()).
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

nice.

with your design the local implementation still have remote exception in it, and
that's what i wanted to avoid.
since both local AND remote contains RemoteException you could merge them
to one class..
well, at least in my design, because i intend to use the same methods and logic on
both classes. any specific configuration (exportation and such) would be handled externally...

something like that maybe:

if(args[0]=="alone")
Server=new LocalServer();
else
Server=//get reference from remote registry.
passServerToGUI();
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Jonathan Elkharrat wrote:with your design the local implementation still have remote exception in it, and that's what i wanted to avoid.

And you want to avoid that for which reason? What benefit would you have with avoiding this?

If you really want to go down this road, you'll have to opt for something like the code snippet with the CoreServer you provided. This class contains your business logic, both the local and network implementation will use an instance of this class and delegate their methods to this instance. But I really don't see any benefit of this approach. But it's ok and you should prefer composition above inheritance (so that's why I opt for this alternative instead of the one suggested by Roberto)
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roel De Nijs wrote:
And you want to avoid that for which reason? What benefit would you have with avoiding this?


there's no benefit, at least not in this assignment since the client always have to deal with the super interface and its remote exceptions.

but that aside, if both classes do exactly the same thing and throw exactly the same exceptions, i couls use only one class for
both local and remote use...


Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Jonathan Elkharrat wrote:there's no benefit, at least not in this assignment


Well champ, is there a place where there is some benefit?

Jonathan Elkharrat wrote:but that aside, if both classes do exactly the same thing and throw exactly the same exceptions, i couls use only one class for both local and remote use...


Well, indeed, there are two classes, but there's code in only one of them, so there is no duplicate code (duplicate code always reflects bad design).

One option would be to do what you said (as long as the server code isn't used in standalone mode), but this wouldn't be a cohesive design. It is cleaner to keep things separate. I honestly don't see anything wrong with having RemoteException in methods of an interface that doesn't extend Remote. You'll have something similar to this in the end of the day:

Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roberto Perillo wrote:
Well champ, is there a place where there is some benefit?


suppose some day someone want a reference to the server locally, he could create a LocalServer=new LocalServerImpl()
and with his interface he don't have to worry about remote exceptions...



and i didn't fully understand this:
Roberto Perillo wrote:
(as long as the server code isn't used in standalone mode)






by the way, this won't compile:
Roberto Perillo wrote:



since the extending class (RemoteBusinessModel) throws an exception that doesn't exist in the super...
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Jonathan Elkharrat wrote:and i didn't fully understand this:
Roberto Perillo wrote: (as long as the server code isn't used in standalone mode)


Well, it's just that the server code must be entirely bypassed in standalone mode, since this causes automatic failure.

Jonathan Elkharrat wrote:by the way, this won't compile... since the extending class (RemoteBusinessModel) throws an exception that doesn't exist in the super...


You mean, RemoteException (your nightmare )? It will compile! The exception just has to be listed in the interface, champ... in the concrete class, you don't have to include it in the list of exceptions that the method may throw.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Roberto Perillo wrote:Well, it's just that the server code must be entirely bypassed in standalone mode, since this causes automatic failure.

Just to avoid confusion, the instructions clearly state: Keep in mind that networking must be entirely bypassed in the non-networked mode. So networking must be bypassed, not the server code.
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

ad roel stated, only networking should be bypassed. the logic can still be the same for both interface.

since i can use the same logic, and the local class that roberto used contain RemoteException, ill ask
this way:
what can't i also implement Remote (indirectly) and then use the same class for both purpose? (or can i?)

Jonathan Elkharrat wrote:


there's nothing wrong in this design (i think).
i can use ServerImpl as a local class (roberto's local class has exactly the same method signature)
and export it for remote use since it's also a Remote implementation and throws RemoteException anyway...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

I would not opt for this approach, but that's just because you tell now that Server IS-A Remote which is not really true. So the design is not wrong (it will work and you'll pass), but it's not for the 100% correct.

Therefor I would opt for this design (and use a ServerImpl instance for both local and network mode):
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roel De Nijs wrote:I would not opt for this approach, but that's just because you tell now that Server IS-A Remote which is not really true.


why? because when you are using it locally you're not using RMI? it's not wrong.
as i saud, the Remote interface act as a marker. think of it as the Serializable) interface, just because
a class implement Serializable doesn't necessarily mean that it'll be serialized every method return.
it says that this object can be serialized. the same goes for the remote, this class can be used remotely.
(espescially since all it's methods throws the RemoteException anyway, which is the only requirement from
a Remote interface)

Roel De Nijs wrote:
So the design is not wrong (it will work and you'll pass), but it's not for the 100% correct.

Therefor I would opt for this design (and use a ServerImpl instance for both local and network mode):


i didn't quite catch the difference here.
if you add an interface along the inheritance/implementation chain it doesn't change the fact
that ServerImpl IS-STILL-A Remote (which is not wrong, based on what i said before)

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

In my opinion Server (the business service) is not a Remote. I agree it's just a marker interface, but the IS-A relation does not apply. But that's just my opinion, you don't have to agree with it and you can take the approach you described a few posts above. That will be just fine.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Roel De Nijs wrote:In my opinion Server (the business service) is not a Remote. I agree it's just a marker interface, but the IS-A relation does not apply. But that's just my opinion, you don't have to agree with it and you can take the approach you described a few posts above. That will be just fine.


Agreed. The thing is that, as I said earlier, it is better to keep things separate in order to have a cohesive design. But, as my good buddy Roel said, the final decision will be yours. You already have our opinion, now just make your decision and justify it in your choices.txt file.
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

looks like i'm not the only one who have thought about "one class to rule them all"..
http://www.coderanch.com/t/180079/java-developer-SCJD/certification/RMI-blues


i'll tell you guys soon my decision

many thanks, Roberto & Roel..
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Interesting read guys. I look forward to seeing what you have decided on Jonathan.

I looked at the thread that you referenced and the guy had this code snippet



He was suggesting that this approach was good because:

So, myDataObject can be used transparently in the client, without having to bother about the mode.


So I'm wondering where you got inspiration from this. Because this doesn't sound like a good design, where ServerImp IS-A RemoteInterface. It doesn't make sense to say that a local mode is remote.


SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Sean Keane wrote:So I'm wondering where you got inspiration from this. Because this doesn't sound like a good design, where ServerImp IS-A RemoteInterface. It doesn't make sense to say that a local mode is remote.


That's the point, Sean!

There will be one time where it will be necessary to verify if the application is running in standalone mode or in networked mode, which is when the application starts. Then, it is necessary to open the appropriate configurations window. From there, the ActionListener that listens to the OK button of the configuration window already knows what is the business class that has to be passed to the main window: for instance, the StandaloneConfigurationOKButtonListener instantiates the LocalBusinessModel class and the ClientConfigurationOKButtonListener gets the remote implementation from the server.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Sean Keane wrote:So I'm wondering where you got inspiration from this. Because this doesn't sound like a good design, where ServerImp IS-A RemoteInterface. It doesn't make sense to say that a local mode is remote.

That's why I don't like the 1 interface design, I opt for the 2 interfaces: 1 business interface containing your business methods (every method throws a RemoteException besides the necessary business exception) and a remote business service (which extends the business service and the Remote service with no extra methods). So in your client you can use the BusinessService interface as type for the myDataObject. Because I believe that's the more elegant design, I implemented this one
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

the key point here is that the interconnection between the DAO and the Server are EXACTLY the same, no matter what mode you use..

the only difference is HOW to get to this server, and this has nothing to do with the interface you create/implement, it's done externally.
(for those who have passed SCBCD, think of it as a stateless EJB interface that can provide also webservice access with @WebService.
there can be multiple way to access one interface.)
of course, as roberto mentioned, if you use specific remote code in your class (which shouldn't be there in my humble opinion) you are
indeed forced to do a separation somewhere...

now you people are right that this design limit extendibility. imagine someday the manager want the guys in the company do some CRUD
tasks, but of course it shouldn't be visible to the outside. you'll have to separate the local and remote interface (but not necessarily the implementation class)

but the only time they mention thinking about future change is in the client's view, which is why most people opted for the MVC pattern....

Roel De Nijs wrote:
and a remote business service (which extends the business service and the Remote service with no extra methods)


so the only thing you gain with the remote interface is a marker..









just to be clear:
there's no argument that in real life i'll probably won't use this design, because of the limitation in future change.
the question arose given the simplicity of the assignment and the "good" approach would end up with more empty
interfaces and duplicate classes...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Jonathan Elkharrat wrote:so the only thing you gain with the remote interface is a marker.

And the code in your client will look a bit less weird The interface you use in the client code has not a dependency on the Remote interface.



Jonathan Elkharrat wrote:there's no argument that in real life i'll probably won't use this design, because of the limitation in future change. the question arose given the simplicity of the assignment and the "good" approach would end up with more empty interfaces and duplicate classes...

I didn't have that problem because my local and remote implementations are (slightly) different.
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roel De Nijs wrote:
And the code in your client will look a bit less weird The interface you use in the client code has not a dependency on the Remote interface.


could you please elaborate on that? i dont think i understood...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Jonathan Elkharrat wrote:could you please elaborate on that? i dont think i understood...

I tried to show this in the code-snippet in that post If you have 2 interfaces, you'll use the business service in the client (and the server), the remote business service will only be used at the server. Your client will not have a dependency on the Remote interface. And if you need to develop another implementation (based on let say web services) you can implement the business service interface, the remote business service is only needed if you want to use RMI (so I would only use that in that scenario).
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

I think this is a long discussion. But, as a final consideration, let's think for a while. Here, we have to develop a client/server application that must follow some "musts" using Java and object orientation. A question: could we do everything in only one single class (that would be a big one, which would do everything)? The answer is yes. But, why are we discussing how many classes or interfaces there should be? The answer is, because we would like our design to be as clear and object-oriented as possible. Is it possible to create only one interface and only one class and use them locally and remotelly? The answer is yes, it is. But, this design won't be as clear and object-oriented as it could be. I do believe that, if this decision is made, some OO principles will be "injured" (i.e. IS-A, OCP, LSP, single responsibility and some others).
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

ROEL:
with my 1 interface it would be exactly the same instantiation:


and an if(isRemote) would only export this to the RMI registry (so external clients
would also benefit from this server)
if it's local - no extra steps are needed. anyhow, the client will get a Server instance..

Roberto:
did you write 2 DAO classes, one for the remote and one for the local? no. why?
because it's the same for both. idem for domain classes, same for both. so as far as no
special functionality is required from one mode, the easiest and most elegant way
is one class (and i even think it would be easier for a java beginner to understand
than some extra classes and interfaces that do the same job)
and it's not a BIG class, it's just merging two identical class into one..





but i think i'll stick with the 2 interfaces (the first one i proposed in my first post, i think it's roel's solution too)
because it's a safe bet. (i only have 1 try to submit)
of course i'll write the 2 options in my choices.txt and i'll say that i opted for this solution
because it a better programming approach and easier to extend in the future.
and it'll probably give more points.. well, maybe i won't write that last sentence in my choices.txt
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5534
    
  13

Jonathan Elkharrat wrote:but i think i'll stick with the 2 interfaces (the first one i proposed in my first post, i think it's roel's solution too)
because it's a safe bet. (i only have 1 try to submit)

Don't forget that my solution has 2 interfaces and 2 implementations, because the "server" used in standalone mode is slightly different to the "server" in network mode. You should not use someone else's approach in your application, simply because it's a safe bet (because that approach passed), because your solutions might differ. Although I'm quiet convinced you won't fail because you use 1 or 2 interfaces (worst case scenario would be just losing some points).
But I still think it's not a good idea to have a dependency on the Remote interface, for the simple reason it's definitely a RMI-specific interface. So in my opinion this dependency should just stick in the RMI part of your application, and not throughout the complete application. Your client should not know it's talking to a "server" through RMI. And before you throw it in my face: I know each method must throw a RemoteException, so you have already a RMI-specific dependency

It has become a very big thread about a minor issue, so I would make your decision and let it rest
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

i must use a super-server interface, that's a face.
i also don't want the localServer to extends Remote (this is the Safe bet i was talking about)
so i got 2 sub-inteface for Server, hence 2 implementation.

which result in:
1 Super interface
2 Sub interfaces
2 Implementations
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Jonathan Elkharrat wrote:i must use a super-server interface, that's a face.
i also don't want the localServer to extends Remote (this is the Safe bet i was talking about)
so i got 2 sub-inteface for Server, hence 2 implementation.


Hum... I think there's something wrong. You should have 1 interface with the business methods throwing RemoteException and business exceptions, 1 sub interface for the server extending Remote, one class that implements directly the super interface and another class extending the class that implements the super interface and implements the sub interface... you shouldn't have 2 sub interfaces...
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

I know Roel mentioned this thread is getting quite long. But just to let you guys know I am following it and find it interesting.

I'm sure, as Roel pointed out, many of the solutions mentioned here could be used and you will pass the exam.

But it is interesting none the less to see different ideas in the context of something you are working on. Rather than just reading about some "toy" example in a book. For me anyway, I like it, as it will provide me with many ideas, designs, and possible solutions for "real world" problems going forward.

That's what this assignment is all about for me. Toying about with ideas. If I simply wanted to get it done and pass I'm sure I could have "used" a lot of the ideas from Andrews book and had it wrapped up a long time ago
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Roberto Perillo wrote:
Jonathan Elkharrat wrote:i must use a super-server interface, that's a fact.
i also don't want the localServer to extends Remote (this is the Safe bet i was talking about)
so i got 2 sub-inteface for Server, hence 2 implementation.


Hum... I think there's something wrong. You should have 1 interface with the business methods throwing RemoteException and business exceptions, 1 sub interface for the server extending Remote, one class that implements directly the super interface and another class extending the class that implements the super interface and implements the sub interface... you shouldn't have 2 sub interfaces...


i added a local interface that
1. suppress the RemoteException from method signature
2. could be used (sometime in the future) to add local-specific method. this is quite
the same reason i separated the remote-server-interface..

the more i think about it the more the one interface-one implementation seem natural to me. i hate being indecisive...
Jonathan Elkharrat
Ranch Hand

Joined: Dec 31, 2008
Posts: 170

Sean Keane wrote:

He was suggesting that this approach was good because:

So, myDataObject can be used transparently in the client, without having to bother about the mode.


So I'm wondering where you got inspiration from this. Because this doesn't sound like a good design, where ServerImp IS-A RemoteInterface. It doesn't make sense to say that a local mode is remote.


this is the point. the server shouldn't know about whether he is a remote or local.
imagine you have a pizza store. you get orders both from local clients and by phone.
but your work is the same for both.
the worker (JVM/RMI) is the one who know where to deliver each pizza (record)..

just to emphasize, Remote interface doesn't have a method. making a class implement remote simply means its
method can now be accessed remotely (it's the equivalent of buying telephone for your pizza store).
the fact that the pizza have a telephone doesn't mean you always have to pass orders by the phone..
or simply put: Remote is just a "marker" interface (like Serializable).

by the way, implementing an interface is not exactly IS-A (as in extending a class).
it just says: "i can provide the functionality listed in that interface"...


so at startup i start a serve anyway. if it's local, nothing more to be done, just pass the reference to
the standalone client. if not specified local (not standalone mode) i'll put it in the RMI registry so it will
be visible to remote client. the type of the server shouldn't change, and the communication isn't handled
by the server anyway..
Hau Nguyen
Greenhorn

Joined: May 09, 2011
Posts: 7
Thank all you guys very much for this topic, this also helps me a lot.

If anybody is forum moderator, please help me to delete my newest post as it is cross post. I am sorry.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI server interfaces