Problem identifuing design pattern
Hi!
Some background before asking the question. I have so far worked only on 3 web applications. I am not an expert architect by any means, but I can usually identify patterns when I have to.
But now, I have to design a totally different kind of system, and mind you, I do not have much flexibility as to what I can do. The company for which I work for has two system. For one of those, the data is inserted into a central database (1 table is of interest for me) and the other system is inserting data into an MQSeries queue. My system as to "listen" on those two input and, when a new message arrives, retreive it and process it.
I had already made much of this system work in "standard" java and it works pretty well. But I would like to move it to J2EE for the next phase of the project. My only problem is that I do not know how to "listen" to the input I mention before from within a J2EE application. What I mean is that every other J2EE application I coded on where receiving HTTP request, thus the servlet container was dispatching it etc etc... But now, there is no request coming in, I have to be proactive and take action on a database insertion. And from what I have seen so far, servlets and EJB's seems to be passive objects, in the sense that they won't begin doing work on their own at startup. So I would just like some hints as to how I could make a J2EE application run on its own, in the sense that there will be no client request triggering anything. Or, as I see it, my client have to be running inside my application server and my problem is how to "start" it. There is no main() in there and that confuse me a lot I guess...
Thanks in advance!
[1701 byte] By [
manicheloa] at [2007-9-28 7:42:42]
you can use a MessageDrivenBean (MDB) to listen to a JMS queue or topic.
JMS (java messaging) is the interface that MQSeries (a JMS provider) implements.
As to the database - you still have alot of options:
1) DB trigger that puts the data on an MQQueue (thus you only have to write the processing code once)
2) implement the processing in PL/SQL (which is kind of a stinky solution; but sometimes you've got no choice)
3) if you're DB is oracle; you can write a 'package' (which is just PL/SQL implemented in Java); you're package could call code to perform the processing, put the data in the MQ, or do the processing itself.
My opinion is that you use option #1.
Well, this could be a good idea, but the different input could possibly change in the future, I would like one which could be extensible. There is the possibility that I will need to listen for new files creation on the server for exemple or for data on a new table. I would have liked to only have to code a new "service" or "listener", create a config file and to deploy it... Do you think that this could be solved by using a load-on-startup servlet which would span the needed process? I was looking for a clean approach to this problem, but it doesn't seem to be a very frequent use of J2EE applications...
It sounds to me like you have a 'polling' problem. basically you have n mechanisms of data being sent to your application for processing; some of these mechanisms provide you with an event; and some do not.
What I would try to do is have 1 central 'processing' system that takes the domain objects and does whatever business processing needs to be done. The rest of your system's job is to get the data, turn it into the domain objects, and pass it to the processing subsystem.
I think you'll end up having one susbsystem per mechanism (jms, ftp, etc.). The easiest to implement will be event based (jms/mdb, or DB trigger); the harder will be polling based.
p.s. for polling - you basically create a class that implements Runnable and start a thread; your Runnable class sleeps, and periodically wakes to look for new data (perhaps in a ftp directory or something); when it finds the new data it works until all the data has been sent for processing; then it goes back to sleep. You could probably make an abstract framework for the polling part; and plug in various sub-classes as needed.
This sounds like a good idea. Exactly what I was needing. If I can abstract the polling system as much as I can, it would meet my requirements perfectly. I tough that I was not allowed to create threads at all in a J2EE application. Seems that it was only for EJBs (that is what I read...)
I will investigate further in this direction. Back to the drawing board!
Thanks a lot for your kind reply, it is very much appreciated.
Ciao!
where's the dukes? ;)
You can have threads in a J2EE system, it's just that EJBs shouldn't create/use them or call synchronized methods. These restrictions are in place to prevent scalability issues (blocking on synchronized methods), and to ensure transactional integrity.
Think of it this way: you're polling framework runs 'outside' of J2EE; when necessary it invokes the J2EE code - which alleviates any fuss/muss
- Andrew
Ok, I think I understand it.
In fact EJBs are a bit like a shared librairy, they expose some functionality which can be used by many "clients", so they should not spawn new threads which could block them or corrupt data part of a transaction. But I can happilly create new runnable objects from servlets if I need to. is this right?
P.S: I would happilly give you all my dukes, but I can't find where to go to transfer them to your account! I tough they were automatically given to you when you were answering my post! :(
Doh! just read how to "pay" with dukes at the top :)
> But I can happilly create new runnable objects from servlets if I need to. is this right?Yes, this is exactly right and how the EJB componenets are ment to be used (multiple clients [except for stateful session beans which have only one client]).
