Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

listener-pattern for gui-application linking- help

 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought I must decouple the gui from the application logic and also ensure that RMI calls are not made in the Event Dispatch thread (to keep GUI responsive). So I have implemented a listener pattern. I have defined RequestJob interface and implemented it in separate classes each representing a type of request job. For eg. RequestInfoJob, RequestBookingJob. Each such class has a run method which contains the logic for the job.
The relevant gui element executes a request by instantiating the appropriate RequestJob. The gui element then attaches itself as the listener to that RequestJob object. The RequestJob object is then submitted to a Dispatcher object which maintains a queue of RequestJob objects and processes the queue in a separate thread.
When in the execution of its run-method the RequestJob object receives a final response from the server it throws a ResponseEvent which is notified to all the listener gui elements registered with the RequestJob object. I think the notifying of the listeners should also be done in the EventDispatch thread by calling the InvokeLater() methods.
Upon receiving the notification the listener-gui elements analyse the RequestJob object to find out the fate/result of the request and then present the information to the user.
Is this a sensible design. I would be grateful for any help, since I don't have much practical experience.
Thanks
 
vladimir levin
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rahul,
I am just getting started on my assignment myself, so hopefully someone else will post a more substantial reply to your posting. That being said, I'll try to make a stab at it:
I think the idea of having a separate thread on the client-side to process a request -- for example to list flights based on search parameters, or to book a flight -- is a good idea insofar as it makes it possible for the user to cancel a request if it is taking too long -- similar to how you can click the stop-button on your web-browser if a page you are trying to view is simply taking too long to load.
However, in the case of processing a booking for a flight, you do have to be careful to make sure the server can handle cancelling a booking that is mid-way through processing. In fact, this sounds sufficiently dangerous to me that maybe it is not a good idea. On the other hand, a search is a perfect case for allowing this type of functionality since the user may want to cancelt a request to display all flight (eg. any destination and any origin) if it is taking too long and type in more restrictive criteria.
Anyway, it is probably not a bad idea, and something I have been thinking to implement into my assignment too, but I also feel that doing this sort of thing is probably not really necessary. If you just put up an hourglass icon while requests are being processed and leave it at that, I imagine that would be just fine.
Also, if the queue you refer to is a queue on the client-side, i.e. you are thinking of allowing the user to queue up multiple requests, like in Napster where you can set up multiple downloads, I think that is not conceptually necessary for the application we are supposed to build, and it also seems to be a bit beyond the scope for this assignment too.
Just my 2-cents...
Vlad
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Vlad for your considered and detailed reply.
Yes you are right about disabling the client from cancelling a booking once it is submitted to the server for processing, and you are also right about allowing the cancelling of an query job.
However I am not allowing the user to cancel any request. I think the design is flexible enough to allow this functionality to be easily incorporated in the future.
But my more important objective was to allow the user to submit concurrent requests, without waiting for the earlier request to complete. The gui would always remain responsive. For eg. the user wishes to book 1 seat on flight A and 2 seats on flight B. Why should the user be made to wait for the first booking to complete before submitting the second. Concurrent requests are easily supported because the gui simply has to instantiate the appropriate RequestJob objects.
Of course if one starts thinking on these lines, then a number of other functionalities can be envisaged. The concurrent requests may be linked for the user i.e. he wants a booking on flight A if and only if he can get a booking on flight B. Then the user must be allowed to send linked/grouped requests which execute atomically.
The reason I am making a queue on the client-side is because I am not exactly clear or sure of the effect of multiple threads concurrently accessing the RMI stub. I have this idea that the methods must be called on the RMI stub serially. If object A on client makes an RMI call through the stub, which is processed in thread1 on the server, and object B makes concurrent call through same stub which is processed in thread 2 on the server, then if thread1 returns - will the stub be able to direct the return back to A or can it be confused and return to B ? I would be delighted to hear your views.
 
vladimir levin
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rahul,
Regarding the idea of queuing multiple booking requests *per*
client, I honestly am not sure it is a good idea at a
conceptual level, quite aside from any technical issues of
implementation. Don't get me wrong, I think your idea is "cool",
but given the spec we've been given for the assignment, does it
make sense? In the example of Napster I mentioned earlier,
queuing is useful for two reasons:
1) A given "job" (file download) may take quite a long time
2) All jobs are inherently independent from one another
The first point is that once I decide to download a file, it
may take a while, and I may want to start downloading other
files at the same time from other sources. I also may want to
cancel a download at any point in time without affecting my
other downloads.
The second point is that the order in which my jobs are completed doesn't matter to me, and if one job dies a horrible
death for some reason (the guy on the other side turns off his
computer), that doesn't affect my other jobs.
Now, consider our flight booking app. Regarding the first point,
is it really likely that booking a single flight will take a
really really long time? Considering we are holding a lock on
that flight record, I should hope not. If that is a problem,
then we have much bigger problems than just a single user being
able to queue up requests.
As for the second point, we may have dependency problems: If a
user concurrently issues a request to book two flights, and
the second one completes successfully but the first one fails
for some odd reason, that might be a problem for the user who
would want both bookings to complete atomically, so to speak.
As for your actual question, which concerned the technical
details... I'm afraid I can't really help with it. I don't know
much about the whole issue of using RMI to queue up requests
on the server side. As I see it, you would need to implement
real transaction support, and that is beyond the scope of the
assignment as I see it. eg.
startTransaction();
... issue requests to book flights ...
commitTransaction(); or rollbackTransaction();
I think what you are attempting to do, while cool, is
perhaps not necessary...
Just my 2-cents
Vlad
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic