I just started Consulting 2 weeks ago. My first ‘gig’ is a pretty big J2EE’ish portal site. I say ‘ish because the chosen server is ATG Dynamo. I’d vaguely heard of it before…now I kinda know why. My first reaction to it was negative. I just questioned everything about it. The learning curve on it is huge (took me the first full week to understand what it was), it is REALLY expensive, and its not compliant (we’re using 6.3). I should clarify and say we are really using ATG Dynamo App Server + ATG Dynamo Application Framework + ATG Portal + ATG Commerce Module. Part of the confusion the first few days was that everything was refered to simply as ‘ATG’. So I have this love/hate thing going with it. There are some good parts and bad….I’ll spare you the bad and just cover the good.
Nucleus.
They have an IoC container they call Nucleus. They don’t sell it as an IoC but it really is. I would consider it more of a middle-weight container as it expects you to know a bit too much about the container itself. For example, they have the concept of having a scope set on the component (they call them components). Scope can be global (singleton), session or request. The last 2 indicate this is a web-only world and to get those components, you have to have a handle to the container and ask for the component in your methods (unless you are using strictly global scopes).
One thing I think Nucleus does really well is namespacing. The container reads properties files from a config directory (it can do xml too…but it seems that the properties files are preferred in ATG). There is 1 file per bean and the location of the bean in the heirarchy becomes the qualified name for the bean. So if you have com/foo/Bar.properties, then when you request the bean ‘com/foo/Bar’ from the container (or reference it) you’ll get the bean defined in that file. The class is actually defined in the file (under a special $class property), so it can really be of any type. There can be multiple (configurable) config folders for the container to search through and the definitions for the beans are all combined before applying them (properties defined for beans futher along the path overwrite those that show up earlier). Then there is a Globals.properties that just contains properties that will be applied to all beans (if the properties exist). Its sort of a cross between and IoC and JNDI.
They also have this ATG Control Center that they’re trying to sell as a full-fledged, everything tool. It does do a lot…but I think I’ll stick to my own IDE for the actual development. One of the neat things about it is the component browser (they call their IoC managed beans components). You can actually browse through the bean container at runtime and see all the components. It displays the configured values for their properties, the current ‘live’ (runtime) values for them and whether or not the component is currently running (instantiated). It will also show you what all config files had a part in the configuration as described above.
They also have their own ORM’ish technology they are calling Repository. It has the ability of persisting dynamic beans (HashMaps basically) or pojos. I haven’t been able to bring myself to read as much about this one…I keep hearing myself say “hibernate does that too…why don’t we just use hibernate”.
From what I’ve read, Nucleus has been around since 1997 and Repository since 1998…that impressed me. Seems it was a bit before its time and had some really smart people working under the hood. I’m not saying I like Nucleus over Spring (I don’t)…I do think there are some things that can be learned from it though.
I invite you to read about it here.
.
