Comments for Jon's Radio

comment

I agree with some of what you say. However, I also think most of the whole issue is caused by a number of factors not necessarily directly related. On one level, you have the whole Objects+Databases+Transaction thingie, which doesn't always quite mix, and adds some significant complexity to the issue. Sure, you can get around this by using appropriate patterns (such as Unit-of-work), but you still need to fully understand how transactions impact your whole architecture (knowing when to finally commit data, managing caches, coherency, etc.). Add to this the fact that transactions + distributed caching of data is just plain hard.

WS-Transaction seems hopeful, but it sort of highlights something that's starting to really shape up: With the whole webservices world, and large service distribution across trust boundaries, database-style ACID transactions just don't cut it anymore. We really need to start focusing on compensation-based transaction styles on top of asynchronous messaging. And you know what? Designing such a system is hard, specially for most people used to the safe world of closely guarded synchronous RPC style interactions.

Tomas Restrepo • 5/12/03; 5:29:01 PM

comment

Even just focussing on one aspect of J2EE, Enterprise Java Beans, shows that they are oversold in the same way. If you need your objects to be tranparently composed of classes and data spread among arbitrary machines across a corporate network, than yeah, EJBs are an appropriate design choice, but let's face it, most applications are a *little* more centralized than that, and regular Beans, Java Server Pages and Servlets work just fine (assuming you still want to use Java, which I don't, Python being my tool of choice).

Michael Bernstein • 5/12/03; 7:40:59 PM

comment

Jon, I found Rod Johnson's book "Expert one-to-one: J2EE Design and Development" to be full of useful information on this topic. It was the first book that I felt addressed development issues head-on, and which didn't just recommend using a specs features like EJB entity beans "just because". He ends up concluding that in many cases, you are better off using lightweight JavaBeans (configured from XML metadata) whose persistence is managed by extending a framework base class or implemented via some other O/R mapping technique, for best perf and most flexibility.

I ended up quoting from his book (with his permission) in a recent whitepaper I wrote about building a web storefront using existing J2EE controller-layer frameworks like Struts and application frameworks like Oracle Business Components for Java (which is what over 800 of our own internal J2EE web app developers use, among other customers). The link is http://otn.oracle.com/sample_code/products/jdev/bc4jtoystore/readme.html in case you're curious to check out the demo and the whitepaper's technical explanation of it.

Steve Muench • 5/13/03; 3:05:59 AM

comment

I hope you talk to Bruce Eckel...

Bill Seitz • 5/13/03; 4:12:24 AM

comment

re Scalability - I hope you get pretty specific, because I find that people often think of themselves needing high scalability when they're really small fish in that regard. Log-envy, or something...

Bill Seitz • 5/13/03; 4:16:18 AM

comment

When people say this, what I usually hear is "we don't need EJBs," which is often correct. But if you are writing code that should really be transactional, that utilizes multiple datasources, that makes use of messaging APIs, and that will deploy some JSPs, the better J2EE containers will save you a lot of code. Even if you only need a few of these things.

More than anything, the OR mapping abilities of EJBs have caused them to be terribly oversold.

Tools amplify one's talent. If you know the appropriate applications of J2EE technology, writing with a good container can make life much easier.

Eric Hancock • 5/13/03; 5:44:05 AM

comment

I think it was Tim O'Reilly who coined the term "Enterprise Black Hole". It is such a strong resource sink that it's difficult to see the value beyond the event horizon.

With all the services provided by these containers, how much of the complexity/appropriate-use problem can be solved with tools?

How much has J2EE been shaped by current database technology and how might that change with native object/xml storage or in-memory technology like Prevayler?

It's too hard for some developers to *flow* in J2EE.

Dan • 5/13/03; 9:45:00 AM

comment

As an industrty we tend to jump on bandwagons - probably driven by our marketing and sales efforts. I can remember a similar binge around client-server and I am sure Annrai remembers a similar religous fervour around CORBA ;-). As technology leaders we have the task of sorting through the marketing hyperbole and picking out the useful concepts and tools.

