Originally posted by viswanadh kasinadhuni:
Kathy,
I just wonder how far the above said statement is true? Dont you think we need to learn and memorize all of the following technologies:
J2SE 1.3
JNDI 1.2
JTA 1.01
JDBC 2.0
JMS 1.02
JAVAMAIL 1.1
And how many people have written Enterprise Beans that scaled to multiple containers??
OK, this is another really good question.
The only thing you MUST know, in order to do EJB, is a solid knowledge of the Java language. If you have passed
SCJP, you have enough Java knowledge. Actually, *more* than enough, because you do not do threading in EJB, for example. You do not need to know many/most of the APIs in J2SE, other than those you'll be using. You'll do know file IO or AWT/Swing for example. No custom classloading.
As for the others, you do not need to know them unless you are going to be using them. You do not need to know JTA, but you DO need to know the javax.transaction,UserTransaction, which you'll learn as part of learning bean-managed transactions. (But even that, you will most likely NOT use BMT, in which case you wouldn't even use THAT).
You do NOT need to know most of JNDI, other than getting an initial context and navigating / doing lookups. Again, very simple, and only a very small part of JNDI. Your container is required to do the JNDI registration on your behalf, so the only JNDI you really need is what is in the spec, UNLESS you are also doing additional work with your company's naming & directory services. But just because you're doing EJB, does not mean you're responsible for managing/administering a company's naming services.
You do NOT need to know JDBC unless you're doing BMT, which very few people are with EJB 2.0 (if you are working with legacy EJB systems, then yes, you probably WILL need JDBC.) A large part of the POINT of EJB 2.0 was to prevent developers from having to be DBA's or know JDBC, since CMT will nearly always be faster and more efficient than using BMT.
JavaMail you would need only if you happen to be writing an application that uses it. Most won't. I would put that in the category of "just in time learning" -- wait until you need it, which you may never need.
JMS, I agree that
you should have *some* familiarity, but other than understanding the purpose and how message-driven beans work, you can probably hold off learning much about JMS until you know for certain that you will need to use it, either because it's already a part of the enterprise system, or because you've identified it as a part of your design (so, if you're a designer or architect, you WILL need to know enough about JMS to know whether you should use it... but you certainly don't need to know much about the APIs.)
So, writing EJB's really *is* pretty easy. BUT... that doesn't mean assembling and deploying an application is easy. Not to mention administering it! In other words, if your job is simply to write business components, then, as others here mentioned, it is fairly straightforward and MUCH easier than if you had to write code for transactions and security and concurrency, etc.
But if your job is to build a complete application, whether from existing components or those you create (or more likely, a combination), you have a lot of choices to make. Still, the best way to make reusable applications in EJB is to use declarative transactions and security, and allow as much customization as possible to happen during DEPLOYMENT rather than during code development.
If you are writing for a clustered environment, the difficulty is *not* in how you write your components. If you have written components to the specification, they should be usable regardless of whether the server is clustered or not. In reality, of course, there are issues... but they are much more vendor-specific / Container-specific issues rather than strictly EJB issues. So I would say...
"Building EJB components is easy"
"Assembling and deploying an application can be a little harder" (sometimes a LOT harder, depending on the complexity of the app)
"Administering a large-scale clustered J2EE server is hard."
and finally...
"Architecting and designing a large-scale J2EE application can be challenging!"
If I were looking for a job, I'd be hoping for business component developer
and I would run SCREAMING away from a job that required me to manage the server environment. But often, you don't get a choice. Especially these days.
So, the business component development (in other words, creating the EJB) is by far the easiest part, and requires only a basic level of Java knowledge. Crafting an application requires more sophisticated knowledge, since the application level can affect performance in profound ways... (like, choosing to make separate transactional calls to an entity bean rather than scoping three calls to the same bean in the same transaction, for example) or, using a multi-row finder when a home business method would be far more efficient... and of course transaction scope and security is in the application level as well.
And architecting and/or designing both the application and its deployment can be a Big Decision, not left to junior programmers, even though a fairly inexperienced programmer can write good beans, if they understand how EJB works, so that they know WHAT to put, for example, in each of the lifecycle methods.
cheers,
Kathy