wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX - Contractors - Network implementation 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 "NX - Contractors - Network implementation" Watch "NX - Contractors - Network implementation" New topic
Author

NX - Contractors - Network implementation

Xavier Fabreguettes
Greenhorn

Joined: Jul 17, 2003
Posts: 14
Dear members,
2 questions:
1) Has any of you (sucessfully) submitted you Contractors assignment with sockets instead of RMI? It is what I am using at the moment but it seems that almost everybody is referring to their RMI implementation. The specs mention though that either sockets of RMI can be used, and that should not be detrimental to the final mark as long as the choice is justified.
What is wrong with using sockets?
2) From reading previous threads, it seems that Sun is not too keen on input fields and much prefers JComboBox. Do you think that this also applies to the contractors assignment? I understand that if you choose a flight, the number of origins/destinations is limited but for contractors, the list may be much longer (and very long drop-down list are a fairly poor feature). You could also argue that people are maybe only going to remember only a part of the name (e.g. if it is "AAA, BBB & CCC"), which would mkae the CSR's job more difficult as they would have to visually scan the the list to find the contractor the customer is after (say "BBB" in the example above).
Another possibility would be to offer both combo boxes and textfields (which, to be honest, wouldn't require a big effort).
What are your views on this?

Many thanks for your help,
Xavier
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Xavier,
1) Has any of you (sucessfully) submitted you Contractors assignment with sockets instead of RMI? It is what I am using at the moment but it seems that almost everybody is referring to their RMI implementation. The specs mention though that either sockets of RMI can be used, and that should not be detrimental to the final mark as long as the choice is justified.
What is wrong with using sockets?

I've not (yet) successfully submitted my socket-based implementation of the assignment, but I am one of the few who chose sockets too. As far as I know from Max Habibi's book (The Sun Certified Java Developer Exam with J2SE 1.4 - recommended !), the only wrong side of sockets against RMI is that it could be more complex to design. A well-designed socket implementation seems to outperform RMI in terms of scalability and pure performance and does not need client stubs to be recompiled when the server changes. So, as there is no final-mark difference and nor scalability neither performance is really important in our assignement, my main motivation in choosing sockets is personal challenge.
But I have one more justification in favor of sockets. As a Java newbie, I am fascinated by its write-once-run-anywhere paradigm. A nice language, strengthened by a huge and still improved API, giving us applications running on so many platforms. So, what I dislike in RMI, is that it's a java-to-java network technology. In comparison, as sockets are standard, you may imagine a Java-based server communicating transparently with Java-based clients and any other client as far as it understands sockets and the protocol we decide to implement. It's a very big plus IMO.
As the assignment requires that we use serialization as the underneath protocol, I'll do it of course, but my intent is to abstract it through some CommandDecoder / ResultEncoder abstract classes, to keep the system open. What do you think about it ?
Cheers,
Phil.
[ July 17, 2003: Message edited by: Philippe Maquet ]
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Xavier,
I forgot your second question.
2) From reading previous threads, it seems that Sun is not too keen on input fields and much prefers JComboBox. Do you think that this also applies to the contractors assignment? I understand that if you choose a flight, the number of origins/destinations is limited but for contractors, the list may be much longer (and very long drop-down list are a fairly poor feature). You could also argue that people are maybe only going to remember only a part of the name (e.g. if it is "AAA, BBB & CCC"), which would mkae the CSR's job more difficult as they would have to visually scan the the list to find the contractor the customer is after (say "BBB" in the example above).
Another possibility would be to offer both combo boxes and textfields (which, to be honest, wouldn't require a big effort).
What are your views on this?

What about editable comboboxes ?
Phil.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Xavier
it seems that almost everybody is referring to their RMI implementation.

One of the nice things about having this assignment is that it gives you a real task to do, but no constraints. So you can use the assignment to learn new ways of doing things, no matter how steep your learning curve.
That is one reason many people are using RMI: it gives them the chance to learn this technology and see what the good and bad points about it are.
There is nothing really wrong with sockets - as Philippe mentioned there are quite a few good reasons to use sockets.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Xavier Fabreguettes
Greenhorn

Joined: Jul 17, 2003
Posts: 14
Phil, Andrew,
Many thanks for your reply. I'd like to discuss further a couple of points with Philippe and whoever has suggestions to make about the questions I am raising here:

How did you implement your connection? At the moment, I open a stream from a client and send a request across to the server, carry out the query or update, send the response back to the client and then close the connection. If the client subsequently wants to submit another request, a new connection is established and the above is executed again. In this context I believe there is little need to keep a map of all cookies belonging to one specific connection handler (one client -> one client handler on server side) or is there? BTW have you found a way to keep the connection alive and therefore service several requests for the same client (I mean independent requests, I am not talking about multiple requests). I gave it a go a few weeks ago and got stuck because I was using an infinite loop on the client side, which did not seem to work very well. I know that it is easy with InputStream but it does not sound straightforward when using objectstream (which I do using serialized objects). Any tip?
Cheers,
Xavier
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX - Contractors - Network implementation
 
Similar Threads
No need for a locking manager?
"DataInterface" in a waste of code in my eyes
How to map the to-be locked recordNo to the request client
Anybody interested in a sockets discussion ?
A questions about UrlyBird