Announcement Announcement Module
No announcement yet.
Spring vs. ATG Nucleus Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring vs. ATG Nucleus

    Does anyone have experience with ATG's Nucleus? Specifically, what do you have to say about this argument from someone involved in the development of Nucleus? Do this person's allegations have any merit? Discussion of Nucleus aside, are they even fairly representing Spring's capabilities and drawbacks?

    Spring is an inferior framework to Nucleus. I have had a look at it and there is very little in there that Nucleus doesn’t do and lots that Nucleus does that Spring doesn’t. Nucleus does a much better job of component lifecycle management. Spring has only 2 scopes, Global and “do it yourself”. Spring has some nice hooks for persistence but Repositories are infinitely better, and Spring’s transactional hooks are similar to Nucleus’.

    I have found a couple of features that Spring does better than Nucleus:

    1. The ability to define the use of alternate, non-default constructors.

    2. The ability to define factory classes to create beans

    3. The ability to define methods to be called prior to destroying the component.

    4. The ability to define initialization methods to be called after all properties have been set

    Nucleus additionally has the layered configuration mechanism and XML file merging. Spring does not support this at all. The XML file system application context does support using multiple XML configuration files, but definitions in later files simply override settings in earlier files, there is no merging.

    Nucleus also supports a hierarchical namespace that maps to the locations of configuration files on the disk. Spring has no notion that is close to this. Components are given an id that must be unique. This could quickly lead to name conflicts if applications are combined together, or if you are working on a large project. I can see that for small projects this wouldn’t be an issue.

    Nucleus supports “global” configuration for settings using the file that apply to all components. This is useful for turning on log levels uniformly, or configuring all components to use the same logListeners. As Nucleus has configuration merging this is easy to do, Spring provides no facility for this.

    The Spring MVC framework is very similar to the MVC framework supported by Nucleus.

    Overall, Spring seems good for small implementations, but as the application size grows and more components are added Spring will become unwieldy and hard to maintain. Nucleus is much more enterprise friendly.

  • #2
    I have never heard of it And maybe ATG can do some things better than Spring, but Spring is well developed with a lot of extensions. Replacing something like Spring seems quite difficult I think.


    • #3
      I briefly looked at ATG Dynamo a few years ago, but would have thought this was an apples and oranges sort of comparison.

      At the time, I think ATG Dynamo was part of a 300K per license high-end content management system. I guess ATG Nucleus is their core framework then.

      Spring is an inferior framework to Nucleus
      Go ahead and use it then. Knock yourself out.

      Maybe Oracle and BEA will be posting support for ATG Nucleus soon, or you'll be able to download the source code, or Martin Fowler will reference ATG Nucleus in some paper on best-practice approaches to software development...


      • #4
        I worked with ATG Nucleus/Dynamo a few years back, too. At that point(circa 2001) it totally blew me away compared to the mess I've seen in jrun or weblogic (weblogic 5, go figure). It's got a neatly laid out architecture, a service-oriented framework, and a very nice GUI workshop.

        That said, today I wouldn't give up Spring for Nucleus except when I'm told to use Dynamo (even in that case I'd try to put at least the business tier in Spring). The reason is very obvious - when there is a vendor-neutral and open source framework that does the job at least as well, why would I want to use something vendor specific - even let's just _pretend_ that they were both free for a moment?


        • #5

          Thanks for your responses.

          Another question: what does he mean by "Spring has only 2 scopes, Global and 'do it yourself'."?

          Also: is he justified to claim that Spring is fine for small projects but grows unwieldy as the application scales?


          • #6
            Spring versus ATG nucleus

            I was a big fan of ATG Dynamo back when DCS (Dynamo Commerce Server) 4.5 to 5.x were around. At that time, Dynamo nucleus technology was far more superior to any server-side technologies, IMHO. However, it is not quite fair to compare Spring framework to Dynamo Nucleus since Spring framework is a lot more than jsut managing a life cycle of beans (services) while Dynamo provides a lot more than just nucleus technology.

            For instance, Dynamo Commerce Server with a lot of innovative technologies (at the time) such as content management, repositories, filter, request pipeline, etc ... is built on top of a core nucleus technology using XML files to manage and to configure beans (components). Spring Framework, jsut to name the few of its features, provides AOP implementation and integration to persistence technology such as Hibernate, JDO, J2EE entity bean, etc ...

            By the way, from my experience, the posting is correct in comparing how ATG nucleus and Spring framework manage bean life cycle and XML files. I will let the authors of both technologies voice their opinions.

            What drives me to select a technology is not simply in the apple-to-apple comparisons but the business context in which I will use the technology, and of course budget is one of many critical factor. I have been using Spring framework since its inception and I would advocate and recommend this technology to anyone. However, if my client has a big budget and would like to go live with a commerce web site containing a lot of dynamic content management, perhaps I would turn to DCS.

            For the record, I am using Spring now on a large J2EE project and I love every aspect of Spring Framework. Big thanks to Spring developers.

            Just my 2 cents.



            • #7
              I've already seen these comments from ATG elsewhere. Interesting.

              I've been working with a large client this week who are moving from ATG/Nucleus to WebLogic/Spring--and are very happy with what they're finding. I was not aware until a few months ago that Nucleus offered what would now be called a Dependency Injection mechanism.

              I'm planning to spend some time next week assessing Nucleus in order to be able to respond to these comments.

              From what I've gathered so far from the client and a quick glance over the Nucleus docs, the comparison misses a lot of important points, and seesm to have been written by someone who didn't know a lot about Spring.

              One huge thing it would appear that Nucleus lacks is an AOP concept. Spring isn't just about DI. To enable a POJO programming model it's essential to be able to apply services declaratively, and to offer a highly extensible IoC container, which Spring enables via post processors etc. Also, of course, the ATG offering does not offer the portability/pluggability benefits of Spring, such as the ability to integrate with leading O/R mapping tools rather than a proprietary repository.


              • #8
                For the record, I am using Spring now on a large J2EE project and I love every aspect of Spring Framework. Big thanks to Spring developers.
                Thanks. Glad you're happy.


                • #9
                  When i first stack looking at a development stack of JSP/JSTL-SpringMVC-Spring-Hibernate it reminded me of the development using JHTML-ATGFormHandlers-Nucleus-RelationalViews we used to develop sites such as and back in 99/00. Spring is a much more sophisticated model.

                  ATG doesn't have much of a MVC model at all relying mostly on droplets(dependency injected tag libraries). We used to 'fake' MVC by putting a formhandler onLoad method at the top of each page (it had to be the very very top in case you wanted to 302 redirect) to act as a controller. It was very unfriendly unless you followed a specific development pattern.

                  The 'request-session-global' scoping of beans could cause problems too and was frankly unnecessary. if you injected a session scoped bean to a global object the global object would only reference the first session ever created and could often result in all users seeing one users session. ATGs own CRM code had this bug in it at one point.

                  RelationalViews were an early ORM and fairly useful but dont have the power of their modern equivalents. I know ATG has now replaced them with repoistories and RQL..... mainly as integration into all their "products", personalisation, portal, scenario server etc...

                  Yes ATGs core server (DAS)was ahead of its time, it was lightweight, had IOC, had configurable beans, had ORM, had expression language way ahead of the Sun specs and the ironic thing is it got killed on marketing because it wasn't "J2EE" and now people are coming round to the idea that maybe a lighter faster-development J2EE is the way to go.

                  Spring has far more going for it now though, its more modern with vast additional features in AOP, transaction management, pooling and a vast range of integration into other products.[/b]


                  • #10
                    Btw I'm working on Request and Session scoping, which I'll check into CVS after 1.2.3 is out. Our ex-ATG client were keen to have it, as they're used to it. It can easily be done using a Spring AOP TargetSource. And because the implementation isn't tied to the web layer, there are lots of interesting other possibilities, such as a per-transaction scope, or a scope transparently backed by a JavaSpace, with replication support.


                    • #11
                      thats an interesting concept. Spring POJOs and javaspaces, could be very cool.

                      But ATGs concept of session scoped object was "one per user session". how will this not be tied to the web tier. guess you could pass the session id on the thread and use that to determine the invocation lookup ......


                      • #12
                        Sure, the web session implemention is tied to the web tier, but the concept of a ScopedTargetSource is not. There's a resolution strategy interface behind it that can be implemented backed by a request or session.


                        • #13
                          yeah i get that. the possibilities are quite powerful. i guess the ThreadLocalTargetSource is already sort of an example of a ScopedTargetSource

                          just considering how you would implement a TargetSource that understands the concept of a web request or web session, Either "backed" by the request object or session which im guessing would require some kind of ThreadLocal setting variable indicating which Request or Session object belongs to this Thread. or by having a cached lookup of object invocations to sessionid/requestid and passing that in the thread. Either way its going to require the dispatcher servlet or an interceptor accessing the TargetSource to set the request/session on a ThreadLocal variable.

                          but maybe you can think of a better way :o) Either i look forward to seeing what you come up with.


                          • #14

                            which im guessing would require some kind of ThreadLocal setting variable indicating which Request or Session object belongs to this Thread
                            Yes, this is how it's done. It uses a Filter to bind the request, so will work in Struts, JSF et al as well as Spring MVC.



                            • #15
                              Originally posted by Rod Johnson
                              ... And because the implementation isn't tied to the web layer, there are lots of interesting other possibilities, such as a per-transaction scope, or a scope transparently backed by a JavaSpace, with replication support.
                              As a side note here, I just want to say that JavaSpaces are awsome, and I've never understood why they haven't taken off more in environments needing clustering and scalability. I suppose many end users who don't need the more exotic features of JavaSpaces can settle just fine for some JMS implementation (such as the incredible ActiveMQ) - JMS implementations tend to be more mature as well, since they are more popular - but still, JavaSpaces is just... awsome.

                              - Andy