We are in the midst of developing version 2 or our e-commerce system. We run a data center where we are setting up ASP services. This product is designed to support many of our 'clients' businesses (books, car accessories, fast food, home appliances, etc.) so the structures of the 'entities' like categories, products, users, orders, etc. were completely flexible in the sense that we can add or take away attributes from the entities without altering the schema of the db. There is a 'catalog' table that specifies the structure for each entity within each of our clients. We then have a table of 'dynamic' values (with columns for strings, numbers, dates, booleans, etc.) that are tied to the different objects through an object id and the catalog.
Here is a brief schema:
In version 1 we had a domain layer of classes that handled all the interaction with the db through JDBC which for now has worked fine but the amount of clients is likely to increase and we need something that scales better.
What is the best way, with EJBs, to model this situation? We are relatively new to EJB and have read a lot about it. We have come up with two possibilities:
1) Model each of our tables as an entity EJB. This would probably work but there are thousands of 'dynamic' values, as many as 20 per entity like product, so if we have 10,000 products * 20 values, that's a lot. This would probably be an overkill.
2) Model each of our objects (a category or a product with their respective dynamic values) as an entity EJB. I think it sounds better, but we are not really sure. How would we tell the entity bean that it's not just one row of dynamic values but 20?
Where could we get more information on how to design or model problems in EJB? EJB design patterns? Any specific book, article or suggestion?
Thanks in advance.
Do the industry a favor and hire an EJB architect/developer.
Do yourself a little favor and disregard unpolite comments.
Do your self a greater favor and don't hire an "EJB architect". Don't hire any "architect" as a matter of fact, I'd add.
There is an inherent performance penalty in any totally dinamic design like yours.
Though the performance penalty may not be that bad, especially if you're able to tune your database.
But the fact that EJB technology would make a system perform better, well you have to take it with a little bit of doubt.
Don't consider vendor marketing materials, consider the fact that no EJB vendor posted any result for any TPC performance benchmark, more they are in the process in developping their own EJB benchmark, so the will not be able to compare with any competing technology.
A better thing to improve performance would be to consider an advanced caching product, so you'd be able to cache infrequently updated data with little effort in the application layer.
Why use entity beans for your catalog data?
It sounds as though this info is read only, so why not access it as plain java objects, created by a factory using JDBC?
You can have a simple cache which has a hook to allow maintenance apps to flush it when they change the underlying data.
What you need to do is to come up with a framework using Bean Managed Persistence. Here is what I mean by that.
Looking at your requirements, I see that the structure of (associational navigation) your Object model remains the same. That is, for one application, say A1 has a number of B1s, and B1 has a number of C1s...In a different application, this will be, say A2 has a number of B2s, and B2 has a number of C2s. (A1, B1, C1 etc being Classes). The only difference between A1 and A2 is in the number/type of variables in the Class.
Inside the BMP Bean, you can figure out which Java Class to instantiate, based on the object id. So, you will end up writing the BMP beans only once (with one JDBC call for each association navigation). But, for every new application, you will have to create a set of Business Classes (A, B, C etc). You can even have an Inheritance hierarchy here, so you get a lot of reuse.
You may benefit from using Java's reflection classes too, if you want to display all fields in these objects...
Just some thoughts...
It sounds like your table design is the classic problem of transposing multiple columns in a single row to multiple rows with a single column denoting type.
This gives you a problem using CMP with most vendors (Although you could use products like TopLink to do OR mapping.)
I would count out option (1) immediately. These are detail objects, if you model them as beans you're dead performance wise.
Option (2) sounds better. There are then 2 options to get the data into the bean from the database.
1) Use BMP as already suggested in this column.
2) Investigate options such as TopLink which will do this kind of thing for you.
But, before you do any of that, take a look at how often the data is read, versus written. In most EJB implementations each call to the bean will cause a read and write of the whole contents of the bean from and to the database. Now most vendors will let you mark beans as read only or specify an isDirty() method. But when you go that route you are using vendor specific features. In that sense you need to consider vendor along with the use of the technology.
My main recommendation here would be to look at the distribution of access across your data objects. If you have lots of clients accessing lots of objects then things will be reasonably OK with EJB. If you have lots of clients accessing a small number of objects, you can run into contention issues. (Basically, the same contention issues you get with any database, but moved from the database into the entity bean layer.)
A powerful caching engine might be a better bet.
PS. I would also suggest you ignore unhelpful, ignorant people who make comments like the first comment made in response to your asking a perfectly reasonable question.
I apologize for my previous comment. That day a number of my friends were laid off due to the company hiring some developers whose sole development experience comes from reading an EJB book and posting questions (such as "Pls. tell me how to write EJB program") on a discussion group such as this.
My comment was very inappropriate, especially considering the amount of assistance I have been given by many of the regular posters. Again, I offer my sincerest apologies.