I'm not closely familiar niether with ATG nor with EJB, only have a rough notion about the latter. Have just started to read about ATG, and it seems that one of its components (namely Nucleus) uses EJBs. It also seems like everything else in ATG is based on Nucleus. I'll maybe have to work with ATG soon, so:
1) What is the relationship between ATG Nucleus and EJB?
2) Are EJBs that nucleus use usual EJBs?
3) Are EJBs necessary for Nucleus? Can I use something else instead?
4) Does Nucleus use full functionality of EJB or replaces it somewhere?
5) Can the functionality provided by Nucleus be fully replaced by EJBs?
6) Do I need to study EJB to use Nucleus? Will it improve my understanding of Nucleus?
Sorry if these questions are stupid, I'm just trying to speed up my studying.
Have also found an article about some DataNucleus (formerly known as Java Persistent Objects JPOX) on wikepedia. Is it the same Nucleus?
The Nucleus is not an EJB and does not use EJBs.
The Nucleus is a bean container, somewhat akin to a Spring Bean Factory or Application Context.
More specifically, it is a registry and a container for managing the lifecycle of and the binding between components.
In that sense, you may consider it to be similar to an EJB container, but it is a lot less complex.
The components it manages are simple JavaBeans (POJOs), though convention dictates that they are usually subclasses of an ATG-provided class (such as GenericService).
When you package up an ATG application, it is assembled into an EAR.
When this EAR is deployed and instantiated in a Java EE application server, it is the Nucleus that is started up. The Nucleus, in turn, instantiates the components it is responsible for.
You can package your application alongside EJBs, and you can deploy other EARs into the same application server, but these are not ATG applications. These do not use the Nucleus, and vice versa.
So, to answer your questions
None.
No. The Nucleus does not use EJBs. It uses POJOs
No.
Yes. I recommend you use the ATG-provided base classes and then extend those components you need to or create new ones as you need
It replaces it in almost all respects.
The Nucleus is a registry as well as a component container. Every component managed by the Nucleus has a unique name in a Nucleus namespace. The Nucleus exposes these components via JNDI and Java name-resolution API methods.
You can also expose Nucleus components as web services (SOAP) and REST services (JSON over HTTP). ATG as a platform (technically not the Nucleus, but ATG-provided components running within the Nucleus) also provides a message-driven event framework for developing message-driven logic via JMS.
Further, the ATG platform (again not the Nucleus but ATG-provided components running within the Nucleus) provides a Repository framework which is an ORM layer, but not just for relational database data sources, but also LDAP, XML and other file data sources.
At a technical level, yes.
However, EJBs (especially before EJB3) are very clunky and seem overly complex. Dependency injection, managed entities (ORM), etc. are just much less effort ATG, and also in some other frameworks (Spring Hibernate etc.)
Moreover, ATG as a platform (again, not technically just the Nucleus), provides a lot of sophisticated business functionality for personalisation and commerce.
No. Not at all
Yes. But only in a very limited way. Any learning or understanding is a journey from the known to the unknown. The greater the base of the known is, the easier it is to move towards the unknown as you have many more jumping-off points.
If you already know Java EE very well, then you will be able to relate to what the ATG platform is doing under the hood and therefore will understand it easier. However, if you do not know EJB at all, then learning it for the sake of understanding ATG better will actually have a detrimental effect.
On the other hand, I think it it imperative that you know and understand Java EE web applications (JSP, Servlets, Filters, etc.) in order to work with ATG best.
No. It is completely unrelated