Ejb design concern

Question

I have more than 40 tables in backend,
The corresponding entity beans have been designed
Now I want to use one or several stateless session beans as facade to exposed API to clients
What business logic should I put in the session beans?
How many session beans I am suposed to employ?
So far we do not have more business logics needed except for basic database operations (insert, delete, update, select)
The one problem is confusing me is that I do not know exactly how clients(servlet, or web service) do data access
What I want to do is to abstract most client access again database into several methods. How can i do that?
Is it a good idea to develop four stateless beans for delete, update, insert and select, respectively?
Or simply design one stateless session bean to include all methods mentioned above?
Any suggestion
Many thanks!

Answer 1

I have more than 40 tables in backend,
The corresponding entity beans have been designed
Now I want to use one or several stateless session
beans as facade to exposed API to clients
What business logic should I put in the session
beans?Rather than starting with your 40 tables and pushing outwards towards you application, try taking your application design, thinking about what it wants to do, and then push inwards. While read/writing/updating data is a large portion of application design, the more important parts tend to be the data relationships and the data processing. Those are the portions that require all of the reading/writing/updating of the data. You don't read data for no reason.
For example, say you have a typical order entry distribution system. When you ship an order, you could easily have to a) update the actual order data, b) generate a shipping record, c) add to order history d) notify the customer via email.
While that may well access four different tables in the database, it's really only a single process, and may well be a single method: OrderSessionBean.shipOrder(Order o).
The OrderSessionBean could easily interface with the CustomerSessionBean.sendShippingNotification() routine, and the ShippingSessionBean.createShipment(...) routine.
But that's the rub, isn't it. Should OrderSessionBean create the shipping data (since it's based on the order), or should the ShippingSessionBean create the data. Basically that's a judgement call. On the one hand, you don't want a single session bean that's your entire applicaiton. That's just madness and very difficult to maintain. On the other, you don't want a session bean for every individual method in your system.
So you need to balance the two extremes and try to come up with a good balance. But you just remember, the data doesn't exist in a vacuum. Those tables are there for a reason. Let the application needs drive this, don't simply make interfaces for no purpose.