Just finished developing prototyping web services using a simple Java class exposed as a stateless rpc web service to connect to Oracle. The java class simply packs/unpacks data and a PL/SQL stored procedure is called to do most of the work. The databases acceses are mostly simple get and update functions. We chose PL/SQL because we think that it will be more performant than using only Java. My question is: Would it useful to use stateless session EJBs for our Java layer? What are the pros/cons? Another question: Should we scrap the PL/SQL and use Entity Beans instead? We were using JDeveloper for our web services during the protoype and deploying to 9iAS. But the client requires that we use WebSphere so we're migrating to WSAD, but we're still using Oracle as our database. What are the implications of this?
There is no easy answer. If you're building a heavyweight application that requires transactions, process pooling and all the other heavy weight stuff that EJBs make easier (not easy I hasten to clarify) then definately use Session beans. If not then you'll just be acquiring a lot of extra baggage, compelxity and the need for more powerful hardware to do the same job for no benefit.
My question is: Would it useful to use stateless session EJBs for our Java layer? What are the pros/cons?
The overhead of using EJB is you need to invest on a ejb container, which is expensive, and few servies specific to ejb are started by default even if your app dosen't use them. But in your case because you already have a ejb container, I assume, I don't see a problem. I will normally represent a service as a session EJB (stateless) when it is going to be accessed frequently used and if it has to support transaction. The most important container services frequently used by the ejb is pooling and transactional support. The bright side of using ejb will be reduce the amount of code written but the dark side is deployment and maintainence is not intitutive.
Originally posted by Daniel Dor-Chay:
Another question: Should we scrap the PL/SQL and use Entity Beans instead?
I would be cautious when it comes to use of Entity EJBs, make sure whether your application does frequent access of same set of cached data, ie., it mostly does selects and updates. Then make sure you are in a clustered enviormnent or single server enviornment so you don't run into dirty data.
Villains always have antidotes. They're funny that way. Here's an antidote disguised as a tiny ad: