This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Can you, or is it wise to, use session beans without using entity beans? The reason I ask is that for our upcoming project, most of the data is going to come from external APIs. So, from my understanding, we won't be able to create entity beans to access that data. We'll just write beans to access the information from the external API using JNI.
Sigh. There is a STRONG difference between what the spec says (or "suggests" in the case of JNI) and what you can really do. In theory using JNI is verboten, yes, but in practice, people do it within EJB containers all the time. As with so many "forbidden" things the fact is that if you don't put JNI methods directly in the beans themselves, but put them in helper classes called by the beans, that this will work fine. We've got several customers doing this now, and we don't expect it to stop working any time soon. One thing you must be careful of, though is classpath issues. We've found that you need to make sure that your JNI code is loaded by the first classloader in your application server (however you determine that) to make sure that you don't get into the dreaded "attempt to reload DLL" issues that happen when higher-level classloaders bounce. Kyle
Another good point to bring up is that Entity Beans are not just for database persistance. I have a system that we access external APIs through provided classes (not JNI, XML over HTTP), and use them as BMP Entity Beans. The APIs are for entity bassed information such as customer and account and it works beautifully (proper handshaking for rollbacks was required)! Be sure to think about whether these APIs are calling entity type objects, and if the business logic would allow for a Entity bean design. If this app is the sole user of this underlying "data" you could truly benefit from the caching of EJBs in 2.0!
Joined: Jun 27, 2002
Kyle, we'll be using WebSphere. You said I shouldn't place any JNI code in EJBs. Is this something that Java will simply refuse to compile or is there another reason for suggesting against it? Is your recommendation to create a simple Java class(es) that would have the JNI code in it and then call that class(es) from the Entity Beans? They API will be used to retrieve Entity related data.
Joined: Aug 10, 2001
Originally posted by Michael Brewer: Kyle, we'll be using WebSphere. You said I shouldn't place any JNI code in EJBs. Is this something that Java will simply refuse to compile or is there another reason for suggesting against it?
The EJB validator will kick it out if you try it. The code will compile but you'll never be able to use it.
Is your recommendation to create a simple Java class(es) that would have the JNI code in it and then call that class(es) from the Entity Beans? They API will be used to retrieve Entity related data.
Yes, just create standard Java classes with JNI interfaces. THEN you will need to place them outside your EJB-JAR file on the lib/ext path (I think lib/ext...I'll have to check that). Otherwise everytime your server bounces you'll get an error about "reloading an already loaded DLL"... Kyle
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com