Is Jtwoee An Anti Pattern

Or "Is J2EE an AntiPattern" (Refactored from AntiPattern)

J2EE is an AntiPattern. Why? Because the standard way of developing applications in J2EE (using EntityBeans) is so slow that the advanced books on J2EE give Patterns not to use it.

No, J2EE is NOT an AntiPattern. Yes, overuse of Entity Beans is an AntiPattern, especially in EJB 1.1. However, using Session Beans (especially Session Facades) is a very good pattern for many circumstances.

Don't conflate J2EE with EJB. EJB is only one of about twelve technologies that make up the J2EE platform and, IMHO, it is the least useful of the twelve. The other technologies that make up the platform, e.g., J2SE, JDBC, JSP, Servlets, JMS, JTA, JavaMail, etc., combine to form a useful and rich enterprise application development platform. If it weren't for the JTA/JTS hooks that come with EJB (and the remote invocation hooks, if you need them), I would have no use for EJB whatsoever. I certainly have no use for entity beans but, because of EJB's JTS hooks, I think EJB 2.0 Stateless Session Beans with local interfaces provide enough redeeming value to use them in an enterprise application's architecture. -- RandyStafford

EJB has been touted by Sun as "core technology" of J2EE, whatever that means. In the group where I work, they decided to pounce on EJB first in order to grab the J2EE bull by the horns. This, I think, was a mistake. Servlet/JSP and JDBC would make much better starting points for converting the typical RDBMS repository-style application into Java, particularly since the state model for EJB sessions is likely going to end up embedded in a larger state model of HTTP session. This leads to a general gripe I have with the J2EE development process, which attempts to start with inner system components and work its way outward. If you want to surprise and disappoint your customer, that's definitely the approach to use. -- WaldenMathews

What the heck is a "J2EE development process"? I NEVER work fully bottom-up like that. I generally tend to work top-down from the Servlet in my designs, although I may do some coding that sort of "meets in the middle" (top-down for Servlets, bottom-up for EJB components...) -- KyleBrown

What the heck is it? Well, if you read Sun's spec you'll find some fairy tales about component writers, application assemblers, application deployers, J2ee server administrators (you should know, IBM even offers certifications) and other roles. It surely smells like development process, and it surely smells like fabrications with no relation whatsoever with reality. If you are willing to demonstrate the usefulness of separating the theoretical component writer from the target deployment environment you might take the challenge in EjbTernaryRelationshipExample. -- CostinCozianu

I'm relieved to see that no one takes that development role stuff too seriously. Yes, that was what I was referring to. -- WaldenMathews

I don't really believe in the EjbArchitectureRoles either. -- RandyStafford

As I wrote in Chapter 7 of FloydMarinescu's EjbDesignPatternsBook, you have to do "domain-out" development to a large degree, because of compilation dependencies (session beans depend on domain objects, etc.) and other existence dependencies. I don't see anything wrong with that development order; it has been working for me for many projects now - and the forces that drive you to that development order transcend technology choices. As for session bean lifecycles getting embedded in HttpSession lifecycles, I use a Broker to broker references to stateless session beans, and I do not store them in HttpSession state (clients return the SLSBs to the Broker as soon as they are done with the invocations necessary for the current response). -- RandyStafford

