Spring vs. ATG Nucleus

[joeberkovitz]

This is an interesting discussion for me, because I was an architect at ATG back when DAS and Nucleus were invented; now I'm working at Allurent and using Spring DI quite happily as a useful tool which offers much of what Nucleus had to offer, at the much more appropriate price (for basic programming infrastructure) of zero. I would not want to develop any large-scale server application without either Nucleus or Spring.

I didn't write Nucleus -- I contributed the odd enhancement or bug fix to it -- but I'm very familiar with the thinking that took place around its creation and afterwards. The comments in this thread are eerily similar to the many internal debates we had about Nucleus' separability from the rest of the platform and the wisdom of releasing part (or even all) of DAS as open source.

I think it's fair to say that Nucleus and Spring share a core of common goals. Nucleus was designed consciously as a dependency-injection framework, although that particular piece of jargon did not exist at the time -- we referred to Nucleus as a "lightweight component system". This was not a sideways jibe at EJBs, which didn't exist yet either. For that matter, neither did J2EE. Servlets themselves were barely in existence. The "ATG vs J2EE" issues that hounded the platform came into being later as a direct consequence of ATG being on the scene so early, and developing a strategy for standards coexistence so late.

Each system has its unique strengths that I appreciate. Nucleus' configuration layers and runtime inspection/modification tools are very powerful -- the runtime admin in particular, which is comparable to a JMX UI for lightweight components. On the other hand Spring (at least, the DI part of it) has a simpler and cleaner API, AOP, more general hooks to bean initialization code, and has the capability to define arbitrary scopes (though it will be nice to have shrink-wrapped request and session scopes). I note that someone, if so inclined, could add configuration layers to Spring merely by performing some XML preprocessing (which is sort of how they were added to Nucleus itself, which did not originally support them).

It's always interesting to speculate on what might have happened, but we'll never have the luxury of knowing. ATG did not make Nucleus available to developers at large, partly because management believed it to be part of a proprietary advantage to the Dynamo platform -- and indeed, Dynamo exploits the lightweight component concept in a comprehensive way that still requires a fair bit of work to achieve in J2EE using multiple open source packages. But tven if they had opened it up, there would have been room for Spring, HiveMind, and so on to improve on the earlier ideas, and 10 years is a long lifetime for a first cut at an idea to survive. It is interesting that Spring developers appear not to have known much about Nucleus, and yet they developed something strikingly similar in approach. To me that is a validation of the aims of Nucleus, if not its actual substance.

Anyway, I think Nucleus and Spring DI are both good and useful things. In the current ecology of the server-side Java world, if you're a developer looking for DI and lightweight components, Spring is currently the best thing out there. Dynamo costs much more, but is the right fit for a project that can exploit the broader scope of what's found in ATG beyond Nucleus, repositories and DAS.

... . . . joe

[analogueboy]

For the record, I used to work at the same company as Stu E. (and Rod at one point I believe?), I can't add much beyond what they already have.

