News: Opinion: J3EE looms ever closer
Ara Abrahamian and Jon Tirsen are talking about J3EE. In the eyes of the lightweight container guys, they see in J3EE a platform that is lightweight, extensible and testable.
- Posted by: Dion Almaer
- Posted on: January 19 2004 11:48 EST
Ara's recipe for J3EE is:
"All the pieces of the puzzle are here:
- AOP support (AOP Alliance, and other AOP frameworks like JBoss')
- IoC support, oops I mean Dependency Injection (Spring, Pico, etc)
- Attributes for declarative programming (JSR 175, QDox, XDoclet)
- Lightweight configurable enterprise services (lightweight container services provided by Spring, persistence using Hibernate/JDO, ...)
And from J2EE just take all the good stuff, such as servlets, JTA, JCA, etc, and add them to the mix. This is my recipe for J3EE!"
Read Ara Abrahamian on
J3EE on the horizon
Jon Tirsen on 'Dependency Injection' is the first step to a unified standard for lightweight containers
- hijacking the J2EE acronym? by joost de vries on January 19 2004 12:52 EST
- Model Driven + Sourcecode Centric = J4EE by Lofi Dewanto on January 19 2004 13:13 EST
- alt-ejb. by Bob Lee on January 19 2004 15:06 EST
- Do we really need it by marc fleury on January 20 2004 01:35 EST
- Do we really need it by marc fleury on January 20 2004 01:43 EST
- EJBs and microcontainer by Kristof Jozsa on January 20 2004 04:27 EST
- Do we really need it by Andrew Clifford on January 20 2004 11:00 EST
- Do we really need it by Brian Miller on January 20 2004 12:42 EST
- No Joke by Michael Boyd on January 20 2004 11:34 EST
- Do we really need it by Mike Spille on January 20 2004 18:07 EST
- Do we really need it by Gary Struthers on January 20 2004 18:44 EST
- Do we really need it by Michal Maczka on January 22 2004 04:11 EST
- Yes, J3EE is more or less a joke, but... by Jon Tirsen on January 23 2004 12:51 EST
There are several ways imo to interpret their use of the term J3EE; (1.) as a joke ("tongue in cheak"), as an ambition (2.1) to supplant J2EE proclaiming to be 'the next level'(2.2) to provide an alternative to J2EE.
As a joke there's no sense in discussing it: either it's funny or not.
So that leaves the serious intentions. 2.1 will not happen imo: a large part of the success of J2EE is that it is standardized and a lot of companies, some very big, support it. The design may not please a lot of software engineers but at least it's a widely known, strictly defined, and a bit conservatively managed- and well supported standard. Maybe this conservatism tends to irritate developers and sometimes maybe it errs on the too slow moving side but on the whole this makes it a reliable long-term platform. In this sense the term is not appropriate for the combination of AOP, Dependency Injection plus meta-data tags.
2.2 Should be very interesting but since it's an alternative you would be naming something along the line of what it is not (to wit: J2EE). I'm always in favour of naming something by what it is.
So as a whole I'd say it is a mistake to call it J3EE if you want to convey any information. Come up with a new term for this enterprise platform. (J2EE sucks anyway as an acronym. :-) )
Agility is a well-loved term. So maybe CEJ: Contortionist Enterprise Java?
I had an N-tier EJB application and received a series of requirements to scale it down for prototyping and unit testing, scale it up, and integrate it with legacy enterprise systems. Scaling down with EJB's is problematic because of dependencies on the appserver. Scaling up with EJB's is also problematic due to rules against concurrency, appservers that include replicated caches when you need distributed caches, and EJB container overhead. EAI with EJB's is problematic because customers already have woolly mammoth systems and don't want to add on a full blown EJB application.
Ara's recipe for J3EE spans desktop applications to high volume single database N-tier application clusters.
Vendors can add value to this model with non-intrusive monitoring and management, distributed transaction management, JCA, and Web Service security, workflow, and transactions.
The enterprise software industry suffers from venture capitalists who don't know how to judge a business model, corporate management that doesn't know how create a business model, and developers with their nose to the grindstone burning up funding on unneeded infrastructure. ISV's can't afford the current J2EE EJB model but they haven't figured that out yet. ISV's that get it will at least buy time to fix their business model and perhaps survive.
One very important point all of these guys forget: MDA + Open Source. The combination of "model driven" (MDA) and "sourcecode centric" (Open Source) approach will be the winner.
The generation and transformation of model PIM into model PSM into sourcecode will become the "standard development lifecycle" of all Java developers. As you try MDA (for example Open Source AndroMDA) you simply don't want to talk too much about those "high level API" (abstraction on abstraction on abstraction). It's no use because you'll never reach the perfect abstraction level you are hoping to. Simply define your metamodel, templates and you generate most of your code out of them. You are in power to choose what kind of code you want to generate. The choice is yours! If you think you have improved your system architecture, just re-generate and still you don't have to worry that it will overwrite your available implementation code, because you are using the good sourcecode centric approach as well.
The more XMI becomes a standard in some Open Source IDE (NetBeans, Eclipse), the more it will be used to generate the code.
I think "alt-ejb" or something similar would be more accurate than j3ee, as these are an alternatives to EJB as opposed to Servlets, JMS, etc.
j3ee was a running joke at JBoss as well. Bill Burke was the first one to talk about it if I remember correctly, and we were joking about trademarking it and then holding SUN hostage for the certification. We failed miserably :)
Couple of points, sorry for the long rant (insomnia in NYC)
1- Microcontainers (TM until fowler renames it 'box injection' and claims it his).
Ara and jon are on it but are skimpy on the important parts.
AOP is definitely there, and I don't just say it because JBoss is mentioned. I should say that Bill has done quite some work there, and as far as we can tell the dynamic nature of insertion through the Advisable API is only available in JBoss4. It is important for cache and persistence aspects, actually the best way to do it. Meaning when you actually try to apply this stuff you find out that dynamic insertion at run time ON INSTANCES is important. JBossCache which we just released does this fine grained replication already. Go check JBossCache out at www.jboss.org. Fine grained HTTP replication is coming your way, alien technology.
IoC support (or whatever the flavor of du jour name is) maybe, I can't really tell if it is a standalone feature, or a nice to have. I feel independence of lookup as commented elsewhere is useful but I predict its real usage in cache/session management. Something like the EJB session notion is needed.
Attributes for declarative programming DEFINITELY. C# and JSR175. <gavin king accent> But</gavin> it is a small point of carrying the metadata inside the class as opposed to other places such as application or instances. Let's not molest flies on this minor point but it is a nice to have and should have language support. JBossIDE integrates tag completion on the J2EE suite as well as AOP tag completion. Fire the IDE, code a method, comment it, righ click and you get auto-completion of available tags == available aspects.
The problem with class level configuration, as documented in research, is that it ignores logical scopes and instances (EJB already configures security for groups of objects for example). Context aware computing also demands deeper constructs, most of them thread based passed by client. Configuration of ReadAhead by clients in EJB is a good example.
I would have liked to see a discussion on the aspects THEMSELVES. Gentlemen we need that discussion. It is going on in JBoss, but deserves a wider middleware input. I read research, bill codes like crazy, bela and bwang implemented cache, gavin hibernate and these are a few aspects. I usually mention this diagram when we talk about the new aspect vision, scroll to the bottom of the page, past the marketing stuff.
These are SYSTEM aspects in JBoss, some exist already some are clear use cases but don't exist. In the research litterature I have been reading some pretty mind blowing stuff on QoS aspects and stream based semantics for example. We already integrated Georgia Tech NRMI (pass by copy restore semantics) in JB4 as client-server aspects.
Again these SYSTEM aspects are the crown jewel of middleware, without them middleware is pretty boring but has very nifty new() constructors ;)
e/ where is the microkernel gentlemen???? WHERE IS THE MICROKERNEL???
Shit, I am still a big fan of JMX. Telcos like industry strength stuff built on standards. IoC isn't it, not even close. I am not saying JMX everything, but you need to reach your system and manage it in a standard way.
f/ So our current roadmap/stack in JB4 for microcontainers (TM)
microKERNEL at bottom, services view (ioc maybe, JMX yes please)
AOP on top (dynamic insertion ala Advisable *A MUST*)
Aspects as a way to insert services in POJOS
Microcontainers as set assemblies of aspects with clear semantics (what is a session what is an entity)
YES PLEASE!!!! for all the bashing they have taken over the years. EJB's are still standing strong and tall. I still love EJB's
a/ they are a standard, standards are important for market adoption, so I am tired of seeing 1001 frameworks in their corner whose goal in life is get to EJB in 3 years.
b/ they encapsulate MOST OF THE DISCUSSION ABOVE. So when we are all done with this, we may have recreated 'light-weight' EJB. whooo hoooo! ALready JB3 allows you to add/remove aspects so you can extend the spec to do what we are discussing here (the creation of ad-hoc services). I am disapointed when I read "persistence with hibernate/JDO" as the whiz-bang insight from ara and jon... come on guys!!! EJB has security, persistence, transactions, cache, see JBoss4 for an a la carte approach to these.
c/ EJB are REALLY THE BEST KNOWN INSTANCE OF A MICROCONTAINER TODAY and they are simple to use (to some degree). Heck I was going to retire "BLUE why I love EJB's" from JBoss' front page but I realize it is more timely than ever. EJB 3.0, the standard seems to be going in the direction of generalized containers with aspect insertion. Good.
3- CALL FOR HELP.
Guys, we need to wake up. We need to accelerate. I am glad microcontainers are 'du jour' but the aspects are the key, not AOP, AOP is irrelevant to the masses POJO MIDDLEWARE is the goal, microcontainers the way.
But we must wake up on standards. 200 frameworks with partial offerings and 2 guys and their dog behind it isn't going to cut it. WE ALL NEED CRITICAL MASS.
I hope the call won't fall on deaf ears. Jon, I will hire Jon. Aslak will kill me. But hey... I can spot a pure bred when I see one :).
shit... way to lenghty... bad case of insomnia in NYC.
BTW I will be at Linux World tomorrow and wednesday. If you guys are around and want to talk about microcontainers, I should be the sleepy guy in a corner of the press room wearing a pink JBoss shirt...
I wonder how the terms EJB and microcontainers got fit in the same sentence (either upper or lowercase)..
Great post. It seems that J2EE is prefix versus J3EE's a la carte approach. While the J3EE technologies works (or will work: JSR-175) they still lack standards backing, maturity, and IDE integration to be considered main stream enterprise technologies. I think IBM, BEA, or JBoss would have to adopt them to get main-stream traction. Ara and Jon seem to present this as a branching of the technology stack when it appears to be just a branching of marketing terms.
I like the term micro-container over Fowler's dependency injection. I can visualize a micro-container.
It seems that J2EE is prefix versus J3EE's a la carte approach. While the J3EE technologies works (or will work: JSR-175) they still lack standards backing, maturity, and IDE integration to be considered main stream enterprise technologies.
The whole point of J2EE is vendor neutrality. Does J3EE also avoid vendor lock in?
The whole point of J2EE is vendor neutrality. Does J3EE also avoid vendor lock in?
Let's forget about the "J3EE" term for the moment. Lightweight containers are, after all, "conventional" frameworks: They are not full servers that you need to run on, like J2EE servers are, but rather address application architecture instead of low-level system services. Think of them like of typical persistence frameworks or web frameworks, just for general application infrastructure.
Lightweight containers *complement* J2EE servers in that they are seamlessly able to be used in J2EE web applications or even in EJB implementations - but they can as easily be used in a plain J2SE environment. Concretely, Spring is an application framework whose main target environment is J2EE. It addresses many concerns that neither J2EE nor current web frameworks address, like architecture of a lightweight logical middle tier, etc.
Spring does support J2EE in the following concrete ways:
- Spring web applications run in a J2EE web container;
- JndiObjectFactoryBean allows to link in JNDI resources, e.g. DataSources;
- JtaTransactionManager delegates to the JTA subsystem of your J2EE server;
- codeless proxies for EJB access, and EJB implementation classes.
- of course, you're able to use JMS or JCA within a Spring application
So this is by no means about *replacing* J2EE, although middle tier code written for lightweight frameworks does typically not *depend* on J2EE: You can use J2EE services when they are available, but you can also choose alternative strategies for other environments. And you do not depend on a particular J2EE server at all - you can leverage any J2EE implementation that is available.
Even if code written for IoC/AOP is as reusable as possible, the wiring up of a concrete application depends on the chosen framework. This is no different from choosing Struts or Hibernate, for example: Obviously, you'll depend on your choice to some degree. However, you can still leverage the full power of J2EE's vendor neutrality, as it is still your underlying platform. This is in sharp contrast to services that are only available in a proprietary server.
Let me clarify what I really meant with J3EE and an open source project for it.
First of all, I didn't mean at all we should start writing some sort of a spec for it. I don't beleive in specs. I think most specs have some problems in the real world because of the way they are produced, mostly spec->product, not product->spec. Fortunately I see a shift into the product->spec way of writing specs, SDO and some other specs developed by BEA and IBM for example are results of concrete real world work first.
What I had in my mind was that we could start a project and start assembling a server out of all these things. For example I would really like to see IoC-able JMS beans or IoC-able web mvc action objects, not just the pure model and service stuff IoC-ed by Spring. You see I think whenever needed we should just enhance/change specs. And AOP applicable to any object, model, service, web ui action, etc.
I was also thinking we could create a concrete server and realize all these ideas in it. So for example would be great if we could have Geronimo's mini-container in its core, Spring's bean factory stuff and all those nice services, JTA etc included in the server via some nice plug points and so on. This approach is more like Eclipse's approach: a common core codebase, with lots of plug points for different implementations. Imho this approach works better, because it deals with concrete code. We have a common codebase, instead of a 800 page spec. If something's wrong/missing in that code we just change it, and people can build on top of that core, which is now almost a spec in the form of concrete code and interfaces/classes and plug points. Spring supports different persisence mechanisms for example. These mechanisms would be implementations plugged into this generic system. And the community wround it would drive it forward directly.
And the name J3EE is not a serious name. Sun won't allow us to use that name and anyway it's a silly name! It was used to grab more attention :-)
First of all, I didn't mean at all we should start writing some sort of a spec for it. I don't beleive in specs.
I am afraid you are dismissing the importance of specs a bit too fast. You are not the only one.
Name one big software product used in production (in the the hundreds of thousands) that is not based on a spec. J2EE, Apache, also routers, telephones, transistors or light bulbs -- even Windows to a certain extent -- are backed by a spec that defines a basic contract for future evolution.
However appealing the idea of a server based on the latest bleeding edge technologies is, it will never take off if it's not based on a spec signed off by a coalition of significant players.
That being said, if the history of J2EE is any indication, the process can start with various technologies competing to solve a problem, but eventually, a spec must emerge.
Your perspective also omits a critical factor, which is very often overlooked in the Open Source community: the users.
All these technologies are cool and we love to tinker with them on a daily basis, but there is absolutely no chance of buy-in from users if you can't show them 1) that it adds value and 2) a migration path from their current technology.
On a more practical level, I have a lot of doubts on the possibility of the various framework authors out there to be able to collaborate and build one unified product, but that's just a personal opinion.
Anyway, I don't mean to discourage the effort, I would love to see something like this happen, but it's about time we stop thinking something is real just because somebody wrote it in bold in their weblog or with a writing style that makes us wonder what substance was ingested before the write-up.
Time to spit out the pill and take a hard look at the real world.
I understand that you did not intend to suggest a spec for lightweight enterprise containers. However, I seem to have a different vision of what lightweight application containers are about.
IoC-enabled web MVC actions are a reality already: You can have that with Spring's own web MVC framework (it's a central point there), Don Brown's Struts-Spring plugin, or WebWork2's new external reference mechanism (with a Spring default implementation, used for example by Confluence). You can IoC/AOP-enable *any* sort of object hosted in a Spring bean factory.
I don't see why we should need a new project for such ubiquitous IoC: What we need is good integration of current web frameworks with a Spring bean factory respectively a Spring-managed logical middle tier (and/or analogous PicoContainer/NanoContainer/Nanning services). This is already available or at least in the works for the above mentioned ones, and also for Tapestry.
Regarding JMS: There is no reason why you should not be able to host JMS beans in a Spring application context. We've considered that right from the beginning but have deferred such out-of-the-box JMS support until Spring 1.1. It's mainly about pooling of JMS sessions, to get similar conveniences as for Message-Driven Beans (maybe via Commons Messenger integration, maybe something own).
As I've already elaborated in a comment on your blog, I don't see why there is a need for creating a concrete server. All of Spring's services address typical application needs, focussing on reusable logical middle tiers and seamless overall integration of an application. This is still the application domain: Such an IoC-enabled application respectively IoC-enabled components can run in any environment, be it standalone or J2EE.
In particular, an assembled lightweight application can easily be deployed as J2EE web application or as EJB implementation behind EJB facades, leveraging all J2EE services that are available. The important benefit is that it is as easy to reuse the very same components in a standalone application (with full conveniences like declarative transactions), and in particular to test them in unit tests without the need to mock a J2EE container.
So all things considered, I believe that rich lightweight application containers *complement* J2EE rather than compete with it. Granted, they offer the means for implementing logical middle tiers as POJOs, with a lot of conveniences similar to local SLSBs: This allows to avoid the use of EJB for purely local purposes, while keeping the conveniences and making deployment much easier. But in all other respects, they do not replace J2EE by any means.
I tend to view Spring as an equivalent of Hibernate in the application framework domain: Like Hibernate, it is able to run in any environment, and to leverage J2EE services when they are there but to not depend on them. Hibernate offers a lightweight alternative to Entity Beans, while Spring offers a lightweight alternative to local Stateless Session Beans as one of its core services: That's why Spring and Hibernate complement each other so nicely, IMO.
I agree with you, Marc. Go Marc! Go! On the topic of frameworks coming up with alternatives to EJBs. I am perplexed as to why developers should ignore the power of EJBs when they offer fine grained security and such. The security features alone are a compelling reason to use them. I use JBoss 3.X as my server and love it!! I am excited about JBoss AOP and see AOP as a major step in the evolution of J2EE programming.
Yes, Marc, AOP and the middle ware aspects, they're very important, to both you, your company, and the open source you're shepherding.
Let's see, leaving out changes that are "Switched to JGroups" (e.g. a change in an import statement), let's see how much work has been done within the JBoss code for aspects (in jboss-aspects). Let's go to the 'forge:
- aop/logging - last updated 6 months ago
- aop/remoting - last updated 6 months ago
- aop/security - last updated 6 months ago
- aop/tx - last updated 4 months ago (woo-who!)
- aop/txlock - last updated 6 months ago
- aop/versioned - last updated 6 months ago
Oh, and no new all-important aspects at all. Yes indeed, middle-ware aspects are so important that no work has been done on them since the summer of 2003.
Maybe your team has been busy working on the core AOP engine, eh? Let's see,
- jboss-aop: Yes!! 3 files have been changed by stark, all 3 days ago. The other 65 .java source files haven't been changed, but three have.
So Stark has changed 3 files, and that's the bulk of JBoss' contribution to AOP and aspects in the past 4-6 months.
Strangely enough, for your bullet points 1 A-F, and 2 A-C, no real code has been checked into CVS at all.
And these are the mind shatteringly IMPORTANT things that the industry MUST address? I guess maybe you HAVEN'T MET CRITICAL MASS - or perhaps you haven't the slightest idea what your programmers are actually coding?
In all seriousness, Marc - if all this stuff is so important, why aren't any of your guys coding any of it?
It's a good sign JBoss 4 has been quiet since DR2. That was a proof of concept but, as Mike has pointed out in the long history of this feud, not a production ready implementation. I hope they are re-thinking how to get to production ready Jboss-AOP and will come around to adopting a gay Dependency Injector (whoo hoo!) with Hibernate / AOP Alliance aspects. Also JBoss 4 seems to be too much excitement for Marc's customers to buy into for now.
Well, if they've been quiet since DR2 because they've been working out grand designs, learning lessons from the DR2 release, rethinking architecture, and seriously consider the best approach to achieve 4.0 final - well, then bravo.
But does anyone seriously think that's what they've been doing all that time? Is there some secret JBoss lab where all the code and design documents and discussions are kept? And they're going to spring it on us a giant CVS dump?
Somehow, I don't think so. All that's happened since DR2 is people running training sessions, JBoss Group begging for money to run the J2EE tests, and Marc posting his grand visions to TSS every once in awhile. What activity there's been has been in the 3.x branch - yet another indicator as to the importance given to 4.0 (e.g. slim to none).
f/ So our current roadmap/stack in JB4 for microcontainers (TM)
> microKERNEL at bottom, services view (ioc maybe, JMX yes please)
> AOP on top (dynamic insertion ala Advisable *A MUST*)
> Aspects as a way to insert services in POJOS
> Microcontainers as set assemblies of aspects with clear semantics (what is a session what is an entity)
Not sure if I understand you. Manageability is yet another aspect of any services and you have have a dozen ways of managing service as you can have a dozen way of "persisting" objects. So why you don't see it as yet another aspect which can be exchanged with something better?
JMX is not ready to use solution. You still need to implement a layer which will use JMX and map it to user friendly GUI. And this needs to be done pratically for every "Managed Bean".
JMX is not addressing at all the "life cycle" of the component and this is what microkernels are all about.
Most of J2EE is actually quite nice. I don't mind things like Servlets, JDBC, JTA, JMS, JMX, etc. It's also nice to have a spec you can rely on, you can actually write really portable applications with it (if you avoid using EJB). But if you are saying that having a spec means that it should not evolve then you are the moron. I believe much of the stuff going on at the moment (AOP, IoC, attributes, lightweight containers) is most certainly going to become the future of J2EE.
I'm working on the .NET platform on my current project and I must say that Microsoft really do get it (in some respects, VS.NET is still absurdly crappy). Creating a pooled object with transaction support is literally about 5 lines of code, *and* you can run it directly in your unit tests, no container. Attributes, some AOP (interceptors), lightweight container. What can I say? If Sun/IBM/BEA don't get it soon they will start loosing to Big Red.