• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java desktop application accessing a servlet?

 
Allen Hamilton
Greenhorn
Posts: 9
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just finished a small desktop application that saves my daily reminders in a local database and presents them in a JTable. I coded buttons to add/remove/edit the reminders also. It also uses Quartz-Scheduler to send an SMS reminder to my cell phone at the scheduled time in the Reminder object.

The issue I'm facing (and it's a pretty big one) is that, whenever I close the desktop application, Quartz shuts down also, and I obviously don't receive any reminders!

I'd like to find a way to persist these reminders, by uploading them to a servlet on a remote server that uses Quartz to process and execute the reminders.

I got a simple version of this working, where I take all of the fields of my Reminder object and pass them as parameters in a URL to my servlet kind of like this:

http://www.example.com/myapp?phone=5555551212&message=helloworld&hour=18&minute=30

But here are my questions:

1) Is it even appropriate for a Java desktop application to be accessing a servlet like this? I ask this because, in the books I am reading on servlets and JSPs, all of the examples are of pure web applications.

2) Is it appropriate to be sending all of these fields of my Reminder object as URL parameters, or is it better design to (somehow) send the actual Reminder object to my servlet, which then extracts the fields?

I know these are general questions, but I just need a little advice on the general direction that I'm going in.

Thanks!

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch!

Sure, a desktop can make requests to web services. The fact that it's using servlets is rather irrelevant to the requesting end. But I don't think it's the right approach to your issue.

What does it mean to "execute a reminder". A web resource is going to respond to the request immediately. What is the web app supposed to do at a later time when some timer goes off?
 
Allen Hamilton
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch!


Thank you!

What does it mean to "execute a reminder". A web resource is going to respond to the request immediately. What is the web app supposed to do at a later time when some timer goes off?


The web resource does not respond to the request immediately. The desktop application just passes the parameters to the servlet (phone number, message, hour, minute) and then the servlet uses that information to create a Job and a Trigger for Quartz, and Quartz sends a text message at the specified time. That way, I can close down the desktop application and still receive reminders.

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Allen Hamilton wrote:The web resource does not respond to the request immediately

A web resource always responds immediately. That's not the same as triggering a timer at a future time.

This could be feasible as sending a text message doesn't require a connection back to the client. But could you not achieve the same thing, and probably more simply, by running a background daemon?
 
Allen Hamilton
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A web resource always responds immediately. That's not the same as triggering a timer at a future time.


Sorry, what I meant was that the servlet does not send the text message immediately upon receiving the request. But the servlet does respond immediately in the sense that once it receives the request, it immediately creates and Job and Trigger and schedules the job with Quartz. Then at the later time that was passed in via the URL parameters, and that was used to create the Trigger, Quartz sends the text message.

This could be feasible as sending a text message doesn't require a connection back to the client. But could you not achieve the same thing, and probably more simply, by running a background daemon?


Do you mean a background daemon on the same client machine that my standalone application resides on? The problem with that is that if I shut down the computer, the background daemon is destroyed, and I can't receive any reminders!

I guess I'm just wondering if passing URL parameters to a servlet is the best way to achieve this. I just want to make sure I'm not overlooking any other options or technologies.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you make a request to a servlet (or other web resource) you pass information in request parameters. For a GET, they'd go in the query string, for a POST, in the request body.

If the data is sensitive, you likely want to protect the transmission via SSL.
 
Allen Hamilton
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:If you make a request to a servlet (or other web resource) you pass information in request parameters. For a GET, they'd go in the query string, for a POST, in the request body.

If the data is sensitive, you likely want to protect the transmission via SSL.


For my 'production' application, I'd certainly send the parameters in the body of a POST request. I was just sending the parameters using a simple GET so I could test out the servlet in a browser window. I'll also use SSL with the finished product.

I've been doing some more research and just found out about REST with JAX-RS, but I need to learn more about it before I make a decision.

In my finished application, I would need it to be able to create, remove, update and delete reminders through the servlet, and it looks like JAX-RS allows you to do that. On the other hand, I don't see why I couldn't just add an extra POST parameter for create/remove/update/delete and have the doPost() method in the servlet check to see which parameter was passed in, and perform the necessary operation. But then again, that seems kind of sloppy. Maybe I should just use something like JAX-RS...
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Defining a RESTful API would certainly be more conventional and professional than creating an ad hoc API.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!