When new technologies and approaches come to market they should be viewed as additions to our toolset rather than automatic replacements. They may replace some existing tools but they typically agument the existing set we use to solve problems.

The benefits of J2EE (and I would consider there being two containers in the J2EE world, Servlets and EJB's) is that it is a well defined architecture. Without J2EE we would all be making this up as we go along and have minimal consistency between applications. On the developer side we would have minmal common competancies and guidelines for building applications. Every design would start from a blank sheet of paper rather than a wel defined framework.

Because J2EE is a well defined public specification there are multiple offerings in all areas, (training, platforms, books, developer community). The range of offerings ensures a vibrant developer community with a deep knowledge of the tools and platforms.

Whether the solution uses servlets or EJB's is an architecture decision, if the architecture team is swayed by marketing hyperbole it may be time to ask a few hard questions. To often I have heard xxx technology is the answer, without anyone understanding the question.

The real issue is being able to pick the right tool of the right task. This requires a rich set of tools at our disposal - and J2EE is just one of these.

John McDowall • 5/13/03; 9:53:13 AM

comment

Jon, I'd like to counter some of your arguments. Your app has to scale -- while there are other technologies out there -- J2EE is the one who has built in support for clustering in a standardized fashion. If stick to servlet sessions and EJBs, I get that without a lot of extra work. Yes, I can do this in another language, but it's often done ad-hoc.

Your app is heavily transactional -- Yes there are other transaction systems out there. And JTS & JMS gives you standard APIs to talking to these systems regardless of what's behing them.

You need object-relational persistence -- I think comparing EJBs deployment without tools to other technologies is a bit like comparing XML to CSV and saying that XML should be avoided because XML is to hard to generate manually. EJBs manually are probably too hard, but with a good tool (whether that's IDE or Xdoclets) are not really any different than a normal bean. And the container will take care of the persistence and storage and clustering for me. Are the containers perfect? No, but I bet that the latest versions can do a better job than me in the long run & are good enough for the short run.

You need a low-impact way to evolve business logic -- Again I believe that given any technology you can make an inflexible solution. Perhaps J2EE is a bit hard at times to figure out the best way to do a particular task, but I view that's getting better. But it's lost in the current hype that's the .NET buzz and the .COM crash. Also I think by doing some simple meta-data development now (XDoclets and coming officially in 1.5) EJBs are not that much more inflexible than any other system.

You need your business logic available to multiple applications -- Most of the latest releases of J2EE servers are auto-enabling EJBs as Web Services.

You want to standardize on one environment and one language -- Jon, the uber geeks like us enjoy multiple languages. Most development staff are lucky if they can learn one language with any depth. Yes, I may have to learn some SQL and occasionally something to glue (I really don't think Jython has fully been exploited for this yet) but I'm amazed how much I can get done in Java now. No, it's not necessarily as much fun as Perl, but that has more to do with the personalities in Perl than the language, I believe. Yes, Java has some ugliness that all strong typed languages do, but in most cases I can have Eclipse which makes this a lot less painless.

In the end, I think what's the real shame is that CORBA had to disappear (for the most part), because it solved so many of these problems (in a cross-platform/language neutral way). But that being said, J2EE has a lot more benefits (good tools, several experts to draw upon, vibrant community, many available APIs for a variety of systems, good mix of open/proprietary options) IMHO than any other system.

Mark

Mark Wilcox • 5/13/03; 2:08:13 PM

comment

Personally I like working fast, and the customers typically seem to need this. I also like working to a clean framework so I don't make too many errors design or code wise - ie I like my decision space to be circumscribed by smart framework designers. I don't like embedding SQL in my code. I don't need interprocess communication all that often. So I go to WebObjects and EOModeler almost every time and I still don't understand why Apple don't rule the enterprise space for these and other reasons. J2EE is just too much and JSP/servlets are also slightly clunky by comparison. I guess it comes down to ... design elegance.

Neil Finlayson • 5/15/03; 1:36:32 PM