Hani Suleiman (of the BileBlog) has an opinion piece in the June 2004 Java Developers Journal titled Exposing J2EE Urban Myths. Ted Neward walks us through these assertions and weighs in with his views. What are yours?

The Myths

1. Myth: JNDI is awkward: +1 Hani nails this one, IMHO. JNDI is an awesome API and highly underutilized; in particular, I think every J2EE developer should at least play around with the example in-memory-based JNDI SPI Provider given with the JNDI Tutorial and look at ways to use JNDI to create a layer of indirection for lookup purposes. Particularly when combined with JNDI's federation capabilities, suddenly you have ways of identifying things in an entirely agnostic manner. This is powerful, much akin to COM Monikers or CORBA IORs.
2. Myth: J2EE is difficult to develop in: -1/+1 It is difficult to develop in, mostly because J2EE's goal is to address high-scale enterprise systems. J2EE was never intended (at least, not at first) to be used in applications that won't go beyond departmental boundaries, despite the fact that this is where 70-80% of projects are. (Correspondingly, I've heard estimates that the large-scale enterprise apps, although rare, are where upwards of 70% of the money in J2EE is spent. Suddenly the reason why frameworks/lightweight containers like Spring or Nano/Pico-container are taking off makes more sense.) But Hani's point is well-taken: not everybody needs every facet of J2EE, such as needing EJB for every project, or JTA/XA transactions when working with a single Resource Manager.
3. Myth: EJB must be avoided at all costs: +1 EJB is all about distributed transaction processing. If you need that, use EJB. If you don't (or if you don't know what it is), then stay away. 'Nuff said.
4. Myth: J2EE is dead!: +1 Can't prove it by me, guys. I get about a 50/50 split in J2EE and .NET requests, so if J2EE is dead, so is .NET.
5. Myth: J2EE is unportable: +1 Hani's right: "Expecting it to be a trivial matter of dropping in the .ear file is naive and akin to expecting a Windows-developed Swing app to work flawlessly on an OS/X machine without a single misplaced pixel." More importantly, achieving J2EE-portable (what I prefer to call "vendor-neutral") code is something that you should openly decide you need, not decide by default, since you run the risk of forfeiting useful vendor optimizations when you do.
6. Myth: J2EE is expensive: +1 Again, Hani hits this one on the head when he says, "The hidden aspect of expense is the nonmonetary costs associated with it.", such as finding someone who's "comfortable in a J2EE environment". In fact, I'd argue that for any J2EE project to truly succeed, you need someone who's more than just comfortable in it, you need someone who's achieved Master status to lead the team--which is probably J2EE's biggest weakness.
7. Myth: API "X" is too complex/unclear; it's easier to roll your own instead: +1/-1 Too many people are trying to "roll your own" lots of things, but sometimes there are situations where it's easier/simpler/more reliable to roll your own "X", so long as you're comfortable with the API in question--and in this sense, Hani's exactly right. Rolling your own "X" because you don't understand "X" is clearly a Bad Thing; rolling your own "X" because you find flaws with "X" and need to clear them up or do things "X" doesn't let you do or because "X" is simply too awkward and clumsy for what you need isn't intrinsically bad, so long as you can explain to another programmer exactly how it is that "X" works. If you can't, then rolling your own is probably an Even Worse Idea. For my money, the list of Banned Roll-Your-Own Technology "X" ideas includes object/relational layers (in fact, I'm not even a fan of the ones that are out there right now, either), connection pools, object pools (which are a terrible idea except under very specific circumstances), more MVC-based web frameworks, JDBC library wrappers ("to hide away the SQLExceptions"), and any attempt to write your own Spring/Nano/Pico-like lightweight container.
8. Myth: Petstore is a reference implementation: -1 Sorry, Hani, but Petstore was a reference implementation when it was first released. It was clearly billed as a "right" way of building J2EE apps, and the fact that it did all the things that we today see as terrible ideas is clear indication that Sun didn't quite understand yet how to use their own technology--which is no shameful admission, since it usually takes 5 years or so to "figure out" any technology (even those that are moderately complex). Just imagine all the fun the .NET world will have in the next three years or so....
9. Myth: J2EE is useless without extra frameworks: +1 There's a tendency amongst J2EE folks to want to make use of every latest framework or toolkit or aspect-oriented-whatever, and Heaven forbid you actually just sit down and use the J2EE functionality out of the box. In fact, the tendency of any J2EE environment is to want to create layers on top of layers on top of layers on top of layers.... "just in case we want to change anything". Folks, if you need to change something, you can rewrite the code later--there's no shame in that. There is, however, major shame in introducing so much indirection that it takes your system twelve days to respond to a single HTTP request.

Read J2EE Urban Myths

Posting a response is not particularly helpful without a link to the original article.

1. Myth: JNDI is awkward: +1 I like the fact that it is very simple but I agree with Ted.
   
   
2. Myth: J2EE is difficult to develop in: +1 Debuging is a real problem due to the container dependency. Even though some parts of the J2EE application can be tested without needing to run the code in container, still big problem for the rest.
   
   
3. Myth: EJB must be avoided at all costs: -1 I would say 'avoid EJB if you can'. EJB is for transactional centralized business logic and data access. I think this is very valuable.
   
   
4. Myth: J2EE is dead!: -1 I think people are mostly trying to avoid EJBs not J2EE entirely. how many people are trying to avoid JTA, JMS, JCA? Yes there is a move towards micro/lightweight-containers and such but not so many. It is just that people who uses them make a lot of noise.
   
   
5. Myth: J2EE is unportable: +1 In addition to its unportablity, it is painful experience to upgrade. imagine upgrading an entire application from EJB 1.0 to EJB2.0.
   
   
6. Myth: J2EE is expensive: +1 Hani and Ted said it all.
   
   
7. Myth: API "X" is too complex/unclear; it's easier to roll your own instead: -0- no comment.
   
   
8. Myth: Petstore is a reference implementation: -1 I never thought Petstore was a ref. impl. when I learned J2EE, and looked at Petstore, I said I wouldn't write it that way. It was long time ago. I have never looked at Petstore again.
   
   
9. Myth: J2EE is useless without extra frameworks: +1/-1 I would say 'J2EE is more useful with extra frameworks'. I like JTA, JMS, JCA and they are very useful but I like to use them with my favorite web app. and persistance frameworks.
   

-talip

On point #3 about distributed transactions:

It looks like the Spring/Hibernate story for managing distributed transactions is improving ( http://hibernate.bluemars.net/110.html ). Just curious, is anyone doing distributed transactions with Spring/Hibernate? Maybe 6months from now it won't be so easy to state that EJB has the best solution for dis. transactions.

CP

On point #3 about distributed transactions:It looks like the Spring/Hibernate story for managing distributed transactions is improving ( http://hibernate.bluemars.net/110.html ). Just curious, is anyone doing distributed transactions with Spring/Hibernate? Maybe 6months from now it won't be so easy to state that EJB has the best solution for dis. transactions.CP

The nice thing about using EJBs to manage transactions is that the container is written by people who really understand transaction semantics and -- more importantly -- understand how those semantics are implemented in the specific application server itself. The trouble with frameworks that want to take over the role of the EJB container is that they really don't know how the application server handles protocol invariants for transaction processing. So even if they have a full grasp of transaction processing requirements, it's not clear how or if they can usefully "shake hands" with the application server internals to ensure they are enforced. Knowledge of JTA isn't enough. For that reason, we recommend EJBs for applications that have serious transaction processing requirements.

Greg
author, Java Transaction Processing: Design and Implementation

Do you really mean entity beans for serious transaction processing requirements, or just session beans to start a container managed transaction? Or is Hibernate (or any other mapping framework) using an application server's transactional data source as good as entity beans in this respect?

Do you really mean entity beans for serious transaction processing requirements, or just session beans to start a container managed transaction? Or is Hibernate (or any other mapping framework) using an application server's transactional data source as good as entity beans in this respect?

I was thinking in terms of session beans.

Greg

First of all, Spring has supported distributed transactions via JTA right from the beginning, and does so in an even more sophisticated fashion since 1.0. Alternatively, it supports local transaction strategies too.

Spring's JtaTransactionManager offers the full power of JTA, i.e. of javax.transaction.UserTransaction and javax.transaction.TransactionManager, including transaction suspension. It supports all 6 propagation behavior defined by EJB (PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW, etc).

All of these transaction capabilities can be leveraged in a programmatic fashion or in a variety of declarative fashions, ranging from proxy definitions and automatic bean post-processing to transaction attributes in source files.

The trouble with frameworks that want to take over the role of the EJB container is that they really don't know how the application server handles protocol invariants for transaction processing. So even if they have a full grasp of transaction processing requirements, it's not clear how or if they can usefully "shake hands" with the application server internals to ensure they are enforced. Knowledge of JTA isn't enough.

To the best of my understanding, JTA defines clear enough semantics. After all, JTA implementations can and are used directly, both in a J2EE container and standalone. I don't know of any standard EJB CMT feature that goes beyond JTA; IMO, CMT is just another way to drive the transaction manager's functionality.

If you're implying that sophisticated transaction management cannot be built on plain JTA, then what is JTA good for at all? What are those server-specific "protocol invariants" that a JTA client needs to worry about despite JTA's abstraction? Where are the gaps in JTA?

So please state details on why "JTA isn't enough"; as it stands, this can hardly be accepted as proven fact. Fact is rather that many people are happily using plain JTA - and Spring's transaction capabilities built on JTA - in demanding environments, without obvious issues.

Juergen

IMO, CMT is just another way to drive the transaction manager's functionality.If you're implying that sophisticated transaction management cannot be built on plain JTA, then what is JTA good for at all? What are those server-specific "protocol invariants" that a JTA client needs to worry about despite JTA's abstraction? Where are the gaps in JTA?So please state details on why "JTA isn't enough"; as it stands, this can hardly be accepted as proven fact. Fact is rather that many people are happily using plain JTA - and Spring's transaction capabilities built on JTA - in demanding environments, without obvious issues.Juergen

You're talking about the client view -- which is a bit different than the container view of JTA. While there are problems with the client view as well that the container really needs to address, I'm saying that if you expect to write a container -- whether it be "lightweight" or compliant to a spec -- with only reference to what's present in JTA, you're going to get something that isn't complete. So let me back up the assertion with some experience: I have worked on (starting with EJB 1.0), five EJB servers. Two I designed and more or less implemented myself. In not a single case did JTA alone provide a sufficient contract for dealing with all aspects of the protocol invariants required to maintain acid properties. In at least two cases, we imported a "third party" JTA implementation (eg, Arjuna) into an application server environment (eg, HP Application server); it required significant wrappering at the application-server/container level to deal with deficiencies/ambiguities in the APIs and protocol invariants associated with transaction processing that just aren't addressed. The latter include cancelation mechanisms to preserve consistency, protocol errors, optimal caching, and recovery scenarios. To do it right -- to deal with all boundary cases -- you need more than just JTA. We do spell out some of this in the book in detail, incidently, which is based on our experiences implementing several transaction services, EJB containers, and virtually every component of J2EE.

The obvious question is whether many of these boundary cases are important. I would argue that's the whole point of transaction systems, to deal with unlikely conditions -- not "obvious issues -- that nonetheless jeopardize consistent views in the system. Perhaps Spring doesn't address these kinds of problems, which may be a reason to prefer EJBs in a hardened application server from a reputable vendor *for certain classes of applications*.

Greg
author, Java Transaction Processing: Design and Implementation

deficiencies/ambiguities in the APIs

Greg, this is an interesting claim. If this claim is accurate, surely the best way to go would be to fix JTA in a new version, rather than every usage of JTA having to layer over its deficiencies. Does your book detail a proposal for a new version of JTA?

Also, are you claiming that JTA/JTS suffers considerable deficiencies but XA does not?

Don't suppose your book can be downloaded for free? :-)

Also, in what public forums have these claimed JTA deficiencies been mentioned or discussed before?

Greg, this is an interesting claim. If this claim is accurate, surely the best way to go would be to fix JTA in a new version, rather than every usage of JTA having to layer over its deficiencies.

I completely agree. This would not only affect Spring's transaction demarcation means on top of JTA, but also every *direct usage of JTA*. Remember that the J2EE spec indicates that BMT respectively direct usage of JTA is supposed to be an equal alternative to CMT. Greg is more or less claiming that everything but EJB CMT is potentially broken.

Effectively, what Greg is saying is a transaction manager implementation's native API is the only way to get reliable behavior in all cases - which clearly indicates a deficiency in the JTA API. This is quite a significant claim that would have to be resolved by an updated JTA spec. This would not be a Spring issue; many people using JTA directly would be affected by this.

I'm wondering about the details here: All that declarative transaction demarcation means like EJB CMT have to do, basically, is delegate to JTA UserTransaction/TransactionManager's begin/commit/rollback/suspend/resume methods in accordance to the specified propagation behavior. This should be equivalent to using these JTA methods directly.

The protocol details - including proper recovery, dealing with protocol errors etc - are supposed to be handled by your JTA implementation. The JTA API is just meant to provide abstract transaction demarcation means. Why should transaction *demarcation* code have to worry about protocol details? All it should be concerned with is proper use of begin/commit/rollback.

Juergen

Greg: "a reason to prefer EJBs in a hardened application server from a reputable vendor"

The so called "hardened application server" is down at least once a week..

A maintenance nightmare,
http://www.esj.com/enterprise/article.asp?EditorialsID=785

Regards
Rolf Tollerud

Greg: "a reason to prefer EJBs in a hardened application server from a reputable vendor"The so called "hardened application server" is down at least once a week.. A maintenance nightmare,http://www.esj.com/enterprise/article.asp?EditorialsID=785RegardsRolf Tollerud

Hard to believe this article, but
can you recommend better (proven in practice) alternatyve if this is true ?

Juozas: Hard to believe this article, but can you recommend better (proven in practice) alternatyve if this is true ?
 
How can I know for sure? A real test like the ones that The Middleware does cost at least in the area of $50-60 000. But I can give you an educated opinion.

A servlet container with Spring or other similar lightweight framework perform more or less as .NET, give or take 10% in either direction. .NET perhaps does win a little in productivity but Spring wins on maintenance. With everything so similar what else can you expect?

On the other hand the J2EE Expensive EJB server is a total disaster from all directions, productivity, maintenance, performance and price. Just think of all the bugs it must be in these millions of lines of code!

Of course Vic with his plain POJOs and IBatis blow away all :)

Regards
Rolf Tollerud

Greg: "a reason to prefer EJBs in a hardened application server from a reputable vendor"The so called "hardened application server" is down at least once a week.. A maintenance nightmare,http://www.esj.com/enterprise/article.asp?EditorialsID=785RegardsRolf Tollerud

Two quick observations: this is report from a management software vendor trying to prove the need for their product; it says nothing about the implied semantics of a transaction service implementation.

According to Bill Roth at Sun the EJB were written for and by the systems software architects at the roughly 80 companies in the world that build distributed/remote transactional software.

That was many years ago and as there has arrived more modern techniques (SOA/Web Services) since then perhaps the number now is down to 4,5 something.

"Distributed/remote transactions never will work perfectly anyway, they are dirty - like replications". Feel free to quote me on that. Or ask Mike Spille. There is a guy that is as far from being a theoretician as it is possible in this world.

The riddle: "What is more dangerous then a Well-meaning Impractical Theoretician?"

Regards
Rolf Tollerud
Answer: "A Well-meaning Impractical Theoretician with a mission"

If there's any technology that's proved it's usefulness for business critical systems over the last thirty years, it's transaction processing. Practice preceded theory by a long shot, as everyone knows.

Greg

We are not talking about the ordinary boring diet of bread and butter transactions of commit/rollbacks, but distributed/remote transactions with EJB that almost no one is using, and about that those who do almost certainly would be better off with another solution.

To be so extremely interested and waist so much time talking endlessly about those faulty and broken solutions (almost always a try to patch up some legacy systems) is a sign of unhealthiness. "If you can not compete pretend you are some far out type of specialist and everybody will think you are a Guru". Why don't the J2EE guys make their systems perform first, and make them stand up before they try to excel?

"You must crawl before you can walk"

Regards
Rolf Tollerud

You're talking about the client view -- which is a bit different than the container view of JTA. While there are problems with the client view as well that the container really needs to address, I'm saying that if you expect to write a container -- whether it be "lightweight" or compliant to a spec -- with only reference to what's present in JTA, you're going to get something that isn't complete.

Remember that Spring is not about server infrastructure and system services; it is not an application server. Don't confuse different meanings of the word "container" here. Spring is rather about the application point of view: It simplifies the client side of things, providing appropriate container facilities within applications (for example within a WAR).

So in that respect, Spring uses the JTA client view underneath and can be directly compared to direct JTA usage. Any problems that it faced would affect direct JTA usage too - because it would mean that the JTA client view would not be complete. I already pointed out that a broken JTA client view would amount to a wide-reaching issue, far beyond Spring.

Perhaps Spring doesn't address these kinds of problems, which may be a reason to prefer EJBs in a hardened application server from a reputable vendor *for certain classes of applications*.

I agree that choosing a trustworthy transaction manager implementation is important for demanding scenarios. However, if I buy WebLogic Express - which includes the full, hardended, reputable WebLogic transaction manager - and use direct JTA to demarcate my transactions, I expect it to work correctly. Are you suggesting that WebLogic would not behave properly in all cases in such a scenario? WebLogic Express customers would certainly want to know that.

Juergen

It's also worth pointing out that one of the nice things of treating transaction management as an aspect, which Spring does in the case of declarative transaction management, is that application code is decoupled from the details of the underlying transaction infrastructure. Thus, for example, you can use local transactions with JDBC, or JTA transactions, without changing Java code. This also means that for distributed transaction management, the JTA transaction manager isn't the only option. Server-specific implementations of Spring's PlatformTransactionManager interface could therefore tap into particular capabilities not found in JTA, without affecting the programming model seen by the application developer. Of course, such platform-specific APIs would need to be published...

Rgds
Rod

I didn't think this was anything new or controversial. The way JTA is designed and typically the manner in which it is implemented assumes that the user visible API is limited to the UserTransaction implementation, which allows very simple demarcation control (begin, commit). The rest of the TX spec mapping is, as you know, expressed in the TransactionManager interface: this API was intended for EJB containers to use (see the old EJB 1 and JTA specs); in practice, that meant it was essentially a guide for application server developers. As such, it's not at all uncommon for implementation assumptions in the TransactionManager to be shared by other internal components in the application server.

Take a very simple example: it's a mistake to assume, for example, that all implementations of JTA will treat the error characteristics of UserTransaction.commit and TransactionManager.commit as equivalent. The former, for example, would presumably never expose the ambiguous SystemException to applications, while the latter may expose SystemExceptions from commit to containers under the assumption that they have appropriate understanding of the implied, implementation specific semantic to make appropriate decisions. The point being, you don't know. It's a bad practice to assume that the TransactionManager should be regarded as a public API.

Sorry for the delayed reply -- I'm out of town and only by a computer intermittently.

Greg

The rest of the TX spec mapping is, as you know, expressed in the TransactionManager interface: this API was intended for EJB containers to use (see the old EJB 1 and JTA specs); in practice, that meant it was essentially a guide for application server developers. As such, it's not at all uncommon for implementation assumptions in the TransactionManager to be shared by other internal components in the application server.

I understand that there might some assumpations in an EJB container that depend on the concrete JTA implementation used underneath. However, they could just be very minor: Proper recovery and co needs to be done at the JTA level, else the JTA client view would be inherently broken.

No sane J2EE server will just apply proper recovery for EJB CMT but not for the JTA UserTransaction respectively EJB BMT, when it easily can move that recovery logic into the JTA implementation, to be available for all use cases. What would be the rationale for treating those differently?

It's a mistake to assume, for example, that all implementations of JTA will treat the error characteristics of UserTransaction.commit and TransactionManager.commit as equivalent. The former, for example, would presumably never expose the ambiguous SystemException to applications, while the latter may expose SystemExceptions from commit to containers under the assumption that they have appropriate understanding of the implied, implementation specific semantic to make appropriate decisions.

What kind of appropriate decisions would the EJB container be able to make on specific SystemExceptions thrown from TransactionManager.commit? The XA transactions has already ended and it unrecoverable, else the TransactionManager would not have thrown a SystemException but applied the appropriate behavior itself. What magic, concretely, could the EJB container apply that couldn't be handled by the JTA implementation itself?

So you are implying that the JTA client view respectively EJB BMT is less capable than EJB CMT, because UserTransaction's commit might not apply all recovery options? That's hard to believe, and an indication of an awkward JTA implementation. As I already said, that's bad news of all direct JTA respectively BMT users, and definitely not known by 99% of them, so indeed quite controversial.

It's a bad practice to assume that the TransactionManager should be regarded as a public API.

Well, if it is just meant as internal API for EJB container implementors, why is it part of JTA then rather than part of EJB itself? Why is it specified at all when each container vendor could simply use its own proprietary API there? The fact that it still is an interface that's part of the JTA spec is an indication that is a public API, just not for the average user. If there are gaps in the semantics, the JTA spec needs to be fixed accordingly.

Also, let's not forget that there are standalone JTA implementations available, and that some J2EE servers have pluggable transaction managers. The natural common interface for both sides is the JTA TransactionManager interface: If the transaction manager is pluggable, all the EJB container can do is to trust the semantics of the TransactionManager API. (Or it would have to resort to custom TransactionManager adapters for each JTA implementation.)

It's arguably bad design to specify a complete low-level API (JTA) and then rely on internal implementation details in higher-level usage of that API (EJB CMT), particularly if there are other but equivalent usages of the low-level API
(direct JTA respectively EJB BMT). This is an indication of the "monolothic container" view and definitely far away from the "pluggable system service" vision that J2EE servers like Geronimo, Jonas and JBoss advocate.

Juergen

I'm not sure why you would assume that SystemException equates to non-recoverable outcomes. I think you misinterpreted that altogether. But I did want to comment that "minor" assumptions that a container may make about transaction semantics are exactly why you want a fully integrated system. Most of the time you may never care. But presumably you're using this kind of technology to protect you for the boundary cases -- transaction systems matter most when things go wrong.

The examples you gave for pluggable transaction systems are systems that have incomplete transaction support. But I think your point is important: at Bluestone we were early pioneers in the composable, service framework architecture for application servers. The CSF (later JSR 111) was the basis of the kernel architecture for HPAS. As an internal design it was a good idea, but doesn't obscure the fact that the transaction core has extended semantics that other pieces have to be aware of, including replication and fault tolerance characteristics that can have serious implications for maintaining ACID outcomes. That's a practical reality that was driven home for me when we actually implemented all this stuff.

Yes, there are standalone JTA transaction managers. That doesn't mean they are all equivalent either. I've seen all kinds of interesting variability in JTA implementations when we were supporting pluggable transaction services at Bluestone prior to acquiring Arjuna solutions, and we frequently had to downcast to deal with the differences.

You may feel that in an ideal world all transaction systems would be exposed in equivalent ways. That's a dicey proposition and it's just not the world we live in. I'm not trying to criticize your work, these are just issues to be aware of. Four years ago I would have argued on your side. Working with this stuff made me change my mind.

Greg

But I think your point is important: at Bluestone we were early pioneers in the composable, service framework architecture for application servers. The CSF (later JSR 111) was the basis of the kernel architecture for HPAS. As an internal design it was a good idea, but doesn't obscure the fact that the transaction core has extended semantics that other pieces have to be aware of, including replication and fault tolerance characteristics that can have serious implications for maintaining ACID outcomes. That's a practical reality that was driven home for me when we actually implemented all this stuff.

Greg, I am finding hard to shake the impression that you have given up on having a standard and complete set of interfaces for implementing transactional behaviour including replication and fault tolerance characteristics. Do you really find it acceptable that all such interactions are not confined to standard interfaces? Don't you think it would do good things for the reliability of application servers if all such interactions were confined to standard interfaces even if modules from different vendors weren't being plugged together?

I guess we're missing our points here a bit. My main point is that Spring's JtaTransactionManager - to a large degree - acts just like a direct JTA user, working with the JTA UserTransaction of the underlying J2EE server: Any problems faced there affect direct JTA usage too.

To clarify the details: Spring's JtaTransactionManager optionally accesses JTA TransactionManager functionality, but just for transaction suspension, i.e. suspend and resume on PROPAGATION_REQUIRES_NEW and PROPAGATION_NOT_SUPPORTED. It does not even need the JTA TransactionManager reference in all other usage scenarios, working with the JTA UserTransaction else.

Your point regarding SystemExceptions implies that EJB CMT does some magic there that direct JTA UserTransaction usage does not give you. I just wonder what that could be that the JTA implementation couldn't do itself. Why move such recovery logic up to the EJB CMT level when it could easily happen within the JTA implementation, available to any client view?

Your point inevitably leads to the conclusion that direct JTA usage (i.e. EJB BMT) is somewhat broken, respectively less capable than EJB CMT. This makes your point quite controversial, as it is by no means common knowledge in the J2EE community. You've still not addressed that consequence.

If there are indeed semantic differences between commit/rollback exceptions in various JTA implementations (even between UserTransaction and TransactionManager of the same JTA impl), I strongly believe that those need to be clarified in a JTA spec revision. For a start, those differences should be documented somewhere - in public.

Juergen

If you rename it to EJB 5.0 maybe it will be hot again?

I am an ardent supporter of that you must be permitted to be wrong. All innovative persons sometimes stumbles on the way, it is as a rule not possible to get it right on the first try. So the war-cry should be: "It is allowed to be wrong, its part of the creative process".

But every rule must have exceptions or limits.

A mistake of the magnitude as EJB, that was hailed as "the apogee of computer science" already in its first miserable 1.0 version, and that was still defended long after hundreds of multi-million dollar project crashes, the most expensive and stupid mistakes in computer history (a catalyzer of the whole IT recession IMO), it is not possible to recover from anything like that or to take seriously anything from "well-meaning impractical theoreticians" that opens a discussion that was beaten to death over two years ago. It’s fatal.

It is allowed to be wrong only if you admit it before too much damage is done.

Regards
Rolf Tollerud

P.S.

You can ask yourself. How can anything like this happen?

It would never had happened but for Microsoft. It was a desperate need for Sun and others to be more "intellectual" and "scientific", profound thinkers of computer theory, more serious and with more money, high above the hobbyists-like Microsoft hackers that had extinguished the mainframe software industry.

In just a single master stroke, by producing some specifications, Sun and the rest of the Big Iron could get back at MS instead of starting the long and difficult task of producing a stream of successful software products.

So what was irritating to us (not MS they don't care, but us millions of MS developers), was not the product itself, but the unbelievable fake haughty manners of the proponents of said idiotic product.

Vanity makes the world go round.

Regards
Rolf Tollerud
(and now it is the desktop that is hot,hot,hot)

(and now it is the desktop that is hot,hot,hot)

Seems like MS is giving up trying to conquer the server side, where competition is fierce, and decided to go back to their niche... ;)

(and now it is the desktop that is hot,hot,hot)

Seems like MS is giving up trying to conquer the server side, where competition is fierce, and decided to go back to their niche... ;)

