- Posted by: Frederic Denis
- Posted on: February 27 2001 11:34 EST
I'm fairly new to EJB and I'm evaluating the possibility of migrating an existing client-server application to an EJB-based system. The client part of the application handle about 5 tree-like structures, two of them having between 4000 to 8000 components. The business validations are sometimes very complex and have to check informations across all hierarchies. The usual number of user on this system is between 4 to 20.
In the near future, we plan to add a module for managers and information viewer. This module will most of the time only display information in a browser window, and if there's input allowed, it will have more to do with project management than really "working" with the system. Then, there will be no hard and complex validations to do. I evaluate that the number of client for that module might go from 1 to several hundreds. This is where an EJB system seems to be a perfect fit.
However, we're looking also to integrate the usual client application with the EJBs. We also plan to add analysis modules to the client application (data mining, fuzzy logic decision-making modules, etc...) which will most probably do a lot of request on the database and will need quite processing power.
Also, We don't want to have a form-like app, where you enter info in all the field, press submit, get some errors message, press submit, get other errors message and so on until the submitted changes are ok and pass. *As much as possible*, we want the validations to occurs as soon as they are entered. That's the reason I was thinking about keeping a java-app client and not switching to a web-based client.
My main concern here is the processing power that will be required on the server. What if the 20 users launch at the same time an analysis request, each on something different? We don't want to have our client to buy a server that will cost more that the software it will be used to run. Especially when each user will have a nice 500Mhz-1GHz computer on his desk, doing only display work, you know what I mean?
Ouf. Thanks for still reading. Here's my questions :
- Could you give me thoughts, hints or links about using client processing power in an EJB system. What can be done? what shouldn't be done?
- Do you know if it's thinkable to have a system as I described running in a normal EJB design (most of the processing done on the server) without the need to force our client to get a huge and expensive server? I've tried to find some metric about what processing power is required for that type/size of system but haven't found anything good yet...
Well, thanks in advance. Your help will be really apprieciated.
- Using client processing power by Costin Cozianu on February 27 2001 14:45 EST
- Using client processing power by raghu tss rao on February 27 2001 19:37 EST
- Using client processing power by Frederic Denis on February 28 2001 12:06 EST
"We also plan to add analysis modules to the client application (data mining, fuzzy logic decision-making modules, etc...) "
For this type of things you definitely don't do EJB at all. EJBs are for transaction processing and not by all means for data mining, complex queries and the like.
And probably you don't want to do data mining directly on your OLTP database, so you usually set up a second database where OLTP data will be pumped periodically.
The second database will be then specifically tuned for OLAP and physical data layout will be also optimized for OLAP as opposed to OLTP.
At the extreme if the cost is really an issue you can share the OLTP datbase between your EJBs and OLAP clients, but you have to be very careful in limiting the complexity of OLAP client queries.
This is definitely a bad thing to have and it can only be used in constrained environments where your database is not going to get over 1GB.
You can also consider for cost effectiveness that you can set the OLAP server as a no-cost solution (like PostgreSQL or mySQL for linux), which will actually reduce the costs of having a mixed (OLAP and OLTP) database in production.
If the data mining requirements are more than PostgreSQL can handle than they are definitely more than any major vendor OLTP database can handle while supporting transactions in the same time.
As I understand .........
If you follow the j2ee blue print recommendations for designing your application, then the client is just an HTML page. Java Server Pages are generated on the server and displayed on the client. So the client can be just a browser.
Now what information do you want to show on the client. Do you want to show the whole catalog on the client at once, I mean how does a client navigate the screens. A well planed navigation can cut down on the unwanted data being passed arround.
You can have validation done on the value objects....(see other disussion on this site for more info...) ie pass data to clients in normal java classes which only have getter methods and validation methods and setter methods for feilds you want modified. Always pass this java object from client / server.
Thank you both for your inputs.
I'm just starting to learn about OLAP and data mining, but I think I understand what you mean. Since data analysis is only reading stuff, and since OLAP database are optimized for such reading (thus have different table structure than the relational database used for transaction), it should not be built inside the EJB where the bean management will do unnecessary stuff (like bean creation, transaction management, etc...). Am I right?
So, no OLAP in EJB. But what about OLAP *with* EJB? I'll do a bit of research and might start a new discussion about it in a near future. Thanks again.
The Sun's blueprint for J2EE does talk about something else than Web-based clients. See the part on the EJB client in the client tier : http://java.sun.com/j2ee/blueprints/client_tier/ejb_clients/index.html
Beside that, I'll take a look to that validation thing you're talking about. I think that's the kind of thing I'm looking for. Thanks again.
Yes Dennis you got my point.
If your customer wants to have a data analysis capability (like performing statistics, spotting trends in the data and so on), you definitely have to have a second database to do that.
And the whole OLAP solution has to be built on a totally diferent technology then J2EE.
EJBs are for OLTP type of applications.
"OLAP with EJB" may sound interesting as a challenge but is probably an effort in vain.