ATG had some great ideas and where often ahead of their time. Unfortunately, their implementation never matched their innovation and we often had to have patches sent to all developers (more than I've seen with any other vendor).

They had the repository API in production long before projects like castor and hibernate. Their DI container came with an excellent GUI which made it very easy to configure applications, even at runtime, but as Rod pointed out, it had no concept of interception.

The problem with Nucleus is that it was engrained into their app server and when they tried to separate it to allow their products to run on alternative servers, it was almost like an app server *in* an app server. It really imposed itself on a project, unlike Spring, which I almost forget I'm using sometimes.

They had a brillant GUI tho, you could create folders for components, similar to java packages, and you could add a component (think Spring bean) at runtime and browse the tree to link objects which would create the configuration files automatically instead of having to hand-code XML files.

As their developer mentioned, it went beyond Spring's capability of over-riding beans using multiple definition files which allowed properties of the bean to be merged. It would be good to be able to do that with spring, adding more references to lists for example. However, their concept of levels could get very complicated and frustrating when trying to debug problems with runtime configuration and it made it very easy to mess up the packaging of an application because all the files are named the same.

In short, Nucleus was a great idea, and it's configuration tool is still vastly superior than anything else I've seen for any other DI container. However, if I was starting on a green-field site tomorrow, I would never even suggest using it. Spring has manged to do much more with much less and allows you to get going much quicker. Spring's documentation is also much better, ATG's documentation often seems to be directed at managers with chequebookes rather than developers looking for a quick-start with an API.

[james.estes]

I ran into nucleus a few months back (march) and posted about it on the dev-list (no replies...guess I should have posted here). I was shocked when I saw how long it had been around...certainly well before its time. I liked some things about it, particularly the way the beans and properties are defined in a kind of cascading heirarchy. I'm pretty sure one could write a spring bean definition reader that would be able to build a spring bean factory from a nucleus folder.
I didn't go that far, but I did put together some code to allow the 2 containers to see and reference beans from one another. Could be useful in a system that is trying to migrate away from atg. Rather than past the code here, you can read about it here: http://www.itsalleasy.com/2005/03/07...g-and-nucleus/.

[justzzzz]

Have been using DAS/Nucleus extensively for the past few years. With respect to the original post, I don't think it's accurate to say that Spring is an inferior framework to Nucleus, but there are a few things that Spring could learn from looking at Nucleus. It sounds like Rod's working on the request/session scoping issues (very curious to see this code, btw), but this leaves two farily important features left to be implemented: hierarchial contexts and layered/global configuration.

In Spring, hierarchial contexts are currently defined as BeanFactory A can be a parent to BeanFactory B. What Nucleus means by hierarchial contexts is that beans/components are placed into a path-like structure that corresponds to a filesystem. As the quote in the original post explains, this is fairly critical (at least to someone used to it) for large-scale projects. I've never understood how Spring can scale past a few dozen components with it's flat namespace. Even if you cut up your applicationContext.xml files, you still have the potential for conflicts. Some of the Nucleus-based sites I'm involved in have several thousand components, which seems entirely unmanageable with Spring.

With Nucleus's layered/global configuration features, one is able to define a base set of component properties and then override those properties in a separate set of files. Similar to the path-like contexts, once you've used this, it seems impossible to live without, especially if you support multiple sites off the same codebase or run with different configs in development and production (who doesn't?).

I have code to implement these two features in Spring, but am not really clear on where to take this next. I do believe that Spring has a lot of potential to replace the ATG stack, especially in situations where little of the higher-level pieces (DPS, DCS, Repositories) are utilizied.

[katentim]

I have code to implement these two features in Spring, but am not really clear on where to take this next.

You can raise the issue on the dev list and post contribution to JIRA.

http://www.springframework.org/development

[salmon]

Just to add my 2 cents.

About 4 years ago, I was working on an ATG Dynamo project. I don't remember much of this application server, but what I do remember is Nucleus. Later, I've worked with weblogic and resin, but I've always missed Nucleus.

Now, I'm converting an application from Avalon/Excalibur to spring, and handling the configuration files is becoming a PITA. Currently we have about 500 beans that is spread across about 20 files, and more beans are added every day. Even in this state, it is still way better than Avalon, but it doesn't scale as well as Nucleus.

Now reading that justzzzz has code to implement hierarchial contexts in Spring, I really hope this can be added to a spring release soon. I can't speak for others, but at least I would be very grateful for this addition.

Regards,
the happy salmon.

[kay]

I've been working with ATG for the last couple of months. I'm not *that* familiar with Nucleus, seems to me as a newcomer as the same concepts of DI, just the implementation is quite dated. I much prefer the way Spring does things as opposed to DAS, which scatters property files all over the show. Some people that intimately know DAS are very fond of it, but ATG missed the boat with J2EE.

We're now using Spring inside DAS and moving away from ATG's proprietary frameworks. Interestingly, DAS 7.1 ships with Spring AOP - they must be using it internally. (Even more amusing is the fact that they DON'T ship Spring Core, on which AOP depends, so if you're using Spring with an out-of-the-box DAS, things tend break...)

I don't think anyone has mentioned it yet, but ATG DAS has been discontinued. The rest of their stuff will be available as components on top of other app servers, but DAS is coming to an end. We're planning a switch to an alternative J2EE server early next year. We will still be running ATG Dynamo on top of whatever platform we choose to migrate to.

[3dx]

I have been using ATG Dynamo for several years. I liked the concept of the Nucleus very much even now, but once it comes to the miagration, it is all about $$$. When I found Spring, I loved it right away. Yes, ATG Dynamo can do more in some area, but Spring also have many features that ATG Dynamo doesn't have.

The biggest differnce? Srping is open source and free to use. ATG will cost you too much $$$.

Thank you Spring.

[laenzlinger]

Have you evere ran Spring on DAS? It is theoretically possilble?

We are running Spring applications on top of ATG DAS (due to operational reasons).

- We had some issues with redirect (ATG's implementation is not complient with the servlet specification - their own extension of course is).

- We had some issues loading resources from the web application class path (which we solved by using the ATG (server) classpath).

We were developing applications on top of ATG for several years. Of course they had a very nice IoC container already a long time ago. In fact they poineered a lot....

A GUI for the container is nice, but who really needs it....
A hierarchical namespace is nice, but one can easily come up with some nameing conventions....
Overloadable configuration layers are nice, but maybe in reality a little over-engineered...

But a non intrusive container that allows Test Driven Development is not only nice to have. And the AOP features (manly the declarative transaction mangangen) are keeping the business logic clean and maintainable.

Thanks to all the people that helped to invent such a great Spring framework!

[-FoX-]

What were the main issues you encountered?

It would be nice, though, if you could post your migration 'tips' or something like that. We are currently working on ATG/DAS, and maybe.. somewhere in the future.. we will migrate our projects to use Spring. Main reason would be to be appserver independent.

What were the main reasons that you migrated to Spring?