Not just their "niche" but also, and most importantly, their lifeblood. I think Sun and the rest of the industry are finally realizing the importance of the "desktop" (i.e. That Browser apps are not the panacea that "everyone" thinks/thought they were).

(yeah, I know you were sticking in a barb but "Humor plays close to the big hot fire of truth ...")

You may laugh Henrique, but that is what the mainframe people did too in their time. It is not the management or even the CTOs that ultimately decide, that is the end-users privilege. They are the real customers that decide which vendor/company that shall make a profit.

One sign of this new race is the new project Spring Rich Client Platform IDE for Eclipse that has attracted such attention that they practically have dropped everything else. (BTW, one thing makes me a little skeptical of this is that they are using Swing? instead of SWT, I think that was a wrong decision.)

Whatever, don't count on that once again a new evolutionary quirk will save you this time, like when the web changed all.

Regards
Rolf Tollerud

But SWT is the only thing that has forced an XP hard reset on me since a dodgey device driver early last year. It was in eclipse 3m8 though, so maybe that is excusable. But I don't think so.

Swing may die, but it hasn't killed the entire box.

Jonathan

A mistake of the magnitude as EJB, that was hailed as "the apogee of computer science" already in its first miserable 1.0 version, and that was still defended long after hundreds of multi-million dollar project crashes, the most expensive and stupid mistakes in computer history (a catalyzer of the whole IT recession IMO), it is not ...

You do not learn Rolf. You persist in your limited view that EJB is flawed technology. If it is flawed than so is Corba. There is nothing wrong about EJB except it's complexity. But if you do not understand EJB and don't know how to use it, it doesn't mean it sux. It means you suck. And than, EJB got the bad reputation because the average developer like you understood that the use of EJB in petstore is appropriate.

EJB is for big distributed systems that need distributed transactions. 'Nuf said. If you still don't get it than you should reconsider and choose some tech that fits you. Like .NET or if that's hard too, than get VB.

Spring does not perform transaction processing by itself.
It just provides a thin layer of abstraction over available transaction processing systems be it JDBC based or XA compliant DTP provided by a app server.

Myth: Petstore is a reference implementation: -1 Sorry, Hani, but Petstore was a reference implementation when it was first released. It was clearly billed as a "right" way of building J2EE apps, and the fact that it did all the things that we today see as terrible ideas is clear indication that Sun didn't quite understand yet how to use their own technology--which is no shameful admission, since it usually takes 5 years or so to "figure out" any technology (even those that are moderately complex). Just imagine all the fun the .NET world will have in the next three years or so....

So what is a good reference for learning/developing J2EE applications? Has anything been created to take its place over the last 5 years?

Use this: http://ibatis.com/jpetstore/jpetstore.html