I wrote a conference room scheduler application to cut my teeth on J2EE, beginning with the EJB component. To keep coupling to a minimum, I did the interface entirely in generic String types and array lists. Later, when developing the servlet (also my first) that interface all had to be changed. (Didn't have to be, but I was looking for something reasonable smelling.) Had I started with the client side (as instinct would direct me), an iteration would have been saved.

Your description of Brokering stateless sessions sounds odd to me. Stateless session beans are anonymous and automatically pooled by the EJB container, aren't they? My goodness, if good design with EJB means adding more custom brokering stuff, then I give up. I will add that I could not rely on the Sybase ConnectionPoolDataSource? to monitor connection state, and had to put my own little state machine into private EJB methods for database connection. Ugh. Later testing with the JBoss connection stack worked better, so this is not a J2EE criticism per se.

Also, the idea that you wrap enterprise beans in regular JavaBeans in order to sweeten the JSP doesn't lie well with me. If you should be able to call a regular null constructor on an EJB, then that should have been in their design, shouldn't it?

-- WaldenMathews

Yes, stateless session beans are anonymous in the sense that clients shouldn't expect to be served by the same instance from invocation to invocation. However server-side pooling of skeletons is an optional container-provided optimization. In the early days of EJB not all containers provided server-side pooling, so a client-side broker was useful to avoid the overhead of creating a new SLSB on every invocation. Even with server-side pooling the broker pattern is beneficial because it provides ProtectedVariation? w.r.t. accessing services. For example it hides container specific JNDI details and other context-specific details. The motivation for inserting an additional layer of objects between JSPs and EJBs is not just to "wrap" the EJBs - it has more to do with allocation of responsibility over layers of architecture. The role of the SLSB-based services is to define an ApplicationBoundary that coordinates the system's transactional response to external stimuli. The role of the intermediate (usebean/servlet) layer is to adapt the domain to the presentation, and mediate the user's navigation through UI contexts / use cases. There is a bit of elaboration on this in Chapter 7 of the EjbDesignPatternsBook, and there will be more in MartinFowler's PatternsOfEnterpriseApplicationArchitecture.

In general, the problem with a lot of the stuff (specs, libs, examples) that comes from JavaSoft is that the people who author it don't build systems for a living every day, and therefore don't have a very good idea of how much pain they are inflicting on us poor bastards out in the industry. -- RandyStafford

Maybe the problem is that SunIsIrrelevant?. Most of the interesting Java and J2EE related technologies nowadays are coming from the thousands of organizations and developers out there in the Java marketplace of ideas. Unfortunately the standards process seems intent on churning out new specifications and chasing bandwagons rather than fixing problems (like EntityBeans) or codifying established best practice (like code generation).

There are some books coming from Sun's laboratories, containing a collection of anti-patterns, but bearing "J2EE patterns"/"blueprints" in their name. The practical demonstration of these things together is generally known under the name of PetStore, which among les connaisseurs is (dis)regarded as a model of how not to write web applications. In general many folks in the J2EE camps promote quite a bit of ignorance with regards to sound software engineering in general and in particular with regards to modeling issues. I can quote here a few books on EJBs which promote flawed schemas (both at the database level and object level) as "the good way" to model the world in Entity Beans. As a matter of fact some mistakes are inspired straight from CrossingTheChasm paper where KyleBrown advocated using surrogates as replacement for the OIDs, but that's not the only common mistake in Entity Bean "modeling". Other common mistakes promoted by J2EE technologies/best practices include modeling the "directionality" of relations (at best a waste of time), thinking that the only possible relations are binary, coming up with the dreaded EjbQueryLanguage.

If we let EJBs aside , we find Servlets and JSPs which are in fact another collection of anti-patterns. Servlets were promoted back in 1998 as a replacement to CGI, when they are the perfect equivalent of CGI, and at that time a lot better technologies existed but were swept under the carpet by the aggressive marketing from Sun. JSPs, were just the ASPs reinvented under Java and are quite a bad idea. So now, many developers are stuck with developing Servlets/JSPs which is a terrible idea. Luckily Microsoft took over existing models and came up with real component oriented development in .NET, which is by now an order of magnitude more productive for development. With regards to the other technologies, luckily those are pretty decent and are not a feature of J2EE, but luckily adaptations of old ideas (JMS, JTS, JDBC), so at least part of J2EE doesn't suffer from NotInventedHere.

Therefore J2EE itself is probably not an AntiPattern. It is too bulky, too (unnecessarily) complex to be an AntiPattern. It certainly has a good collection of AntiPatterns among its many technologies. But what is worse, the J2EE mindset and the J2EE culture do promote quite a bit of ignorance and quite a few AntiPatterns as Walden observed, I observed and many other observed. These AntiPatterns come with the stamp of approval from Sun et comp, so in practice it's quite difficult to argue against this flood of ignorance. A sad state of affairs from my viewpoint. -- CostinCozianu

So, does that make it an AntiPatternLanguage?

There's so much to disagree with on this page. I'll try to be methodical.

People blame Sun for advocating misguided architectures in their marketing campaigns. I would argue that people should be reading and thinking before coming up with their own architectures rather than blindly following BluePrints?. The classic example is EJB. In some situations they work quite well but that doesn't mean that they should always be used. People should start out with the simplest possible architecture based on the fewest technologies then add more acronyms to the soup only when they are clearly needed.
J2EE is not a development process and it doesn't recommend that we start with inner system components and work our way outwards. J2EE is just a bunch of technologies, APIs, compliance tests and marketing campaigns.
The J2EE spec does go off the rails when it describes that weird Get it ThrownOverTheWall waterfall development process. I always tell people in my classes to treat it like a LogicalModel? that makes it easier to think about what's going on but isn't actually true. A few seconds thought ought to be enough for anyone to realize that it won't work in real life. Unfortunately I have heard of organizations who treated it like gospel truth and they now know better.
People aren't wrapping stateless session beans so much as encapsulating their invocation. This gives you certain advantages like hiding JNDI names and enabling the cacheing of JNDI stubs. And you should only need to write the encapsulating code once. Afterwards all your code just re-uses the appropriate class/framework. Assuming of course that the development team has built and is using a framework/library of reusable code. There's also the additional benefit of drawing a clear boundary which means that developers can write code that's dependent upon EJBs without being coupled with them. Thus giving you the ability to switch to and from an EJB architecture or test without having to have finished an EJB architecture.
As for PetStore, it's indefensible. I tell people to treat it like HelloWorld. Something which might be educational but shouldn't necessarily be emulated.
With regards to "many folks in the J2EE camps promote quite a bit of ignorance with regards to sound software engineering in general and in particular with regards to modeling issues." I agree but would argue that's more a reflection on the state of the industry in general.

And now for some questions. Costin, what alternatives to CGI were out there that were swept away? I'd love to play with them. Funnily enough I do agree with Costin about the J2EE spec promulgating anti-patterns when it comes to databases and persistent stores. -- AdewaleOshineye

NetDynamics is a fine example, Microsoft copied it perfectly in VS.NET. In my current project, I'm rewriting a "kind-of" NetDynamics from scratch, as I go along, because it's way more productive (and probable a lot more productive in the future) than to use J2EE technologies. AtgDynamo. WebObjects. Probably even ColdFusion was better at that time (I don't know now). Unfortunately the J2EE contains much more AntiPatterns than simply EntityBeans. For example they have yet at this point in time, to provide an Application object for a WebApplication, to allow you to divide a system and interoperate across Web Applications, you can't currently in most servers cause the sessions won't work, and the classloaders will throw you out. You don't have a global session either. NetDynamics figured that out back in 96. JDBC is actually a bad standard when you want to write a generic framework, you end up writing adaptation layers for Oracle or any other specific database - wasn't this supposed to be solved by the JDBC itself? And so on, so forth, I'm seek and tired of those bastards who impose standards upon us, without having to suffer the pain of actually working with them to deliver actual software systems instead of junk demos.

What is the worst of them all is that they didn't get it: it's the development time, stupid. I couldn't care less if they want to invent the mother of them all object models, resuscitate the defunct ODMG OQL, lay 7 layers upon 7 layers of abstraction. I count only line of codes, and when I see that the most junior programmer can be at least 2 times as productive as me if he clicks his way through VS.NET, I'm getting ready to jump the boat. Actually, I'm currently trying to fix little things by myself, but probably it's not worth the effort. -- CostinCozianu

I'll second the NetDynamics comment, at the time I was working with those guys developing a Domino bridge component Sun bought them out and canned the technology in favor of SunOne. Since then I've worked with J2EE and VS.NET. Honestly, VS.NET isn't all that either. For simple things it's great, but if you need to do much client side stuff (javascript) it gets real ugly since you now need to know what .NET is doing under the covers and when. My favorite environment so far has been using controller servlets and generating the UI with a templating engine, ala Turbine -- DR