JMS vs .... ?

[David N. Welton]

Hi,

I've picked up some crufty code to investigate at work, and part of
solving the problem is getting data (a pdf) from one machine to another
reliably (and then sending a fax). Currently, the code does this via a
wonky email routing scheme that depends very heavily on the machine in
question being configured 'just so'. Not good...

I was looking at JMS as a potential alternative, but some of the guys in
the local JUG didn't seem very enthusiastic about it as a solution,
suggesting it might be better to just 'roll my own' - a row in the
database that gets updated to say "I've been read" when the file has
been fetched via http. Admittedly, that's an improvement over the
current system, and seems simpler than fiddling with JMS...

Thoughts?

Thankyou,
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

 

[Chris Uppal]

I was looking at JMS as a potential alternative, but some of the guys in
the local JUG didn't seem very enthusiastic about it as a solution,
suggesting it might be better to just 'roll my own' - a row in the
database that gets updated to say "I've been read" when the file has
been fetched via http. Admittedly, that's an improvement over the
current system, and seems simpler than fiddling with JMS...

If the simple solution will in fact solve your problem (e.g no issues with
atomicity, or of reliable access to the database), then the only reason I can
think of for invoking the complexities of JMS would be that you want to put JMS
on your CV[*].

-- chris

[*] == "resume" for people in the US

 

[davidnwelton]

I was looking at JMS as a potential alternative, but some of the guys in
the local JUG didn't seem very enthusiastic about it as a solution,
suggesting it might be better to just 'roll my own' - a row in the
database that gets updated to say "I've been read" when the file has
been fetched via http. Admittedly, that's an improvement over the
current system, and seems simpler than fiddling with JMS...

If the simple solution will in fact solve your problem (e.g no issues with
atomicity, or of reliable access to the database), then the only reason I can
think of for invoking the complexities of JMS would be that you want to put JMS
on your CV[*].

Well, the system should be transactional in the sense that it needs to
fetch the data and do something with it, and if it fails along the way,
it should roll back what it was trying to do, and consider the data
'not fetched'. The super simple real world example: the web server in
the hosting farm needs to send a fax. A computer in the office has a
fax machine. Once the application code has handed off the fax to the
transport mechanism, it needs to be absolutely sure that at some point
the fax is handed off to the office machine, and put in the send queue
(although at that point I guess it's up to the fax software and we
can't really control if the fax actually arrives where it's supposed
to, but we get regular reports from it, so I guess we're ok from that
point of view).

There are a few other processes of this type - sending data from the
office to the server, for instance. They're all asynch, and all need
to be atomic.

Thanks
Dave