This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exam success but probably a design failure

 
Tomek Grzejszczyk
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I've successfully passed an exam, but I've scored only 7/40 on Network Server (and a lot better in other categories fortunately :-)). I'd like to share my design with you so maybe somebody can give me a hint about what is wrong with my networking.

In implementation I went for sockets and my server provided a data access interface (DBMain) over the network. And here is an excerption from my choices.txt about networking:

----

The *NetworkServer* class implements a network server functionality. It follows the pattern:

while (true) {
accept a connection ;
create a thread to deal with the client ;
end while

The *ServerWorker* class represents a thread that is spawned to serve a client. This thread uniquely identifies the client on the server.
The *WorkerManager* class manages creation of the threads, keeps the list of active threads and registers a callback in each thread. That callback is called when thread is about to die, to perform cleanup.
There is also the *AppSocket* class which uses a Socket to talk the application specific protocol (see below).
And finally there is the *NetworkProxy* class (to be used on the client side) which implements the InvocationHandler interface and is capable of transforming a method call into a corresponding network message. On the server side the *ServerWorker* reads the message and uses reflection to call an appropriate method on the target object (which is a database object).

The point is that *NetworkProxy* is capable of converting *any* method call into a network message/command and that *ServerWorker* is capable of calling the right method on the server side, which is very handy.
...

3.1 Protocol
A typical client server conversation in my application looks like this:

Server Client
| |
listen |
| connect
OkMessage -> | #handshake
| <- CommandMessage #request
ObjectMessage -> | #response
... <- CommandMessage #request
... ... ...
| disconnect
| |

There is also ErrorMessage class for comunicating business exceptions.

----

From the time perspective I think that this design is an overkill and too generic. The NetworkProxy class can act as a proxy for any interface (a DBMain in my case), it just marshalls any method call over the network. On the server-side a reflection is used (given the information send over the network) to call an appropriate method on a business object (DBMain implementation in my case). This looks a bit like a self-made RMI, but it was fun to design and implement it.

Is really overdesigning enough reason to substract 33 points?

Tomek
 
Tomek Grzejszczyk
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'am sorry the protocol description ASCII art didn't get through the forum formatting, maybe this time:

...
3.1 Protocol
A typical client server conversation in my application looks like this:
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic