• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The Server

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all!

A couple of questions regarding the design of the server:

I think that the client should always access the database via the server and that the client should not be aware if it is a local or remote server.

This makes me want to design the server side with an abstract class Server with two subclasses NetworkServer and NonNetworkServer. The NetworkServer must also implement the Remote interface (for RMI). I would also like NetworkServer to extend UnicastRemoteObject but to be able to do that I need to make the abstract Server class an interface instead (which I feel is not 100% correct object-oriented coding design, or am I wrong at this point? I mean, the NetworkServer and the NonNetworkServer are a server so it feels right to make Server a class instead of an interface.)

Also, to hide which server the client is using I need to declare all accessable methods in the Server class/interface. The problem is then in the NetworkServer class since its methods need to be declared with the "throws RemoteException" which is not possible to add to the already declared methods in the Server class/interface.

I could declare all the methods in the Server class/interface to throw RemoteException since the client won't know if the server is a NetworkServer or not so it must always do a try{...} catch (RemoteException remoteException) {...} when calling methods on the server side, even when accessing the local server.

However, I'm confused about four things:

1. Is it correct to make the Server class an interface instead in order to make it possible to extend UnicastRemoteObject in the NetworkServer class?

2. Is it correct to declare all methods in the Server class/interface to throw RemoteExceptions? Even when the server is a local server? If not, how should it be done so that the client does not need to be concerned with the type of the server?

3. It feels as the connection to the database will be the same regardless of the type of the server. Do I then really need to make two types of servers? Wouldn't it be easier to just have one Server class which extends UnicastRemoteObject and implements Remote? Yes it would, but then I would go againt the rule that I'm not granted to use the network server code in a local server. Or is it ok if the server is created with Server server = new Server(dbFile); instead of the RMI-looking-up code?

4. If the NetworkServer would use the NonNetworkServer code when accessing the database, is it then illegal to use the NonNetworkServer code when using a local server since the SCJD text says that it is forbidden to use the network server code at all in the local server mode? Where to draw the line of which code is included in the network server code? For instance is the abstract class Server (or interface) which declares all public methods for the client to call, is that code included in the network server code and therefor fobidden to use in the local server code?

Feedback on my thoughts are appreciated ;^).

Regards,
Henrik
[ January 05, 2006: Message edited by: Henrik Strand ]
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Henrik,

Welcome to JavaRanch and this forum.

It sounds to me like you are trying to use a Factory on the client side, and just trying to work out how to get the RMI bit to work within the Factory - have you considered an Adapter at that point?

So the factory side might look like this:



Note: I only said "might" because I have simplified this diagram a bit from common UML diagrams of factories, and patterns are just that - they are patterns which will "look similar" to each other - they are not cast in stone definitions of what a Factory must be.

So your RMI version of "RealConnector" would then become an Adapter, converting anything RMI specific into something that is "Connection" generic. For example, you might decide to have your methods in Connection all throw DatabaseException - that way you could wrap any RMI exceptions inside the DatabaseException: your GUI client will know how to handle the generic DatabaseException, so you have maintained a clear seperation between client and server.

Does this make sense?

Regards, Andrew
 
Henrik Strand
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm...Now I'm a bit confused...

My server side:
I have an interface Server and all its methods throw IOExceptions. I also have an interface RemoteServer which extends Server and Remote. There is then two Impl classes: ServerImpl which implements Server and RemoteServerImpl which extends UnicastRemoteObject and implements RemoteServer. However, RemoteServerImpl narrows the throwing on all its methods to only declare to throws RemoteException. The RemoteServerImpl then has an instance of a ServerImpl and only acts as a wrapper and forward all method calls to the ServerImpl instance.
(sorry if it reveals to much for others...then please delete it...)

The client side gets access to the RemoteServerImpl by calling:
server = (RemoteServer) Naming.lookup(remoteServerName);

and the ServerImpl by calling:
server = ServerFactory.getInstance().getLocalServer();

These are the only two places where the client knows the type of the Server. In all other cases it just calls server.doSomething();


Question #1: Is the server side design ok when considering the requirement "non-network-mode...must not use the network server code at all" since when in networking code the remote server will use the ServerImpl instance which will also be used in the non-network mode (i.e., the ServerImpl, not the RemoteServerImpl).


Question #2: Is it ok that the client knows which server type it gets from the two different method calls? If not, how else is it possible to make the client totaly unaware of the type?


Question #3: Sun has a graphics repository (http://java.sun.com/developer/techDocs/hi/repository/) that anyone is free to use. I feel that their icons could add some value to the GUI =). However, one is supposed (according to their license agreement) to add the license file to the application. Would I violate any must-issues in the assignment (e.g., The JAR file must have the following layout and contents in its root)?


Question #4: My submission should be packaged in a single JAR file which must contain the executable jar file runme.jar. However, is it stated anywhere which name the submitted jar file must have?

Regards,
Henrik

PS. Just found this site:
Design networked applications in RMI using the Adapter design pattern (http://www.javaworld.com/javaworld/jw-05-1999/jw-05-networked_p.html)
Figure #2 looks very familiar

[ January 09, 2006: Message edited by: Henrik Strand ]
[ January 09, 2006: Message edited by: Henrik Strand ]
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Henrik,
  • Henrik: Is the server side design ok when considering ...


  • Yes, it is fine.

  • Henrik: Is it ok that the client knows which server type it gets from the two different method calls? If not, how else is it possible to make the client totaly unaware of the type?


  • I believe this is OK.

    If you really wanted to try and make the client less aware of the connectivity type, you could make a singleton connection factory which would have the connectivity type set by the main method of your application (since your main method must parse parameters, and therefore it knows what mode it is in). Your lower level classes will then just call some method on the factory which will (behind the scenese) either make a network or local connection - but the lower level classes wont be aware of any of that.

  • Henrik: Sun has a graphics repository (http://java.sun.com/developer/techDocs/hi/repository/) that anyone is free to use. I feel that their icons could add some value to the GUI =). However, one is supposed (according to their license agreement) to add the license file to the application. Would I violate any must-issues in the assignment (e.g., The JAR file must have the following layout and contents in its root)?


  • I believe the Sun instructions state what you must have, but don't specify that you can't have more. So I think you can use those graphics. I did use them in my Fly By Night Services assignment, and got full marks for my GUI.

  • Henrik: My submission should be packaged in a single JAR file which must contain the executable jar file runme.jar. However, is it stated anywhere which name the submitted jar file must have?

    From the JavaRanch SCJD FAQ:


  • How should I name my submission jar file?
    The website where you will perform the upload has these directions in the upload screen, but here is a quote from that page
    The name of your submission archive file MUST be derived from your Testing ID, as shown above. Your Testing ID is your 9-digit Social Security Number (U.S. only), or it might be another alphanumeric combination, e.g. sp1234567 (any country).
    Your archive filename MUST BE scjda-AAAAAAAAA.ZZZ, where AAAAAAAAA is your Testing ID, and ZZZ is the appropriate filename extension for your archive type (zip, tar, or jar).



    Regards, Andrew
    [ January 11, 2006: Message edited by: Andrew Monkhouse ]
     
    Henrik Strand
    Greenhorn
    Posts: 20
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks!

    Best regards,
    Henrik
    [ January 12, 2006: Message edited by: Henrik Strand ]
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic