Application server architecture 2

Question

Hello guys,
I have few questions about application server architecture�
I already was asking similar question (http://forum.java.sun.com/thread.jspa?threadID=654898) and got few replies which were looking for me quite ok, but after reading more docs I doubt that suggested approach is right.
So, I have a task to build a server application which will do the following: Clients (special java clients) will connect to it and send some data for further processing on server side. Chunks of data will be relatively small but they will take a lot of time for processing � up to one or two days.
Also server will run some sort of �database� where all clients� working data will be stored. So, in case a client loses its data he/she is always able to download it from the server.
For me it was seeming like server will consist of the following components:
1. �Reception�. This part will be responsible for all client-communication procedures.
2. �Data storage�. This part will simply store all clients� data and provide some API interface for clients through �reception� to manage it (add/get/delete and so on).
3. �Processor�. Some sort of dummy-sophisticated module. It will take some input data from �data storage� when it receives order for this and process it. �Processor� will have two states: �busy� which means �processor� processing some data and �available� which means �processor� ready to process new data.
4. �Manager�. This part will always check �data storage� for new data and �processor� for availability. When �processor� and new data are available �manager� will make an order for �processor� to take new data from �data storage� and process it.
I got few suggestions:
1. Make �Reception� stateless session bean. I agree with it. It is quite reasonable.
2. Make �Data storage� as a session bean that will use entity beans or hibernate to work with persistent data. It is also seems quite reasonable and as it was suggested I would like to implement my own data access mechanisms instead of using those which provided by J2EE server.
3. !!! �Processor�. Suggestion was the following: �Use a message driven bean. Make Reception to enqueue a message when new data is available for processing. Processor will process the data and store the resut in database using Data Storage session bean.� It is quite reasonable, except one little thing: I read that Message Driven Beans are not designed for long time processing. Moreover, for example in my JBoss server, Message Driven Beans have attribute KeepAliveMillis=30000. For me it seems that after 30 second my message driven bean will be killed by server and now I doubt: is message driven bean a good solution for implementation long time running processor?
Now I am thinking that �processor� component should run as an additional application outside of J2EE server and from time to time (when data is finally processed and �processor� available again) send messages to my j2ee server.
So, whole picture will look like this (please have a look on the picture: http://www.flickr.com/photos/77716401@N00/35565234/ ):
1. j2ee server always on and ready to create �reception� session stateless EJB to serve remote clients. At the beginning it thinks that �processor� offline and doesn�t attempt to interact with �processor� in any way.
2. When clients appear to interact with server they simply send or receive package of data without complex interaction. �Reception� simply receives data from clients, pass it to �data mapper� component and tells to �manager� that new data available for �processor� to process. �Data mapper� component stores received data in �database�.
At this point j2ee server does two simple things:
- Collecting information for further processing from remote users
- Returning backups of received information to its owners.
3. �Processor�. �Processor� talks with my j2ee application via �Manager� stateful EJB. When �processor� runs first thing it does it asks �manager� for data to process. If there is new no data to process, �processor� does nothing but �manager� remembers that �processor� is ready to work. If there is data to process �manager� passes data to �processor� and remembers that �processor� is busy.
4. When �processor� finishes processing it does the following:
a. Returns data to �manager�. �Manager� passes processed data to �Data Mapper�. �Data Mapper� stores processed data in database.
b. Asks �manager� for new data to process if there is new data to process, �processor� does nothing but �manager� remembers that �processor� is ready to work. If there is data to process �manager� passes data to �processor� and remembers that �processor� is busy.
5. When client submits new data �reception� tells to �manager� that new data available and it �processor� state is �ready for work� �manager� sends order to process to processor.
And so on. Now for me it seems quite reasonable architecture.
But, since I am very new in j2ee technologies I ask few questions:
1. Is my approach right at total?
2. Is it ok that I would like to make �Reception� stateless EJB, �Data Maper� BMP EJB and �manager� stateful EJB?
3. I know that JMX is a basic concept of J2EE, so I would like to register my database as a resource in my J2EE server. Is it right?
4. I need some sort of component which runs all the time from time server started till it is off. If there is anything like this?
Please, give me some advises and tips!
Thank you in advance!

Answer 1

1. Navigating in SAP systems
--Logon and structure of the user interface
--Accessing functions in the system
--Personalization options
No, this is really nothing more than an introduction for people that have never seen a SAPgui screen before.  Most ABAPers can skip right over this course.  If you understand the NetWeaver architechure, then I would suggest to start withe BC400.
Regards,
Rich Heilman