This is a user community version, what people use.

.V

So what is a good reference for learning/developing J2EE applications? Has anything been created to take its place over the last 5 years?

Yes, the Java Adventure Builder application. I believe it also mentions that in the article.

People at JBoss, Jakarta, Spring etc are creating incredible new pieces of software and ways of developing software and all this guy contributes is some funny criticism. He's like a eunuck at a love fest. Totally useless.

+1

LOL

Most of the time the SQL DB transactions of commint and rollback will do ya.

YOU DON'T NEED TRANSACTIONs in Java.

.V

Most of the time the SQL DB transactions of commint and rollback will do ya.

YOU DON'T NEED TRANSACTIONs in Java.

You're joking, aren't you? This just can't be meant serious...

But on the other side, perhaps you just wanted to write:

Most of the time the SQL DB transactions of commint and rollback will do for me.

I DON'T NEED TRANSACTIONs in Java.

Shaking his head,
Lars

I agree, most of the time you don't need distributed transactions.

eg I guess most java boys accept that a GUI will not directly access the DB. Instead they will use soap/rmi/sockets/etc to talk to some server.
Qu: The server will then do what?
An: Start using distributed transactions!
Qu: Why not move it to the GUI?
An: Don't be stupid, it's obviously rubbish.

Hmm, now step back a bit. The transaction is starting at the GUI, its a user who is driving it, surely that is the obvious transaction boundary. And yet (nearly) everyone is writing their own transaction start, end/error sequence.

Now add in Soap and JMS. JMS supports transactions and its used sometimes. Soap? Roll your own because asynch is king. So I see a return to silo software components, who collaborate with appropriate transactional workflow, but not a language specific one - more of a business specific one. And I recon this is a return to the older comit/rollback type transaction management. Usually because the teams involved are decoupled in a similar way to the software components, and the technologies involved differ, as do the architectural solutions.

So I support the statement 'most of the time you don't need distributed transactions'. And once you accept that then EJB, SLSB and even MDB can go the way of the Dodo. Note these are app server specific things which generate revenue. I completely embrace the need for JMS, JTA, and O/R.

Jonathan

Most of the time the SQL DB transactions of commint and rollback will do ya.YOU DON'T NEED TRANSACTIONs in Java..V

I guess what you want to say, Vic, is that many people don't need distributed transactions. There is certainly a large number of applications that effectively access a single database and do not perform transactions that include other transactional resources like JMS.

This is exactly the reason why Spring's PlatformTransactionManager interface has multiple implementations: JtaTransactionManager on the one hand (delegating to a JTA implementation), and DataSourceTransactionManager, HibernateTransactionManager and JdoTransactionManager on the other hand (delegating to the local transaction facilities of the respective tool).

So if you just need transactions for a single database via JDBC, choose DataSourceTransactionManager and a local DataSource as connection pool (e.g. Commons DBCP). If you need transactions that span multiple resources, use JtaTransactionManager and transactional DataSources (typically fetched from JNDI). Note that Spring's configuration facilities allow to switch the transaction strategy and DataSource references without changing your classes.

