1. You can have as many datasources as you need. There are reasons of performance, the spread of corporate data and so on that dictates that J2EE applications must be able to integrate data from multiple sources, if you view the J2EE tier or layer as the gateway between the user and corporate data.
2. Review http://www.amitysolutions.com.au/documents/JBossJNDI-technote.pdf to view the mapping of relationships between a calling component and a resource. Use *-ds.xml to define your datasources - you can find templates in JBOSS_HOME/docs/examples/jca for the major databases. You deploy the *-ds.xml files in JBOSS_HOME/server/default/deploy (if you are using the default run-time instance.
3. View the DTDs in JBOSS_HOME/docs/dtd.
4. A session bean is used to perform some sort of business logic - so it can perform complex functions on multiple datasets from multiple sources, for example - e.g. Check that an order has been generated in the ordering system, that the shipping system has dispatched items from the order and generate a notice to the sales representative. A BMP or CMP instance is usually representative of or the dual of a database row. So an instance of a BMP represents an "entity" from one data source and clearly has limited capability for higher level functionality. You usually use a BMP over a CMP when you can't achieve the necessary data retrieval via the CMP or can't do it in an efficient manner. There are tradeoffs for using CMP/BMP over a session bean - for example, an unlimited retrieval could generate hundreds of entity instances if you have a large database table, which could be an overkill, and not very scalable.
As with any application of design principles, YMMV. The commonsense embodied in the Agile Manifesto should be the guiding principle. :-)
Thanks for the great reply. I'll need to take some time, read through the references and digest it.
Your reply for #4 did bring up some further questions.
In reference to BMP/CMP correlating to a row in a database, are you saying that it is goor practice to have a ejb instance for each row returned? or am I just not understanding how BMP/CMP works?
I just want to restate this so I am sure I understand: a session bean is where I should house business logic and data access should be housed in BMP/CMP beans. Although it may be okay to house data access in the session bean if it makes design sense.
I am not familiar with what you are talking about in the last paragrah; YMMV, and Agile Manifesto. Can you explain these or point me to a resource?
Do you have a book(s) you would recommend for understanding the basic concepts of J2EE programming?
4.1 - It is not "practice", it is just how entity beans operate. With a CMP/BMP find operation, you find all rows that match a certain criteria. Each row returned will be stored in one CMP/BMP instance. You don't get to control this. The only thing you can limit is the find criteria. Usually it is bad practice to allow a findAll. Say you have a table with 1000000 rows. Doing a findAll would consume a lot of resources - now suppose you have hundreds of users running the same operation at once. CMP/BMP might be considered to be not all that bright if you were to attribute human qualities to them - they are just data containers in a sense. So usually, you have the session beans do the "thinking" with business logic.
4.2 - Yes. If you are into Patterns, TheServerSide website documents a lot of variations for configurations of these components. The Iterative Data Access Pattern is a nice one to look at as it is simple in terms of explaining the mechanics of a two component type configuration - http://www.theserverside.com/patterns/thread.jsp?thread_id=21434
4.3 - YMMV; Your Mileage May Vary. Agile Manifesto is a development approach that is touted as new but isn't really but embraces commonsense, and states that working software is the measure of progress. Martin Fowler's intro into some of the principles of an agile methodology might help - http://www.martinfowler.com/articles/newMethodology.html. Essentially, all I'm saying is that your situation may dictate different component configurations and don't be a slave to convention if after considering all the facts, it still seems idiotic. Nothing is absolute.
I still like Mastering Enterprise JavaBeans by Ed Roman although my copy is now ancient and tatty.
Hope that helps.
Yes, that definitely helps.
Thank you very much for your replies. I shall now go and act like a sponge with the resources you gave me.
Just on the methodolies used ian an J2EE envronmnet.
SUN's site has a dedicated ares for J2EE patterns.
Its not that rich as on severside. But covers a lot.
Having said that, as Jonlee pointed out that it dpends on yr situation so just dont get bogged down into patterns.
Thanks to Jonlee, its really a good explaination.
I believe the posts on this thread have answered my question but I shall ask it anyway just to make sure. It is my understanding that when an EJB/CMP is deployed it is connected to a specific datasource using the username/password supplied in the applicable *-ds.xml file. (in my case the oracle-ds.xml file). This implies that all the selects/inserts/updates/deletes that the bean does against the database are done as that username. The only way for another user to use the bean and connect to the database using his username/password is to deploy the bean using a different datasource definition that has a different username/password.
Is this correct?
One of our main requirements is that each user of our web app connect to the database using their own username/password. Is the only way to achieve this using CMPs is by deploying a bean for each user? We are wondering if CMPs are the best approach given the above requirement.
Any insight is appreciated.
There are ways around this. However, they usually employ the use of specific username/password connection requests. It requires the use of BMP which complicates the generation of entities. You must track sessions. It also detracts from the connection pool advantages.
There are a couple of reasons for having an application owned database account:
2) efficiency through connection pools without the extra connection authentication
3) decoupling data <-> object duality from security and placing security at an object level or higher tier
Using a bean implementation for each user would be wasteful of resources, gives up much of the resource efficiencies of having a scalable, adaptable middle tier with reusable components, and complicates security management.
MHO. There are of course, always exceptions dependent on your situation so YMMV. You have to weigh up the balance of the forces for the particular problem you are solving.