[Opensource] Future Code for Expresso 5.1 and beyond [LONG THINK TANK ARTICLE]

[Peter A. J. Pilgrim]

Kris Thompson wrote:
>>-----------------------------------------------------------------------
>>Job Handler:
>>
>>Ok, so we've all pretty much concluded that JobHandler needs some
>>work.  I'd honestly like to see refactoring take a couple of steps:
>>
>>STEP 1:  Make some interfaces to Job Handler that allows code to directly
>>control the Job Queue, such as initiate shutdown, queue a job
>>etc.  Ideally, we wouldn't use the JobQueue DBObjects at all from the
>>'initiate a job' standpoint.
>>

+1  Some refactoring into interfaces, and a default class and / or abstract
class would help

	public interface JobHandler {
	}

	public class AbstractJobHandler
	implements JobHandler {
	}

	public class DefaultJobHandler
	extends AbstractJobHandler {
	}


>>STEP 2: Get a good reliable Job Handler that runs in a separate
>>thread.  Having Job Handler run in a separate VM currently can cause all
>>sorts of issues with caching.  So let's not even try it first off.  Let's
>>boost reliability in-VM.  Issues are:
>>		Clean Shutdown
>>		Track down the final JobHandler/DBObject race conditions.
>>		Reliably run Job Scheduling.
>>

+1 Some people will only ever have access to one VM on a firewalled DMZ
server, especially those Intranet guys and gals, might never see a J2EE
app server.

>>STEP 3: Work on an out of VM Job Handler.  AFAICT, this will require
>>something like RMI to provide decent IPC communication to the Job
>>Handler.  [Or JMS if we want multiple Job Servers].  This would
>>DEFINITELY
>>be a replacement component for the in-VM Job Handler since it
>>would require
>>additional servers such as RMI Registry or JMS server.  But we
>>can work on
>>it without affecting the current code base because we've componentized
>>JobHandler as listed in step 1.
> 
> 
> I have worked with RMI in the past and found it unsatisfying and would like
> to recommend a JMS server solution but to be fair in my vote, I have never
> worked with JMS before so it might be just as much or more of a pain then
> RMI.  Any comments from folks who have done a JMS implementation, would this
> be a good use of JMS?
> 
> Kris

A JMS solution would presuppose the existance of open source JMS Provider 
solution. JMS is rather like J2EE application server somebody has to
write the back end solution, because JMS is just a standard
API wrapper to enterprise information systems.

However if the JobHandler was refactered to use a plugable implementation,
using an interface, as described in the new design above,
then I can not  see why JMS Job Handler would not work for those
software houses with the ££££$$$$.

-- 
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
    ||
    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''