Juergen

Vic: Most of the time the SQL DB transactions of commint and rollback will do ya. YOU DON'T NEED TRANSACTIONs in Java.

Vic, that doesn't make any sense. When you have (what you call) a "Java transactions" is just something that keeps track of what JDBC connections it has to commit or rollback. So you can not use Java transactions, and do the extra coding yourself, and the effect is identical .. does that make you feel better?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Regarding some of Ted's points:

Myth: JNDI is awkward: +1 Hani nails this one, IMHO. JNDI is an awesome API and highly underutilized; in particular, I think every J2EE developer should at least play around with the example in-memory-based JNDI SPI Provider given with the JNDI Tutorial and look at ways to use JNDI to create a layer of indirection for lookup purposes. Particularly when combined with JNDI's federation capabilities, suddenly you have ways of identifying things in an entirely agnostic manner.

Noone from the lightweight container camp claims that JNDI is awkward. We just believe that it is preferable to get dependencies injected into a component (via setters or constructors) rather than let the component look for its dependencies itself (via a service locator, what JNDI effectively is).

For example, have a DataSource setter or constructor argument on the component rather than doing a JNDI lookup for a DataSource within the component: This way, the component can be used with a DataSource of any origin (be it local or from any JNDI location) - it simply doesn't care where it comes from.

