death pac

Greenhorn
+ Follow
since Jun 15, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by death pac

ofcourse u can add methods to the data class !
amjad
hi mask ,
please read my previos post (passed 148/155) i've listed out five points listing out the advantages of RMI over sockets.

amjad
mask ,
what they mean by extending the data class ,is that u need to implement the lock unlock and critireaFind in another class which extends Data class !
i dont think its necessary bcoz , Data class as the class description say's
"Provides basic database services "
Lock / unlock and search are normal database functions .Hence i thought it would be better to implement them in the data class rather than extending it !This is my point of view ....there might be someone who could find advantages to extending the Data class .But as long as u are able to justify what u did i your design doc things should be fine !!
cheers

amjad
hi mask
what i meant by MVC is not the original swing implementation ,but it's specific to my application .I used to the model view controller pattern to handle switching of GUI screens .
amjad
hi Akanimo
i'm considering the architect exam as well !! But actually i'm a little further than considering ..i already have the voucher which expires in novemeber 01 !!!:-((
so i've to hurry on that !! guess i'll be seeing more of u on the architect news groups !
thanx !
ciao
amjad
mark,
i used rmi and reason why i chose rmi are as follows .
1.Rmi is threadsafe ,where as in sockets multithreading issues need to be cared for.

2.Sockets need a communication protocol which has to be custom defined.But in case of Rmi a custom protocol is not needed,because Rmi uses RMP for communication.

3.Rmi presents a simpler programming model over sockets.

4.Rmi supports dynamic class loading .This allows new types of objects to be introduced in to a remote virtual machine thus extending the behaivour of the application dynamically .

5.Rmi gives more scope for scalability.As new objects can easily be introduced with changing the exsisting setup.where as in the case of sockets the communication protocol might have to be modifyied to accomadate new features.
good luck
amjad
hi narayan,
yes i included the stub's in the client.jar i did'nt use the codebase property .neither did i use policy files !
i tested on linux redhat7.1 and windows 2000 and it worked fine !
good luck
amjad
this is the break up :
General Considerations(maximum = 58): 58
Documentation(maximum = 20): 20
GUI(maximum = 24): 21
Server(maximum = 53): 49
Gui - MVC pattern
local / network - factory / adapter
lock/ unlock - singleton
will give more details on my application as per request !
special thanx to Akanimo for helping me with my remote/local mode design !!

ciao
amjad
hi there ,
thanx for your commments ! they say "better late than never"!! i was gonna submit my assignment on firday!!i ve reworked my design according to your suggestions !!
thanks again
cheers
Amjad
hi ,
i tested my application with redhat linux 7.1 running the server and Win2000 the client and it worked fine !i was running jdk1.3 installation on both the machines.
rmi works fine without any glitches on redhat 7.1/jdk1.3
cheers
pac
Hi Akanimo ,
I agree that i dont need to make my Client a Remote object. The reason i did that in the first place was to implement call backs.But i guesss i 'll have to revert on that one.
i think i need to rephrase my previous post .
In the local mode ,i m not using the rmiclient.instead my factory returns an instance of the rmiserver .the calls to the server are made from the GUI classes using a object of type xyz .so the gui classes are totally unaware of the mode the application is working in .The reason ,i need stubs /skeletons is bcoz of the fact that rmiserver is a remote object and hence the jvm looks for stubs and skeletons .
yes i think it might be a good idea to name my classes accoring to the mode .but again,i m using the same classes for both modes of the application ..except for the fact that i m eliminating the rmi client in the local mode .
hope to hear more comments
cheers
pac
Hi ,
I used the factory pattern to handle local / remote mode.i've one remote interface which has all the public methods of the data class.This interface is implemented by both the rmi client and rmi server.So both the client and server are remote objects.
I've a factory which instantiates the rmi client or rmi server depending on the mode.The GUI makes method calls on the rmi client in case of the remote mode and for local mode ,the calls are directly on the rmi server.
this how it looks :

interface xyz extends remote
{
}
class rmiclient extends UnicastRemoteObject implements xyz
{
}
class rmiserver extends UnicastRemoteObject implements xyz
{
}
class factory
{
getclass(boolean local)
{
if(local)
{
return new rmiserver();
}
else
{
return new rmiclient();
}
}
The problem with this desgin (i dunno know wether it's a problem) is that stubs/skeletons come into play even in local mode.
would appreciate a healthy run down of this design !
cheers
pac