Re: Request for input - Batch processing using JAVA

Web services provide an easy way to submit things (you wouldn't even
need "web services," you could just have a REST-type interface where
you hit a url, which fires off a job...)

But then again: why not set up Quartz, have a single JVM with Quartz
to fire off events based on cron-like schedules. As far as 'searching
through jars' -- I rather agree with Mr. Ham, I don't see why you'd be
doing that in the first place. What are you searching for?

On Wed, Mar 16, 2011 at 8:01 AM, Ham, Paul D <[email protected]> wrote:
>>> The thing we don’t like about this strategy is that the code is packaged
>>> in .jar files which are hard to search and, when necessary, cumbersome to
>>> look through.
>
> Terry – What is the reason for “searching” and “looking through” jar
> files?   On my project we have about 20 Java-based batch jobs with assorted
> jar files and we never have to search inside the jars…
>
>
>
> Paul Ham
>
>
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Terry Waranch
> Sent: Tuesday, March 15, 2011 5:47 PM
> To: [email protected]
> Subject: [Juglist] Request for input - Batch processing using JAVA
>
>
>
> Hi,
>
>
>
> I need some input.  I have sent this message to another email address but
> got what I think is a bounce back.  If this is a redundant message… sorry!
> Here goes…
>
>
>
> Our shop runs a good many batch processes for daily reports, data extracts
> and data updates.  We are moving more toward java as our primary language.
> Currently we use .jar files for these processes.  The programs are developed
> using Eclipse, exported to .jar files, and uploaded to our Linux server
> where they are executed.  The .jar will run under a Unix shell which is
> started by Cron.  A typical program will run under a minute to all day
> plus.  We use common .jar files for shared code.  Performance is good.  We
> have no problem distributing the programs.
>
>
>
> The thing we don’t like about this strategy is that the code is packaged in
> .jar files which are hard to search and, when necessary, cumbersome to look
> through.
>
>
>
> We talked about organizing these processes into web services.  We could use
> Subversion to maintain the library.  This would give us a better tool for
> searching our code and organizing reusable functions. If we did that how
> would we kill an individual job?  I have also read articles that indicate
> that web servers will kill long running processes.  Are people using web
> services for batch processing.  Is that the right tool?
>
>
>
> As an alternative we talked about using large .jar files.  The code for
> batch processes could be stored in a common .jar file.  We could create
> individual .jar files with a simple MAIN to start a batch process.  The jobs
> would be easy to manage using Cron, easy to kill, and we would be able to
> use Subversion for library control. How large could a .jar file like this
> get?  Is this the right tool for this kind of processing?
>
>
>
> If you have any comments or something that I should look at please let me
> know. I attended a meeting several months ago where Service Oriented
> Architecture was the topic.  Does anyone remember the presenter’s name.  I
> would like to address this question to someone who has experience using SOA.
>
>
>
> Thanks for your help,
>
> Terry
>
>
>
>
>
> Terry N. Waranch
> Business Analyst/Developer
> REPLACEMENTS, LTD.
> PO Box 26029
> Greensboro, NC  27420-6029
> 336-697-3000, ext. 2298
> Fax:  336-697-3100
> [email protected]
> www.replacements.com
>
>
>
> NOTICE:  This message may contain information that is confidential,
> proprietary, and privileged.  If you are not the intended recipient, you may
> not use, print, copy, disseminate, or retain this message or any information
> contained in this message, including in any attachments to it.  If you have
> received this message in error, please notify the sender by reply email and
> delete this message and any attachments to it from your system(s).  Thank
> you for your cooperation.
>
> _______________________________________________
> Juglist mailing list
> [email protected]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
>
>



-- 
Joseph B. Ottinger
http://enigmastation.com