In Spring, you can use a JNDI wherever you please (via the provided JndiObjectFactoryBean), but typical application code never touches JNDI directly. This increases testability and reusability of the affected components; they can still leverage JNDI but are not tied to it anymore.

Myth: EJB must be avoided at all costs: +1 EJB is all about distributed transaction processing. If you need that, use EJB. If you don't (or if you don't know what it is), then stay away. 'Nuff said.

EJB is all about distributed components, i.e. about remoting. This is its original motivation, and this is the main reason why the server needs to be told about them via deployment descriptors: Remote EJBs are entry points into the system, just like servlets are.

Local EJBs are significantly different: They are local components that do not serve as entry points into the server. This is where a framework like Spring can provide compelling alternatives within an application, based on POJOs, without the J2EE server needing to know about those components.

One of the most sophisticated features of EJB is remote transaction propagation, i.e. the propagation of a transaction context to remote components. While this is a powerful, CORBA-inspired feature, it is rarely needed (and it hardly works in certain J2EE servers).

XA, i.e. transactions that span multiple resources, is a different matter: This is what JTA is about - implemented by the server's transaction manager -, and EJB is just a way to tap into this service. So: XA without EJB - yes; remote transaction propagation without EJB - no.

Myth: API "X" is too complex/unclear; it's easier to roll your own instead.

