You can always use the transaction services in a J2EE app server - with or without EJBs. The catch is you have to open,commit,rollback explicitly in code using JTA.

More to the point, I've rarely worked on systems that required transactional semantics that didn't exactly map to the single database I was using. Furthermore, typically the DB is the only transactional component I have. So I could just use JDBC transactions and be fine. Or, use EOF from WebObjects (which is now deployable within J2EE app servers - the build makes you a .war file) which manages database transactions for you via editing contexts. One exception I guess is using JMS queues. These can also participate in transactions. But I rarely need one of these and generally I find its easier to design things to be idempotent and guarantee that they happen at least once than it is to deal with distributed transactions.

The single biggest benefit of using Session Beans that I can see is the ability to specify transaction semantics declaratively in the deployment descriptor - assuming you think programming in xml is some kind of benefit over programming in Java. The current trend in EJB's also seems to be to deploy them locally into the same process as the web tier rather than pay the costs of remote calling. I never understood the drive to locate them remotely when doing web apps anyhow.

I've never used EntityBeans and all that I read about them implies they are a solution in search of a problem. Avoid them. Better to make use of a conventional OR mapping layer like TopLink, EOF, or one of the new JDO implementations like SolarMetric's (which I've seen demo'd but haven't used - it looks a lot like EOF).

I've probably bought half a dozen books on J2EE to brush up on my skills (plus I'm working on this app originally written on WebLogic 7). Of the lot of them, the one that seems the most sensible is Rod Johnson's "J2EE Design and Development". He's absolutely objective, unlike the vast majority of the J2EE cheerleaders out there publishing pie in the sky architecture guides.

His chapter on EntityBeans ends:

"I was enthusiastic about the idea of entity beans whent they were first described as an optional feature of EJB1.0. As recently as the first draft release of EJB2.0 in June 2000 I was hopeful that the limitations that I and other architects had encountered working with entity beans in EJB 1.1 would be overcome, and that entity beans would become a strong feature of EJB. However, I have become progressively disillusioned.

Entity bean performance has proven a problem in most systems I have seen that use entity beans. I have become convineced that remote access to eneity beans and the transaction and security management infrastructure for entity beans is architecturally gratuitous and an unnecessary overhead. These are issues to be handled by session beans. The introduction of locan interfaces still leaves entity beans as unnecessarily heavyweight components. Entity beans still fail to address the hardest problems of OR mapping.

My feeling is that JDO will supplant entity beans as the standard-based persistence technology in J2EE. I think that there's a strong case for downgrading the status of entity beans to an optional part of the EJB specification. Entity bean support counts for well over a third of the EJB 2.0 specification (as opposed to slightly more than a fifth of the much shorter EJB 1.1 specification), and much of the complexity of EJB containers. Removing the requirement to implement entity beans would foster competition and innovation in the application server market would help JDO become a single strong J2EE standard for accessing persistent data. But that's just my opinion!"

That's about mine as well. Remove EntityBeans and you're left with a mechanism that looks a lot like a corba server. Within that server, you can access data anyway you like. Whether those business process objects need to be remoted at all is a whole other consideration but generally I'd assume they live in the same process as the web tier unless they are providing an interface for some other server. And as I mentioned elsewhere, remove EJB's seem to make sense for message driven beans handling async requests.

Although I don't quite understand enough about what you're doing to know how you're going to use transactions outside the db without the hassle of writing OTS compliant resources. But based on what I'm hearing, that sounds like the direction for you.