Your proposition about using scripting language inspired me, but I did
not use scripting language, but I just refactored my module a little
bit. The first big change was to modify my LoanInspectorBean, now it
has only local interface and it does not include document/task
generators, so it is really much more compact. The second change in
this bean is that now, it's method returns collection of
LoanInspectorReport objects that represents the state of every loan
my bean was processing: loanId, old status, new status,
isStatusChanged method and info about first unpaid installment.
The third thing was what were you talking about, but it is a regular
session bean in Java (not JavaScript). It looks like this:
public class CheckLoansBean implements CheckLoansRemote {
@EJB private LoanInspectorLocal loanInspectorBean;
@EJB private ActionServiceLocal delayedLoanActionServiceBean;
@EJB private SoftActionsGeneratorLocal actionGenerate;
@EJB private DocsActionsGeneratorLocal docsActionGenerate;
private final Logger logger =
Logger.getLogger(CheckLoansBean.class.getName());
public void execute(Date date) {
logger.info("CheckLoansBean: ENTERING... date=" + date);
Collection<LoanInspectorReport> report =
loanInspectorBean.checkLoans(date);
logger.info("CheckLoansBean: removeExcessiveActions");
delayedLoanActionServiceBean.removeExcessiveActions();
logger.info("CheckLoansBean: generateActions...");
actionGenerate.generate(report);
logger.info("CheckLoansBean: generate PZK actions...");
docsActionGenerate.generatePZK(report);
logger.info("CheckLoansBean: EXITING...");
}
}
And last thing was to "learn" action's and document action's generator
beans to deal with my collection of LoanInspectorReport. This is now
up to them what are they going to do with my report. I really do not
care as long as "report" is good enough for them.
So now, everything that is connecting my 4 beans is my "report" class
and this particular CheckLoans implementation, that can be easily
swapped with something else. Its interface is really not related to
how it works (just one "execute" method), so in the future, when our
application will be working in different companies, we will be able to
move implementation away from interface and combine different
implementations for every customer.
Witold Szczerba
2008/2/21, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org>:
> So, I will offer a 3rd solution to you for you to consider.
> One word: JavaScript.
> (or any scripting language, frankly...)
> Rather than using JBI and XML to represent your processes, use JavaScript.
>
> It's pretty painless to start with, and you can learn the ins and outs of using it better via the documentation.
>
> So, what you have is a ScriptingBean which has a method (lets call in "run") that takes a reference to a blob of Javascript (internal DB reference, a file name, simply a String filled with Javascript, whichever).
>
> Your "run" method prepopulates the Java script context with references to your other service SessionBeans, and it can even inject your Loan Application object.
>
> your Javascript can literally be (this should look very familiar):
> [code]
> var scheduleGenerator = new ScheduleGenerator(loan);
> var schedule = scheduleGenerator.getResult();
>
>
> loanDao.persistSchedule(loan, schedule);
>
> if (loan.getProposal().isRestructuring()) {
>
> loanService.loanRestructActivation(loan);
>
> }
> documentsService.groupGenerateActivationDocuments(loan);
> loan.setLoanStatus(em.getReference(DictLoanStatus.class,
> DictLoanStatus.ACTIVE));
> loan.setStatusChangeDate(new Date());
>
> actionService.genereteOrUpdateBeforeEndAction(loan, schedule);
>
> [/code]
>
> The benefit is simply that you can expose the javascript to end users, you can write a simple interface that generates the Javascript on the fly (if you like, for example, you can simply have a list of processes in a table, and a user could put them together how they like with your generator doing the detail work), etc. However the Javascript is created, you evaluate it dynamically, at run time.
>
> Even in its most crude form, for simple scripts like this, whatever overhead incurred by Javascript is lost in the overall backend processing taking place.
>
> Change it on the fly, no deploys, no restarts, just run it again. Works like a dream.
>
> Give it a look, you can get a script running in your code probably in less than a 1/2 hour.
>
> We use JS everywhere for all sorts of things.
>
> Give that a look, may do the trick for you.
>
> [Message sent by forum member 'whartung' (whartung)]
>
>
> http://forums.java.net/jive/thread.jspa?messageID=260068
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>