I agree with Ted's points here. While there is sometimes a need to roll your own solution, most inhouse-developed infrastructure software quickly becomes a pain because it never gets properly finished. However, open source frameworks are different, as they can have much more momentum than any inhouse framework.

There's a lot of good infrastructure software available, both commercially and as open source. If you as application developer feel the need to roll your own framework, ask someone or do some research - you might find that appropriate solutions are already out there. Tailor rather than reinvent.

Myth: J2EE is useless without extra frameworks: +1 There's a tendency amongst J2EE folks to want to make use of every latest framework or toolkit or aspect-oriented-whatever, and Heaven forbid you actually just sit down and use the J2EE functionality out of the box.

The problem with using J2EE functionality out of the box is that you're more or less forced to implement some stuff yourself, like configuration means, service locators, exception conversion. This is where an application framework like Spring comes into play: It offers prebuilt solutions for those common needs.

There is a point that J2EE - by its very nature - specifies system services, whose tradeoff is not geared towards ease of use. This is OK, but it leaves a gap to address for the application side of things: a single thin layer that mediates between the application's needs and the available services.

Juergen

I'm not even a fan of the ones that are out there right now, either), connection pools, object pools (which are a terrible idea except under very specific circumstances), more MVC-based web frameworks, JDBC library wrappers ("to hide away the SQLExceptions"), and any attempt to write your own Spring/Nano/Pico-like lightweight container.

I found it is better to implement some trivial design pattern at home (or to fork trivial library ) than to depend on some framework life cycle with all dependancies and probably to missuse it. Programming tool for monkeys idea is dead for me ( populism like "You do not need to learn SQL " or "Forget HTTP, we support swing style events").

I'm not even a fan of the ones that are out there right now, either), connection pools, object pools (which are a terrible idea except under very specific circumstances), more MVC-based web frameworks, JDBC library wrappers ("to hide away the SQLExceptions"), and any attempt to write your own Spring/Nano/Pico-like lightweight container.

I found it is better to implement some trivial design pattern at home (or to fork trivial library ) than to depend on some framework life cycle with all dependancies and probably to missuse it. Programming tool for monkeys idea is dead for me ( populism like "You do not need to learn SQL " or "Forget HTTP, we support swing style events").

SQL? You should be a real man and use CLI. HTTP? Straight Sockets. Java/C#/...? Assembly. :)

No, I am not vi fan :) I am talking about decision to use some framework
including EJB, it must be better reason than easy to use, it means easy to missuse sometimes.
It is not bad idea to edit some config file with vi, but I think idea to use EJB for petstore type web application is very bad. I do not think EJB is a good idea for "complex" too, but some people use it without problems ( probably they know how to use it and they are not monkeys inspired by populizm )