• Post Reply Bookmark Topic Watch Topic
  • New Topic

Some fundamental Java EE concepts are preventing me from moving forward

 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all the Java EE experts, who are having fun with Java EE, please allow me to have some fun too! Please, please, help me on each confusion I mention below. I cannot sleep at night.

I have a strong background and certification in Java SE 7. I am investing heavily on Java Enterprise Edition 7 by trying out things using Netbeans 8 and GlassFish 4. There are things blocking my way about which the more I read references I more confused I become. Kindly help me clear the way.

Confusion-1: I have started with EJB. There are so many types of beans out there! Other than EJB (stateful, stateless, singleton, message-driven), I am coming across more types. Would you please tell me what is a managed bean?

Confusion-2: I see that EJB's are sometimes referred to as CDI beans. What are these CDI creatures actually?

Confusion-3: Are all types of beans (EJB, managed, entity, CDI, others I have not seen yet) supposed to conform to the Java Beans Model by defining SET and GET methods? Is that a mandatory requirement?

Confusion-4: From my Java EE client application, I can easily obtain a reference to a stateless session bean with the @EJB annotation. But I am having a hard time trying to distinguish between @EJB, @Inject, and @Resource.

Confusion-5: Regarding message driven beans, what is the difference between a MessageDrivenContext and transaction context? When would I prefer one to the other?

Confusion-6: Where does a messaging service provider fit in the n-tier hierarchy? The EIS tier? Aren't queues/topics part of the messaging service provider? Then why is a queue configured separately for use with Glassfish MQ?

Confusion-7: This is giving me a really hard time. JDNI. I know that java:comp/env is a naming space/environment that is private to each EE component, but what is its role actually? Is it used when a component attempts to find a reference by using portable global JDNI lookup? Is it used when a component attempts to find a reference by using @EJB?
 
J. Kevin Robbins
Bartender
Posts: 1801
28
Chrome Eclipse IDE Firefox Browser jQuery Linux MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Others may disagree, but imho, don't spend a lot of effort on EJB. They are not widely used. In ten years, I have never used one.

As you transition from Core Java to JEE, my advice is to learn to properly structure a web app using MVC. Learn EL and JSTL. Never, ever write a scriptlet. Bear has some very good links for these topics, but I'm on mobile and don't have access to all my links and notes.

Also, on my list to learn more of is web services. If you like doing client-side coding, learn jQuery.

I think there are lot of other things that are more important to learn than EJB.
 
Michael Remijan
Author
Ranch Hand
Posts: 131
7
Java
  • Likes 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Confusion-1: I have started with EJB. There are so many types of beans out there! Other than EJB (stateful, stateless, singleton, message-driven), I am coming across more types. Would you please tell me what is a managed bean?

EJBs are the part of Java EE which provide thread-safe high performance transactional operations for your application. Do you need to read-write to a database? Do that with an EJB. Do you need to need to update multiple database and send JMS message all within a transactions so all that work is atomic? Do that with an EJB.

Typically @Stateless beans are most commonly used. They can be deployed as part of a WAR, stand-alone as part of a JAR, or bundled into an EAR. Start your application by putting everything into the WAR and if you have great need then separate them later. @Stateless beans are also great for “micro services” because they are a thread-safe pooled resource so they provide very high performance servicing requests.

@Stateful beans are like a webapp session…each session gets its own instance to store its own stuff. These aren’t used much anymore.

@Singleton beans are most commonly used for configuration and reference data. They can be deployed as part of a WAR, stand-alone as part of a JAR, or bundled into an EAR. They can be configured to automatically instantiate when the application is deployed. They can cache reference data for the lifetime of the application – use your imagination for what kind of read-only reference data your application may need. Combine this with the @Scheduled annotation to automatically refresh the cached data periodically.

@MessageDriven beans are typically used for listing to JMS topics or queues for messages to process. Very valuable, but not needed by all applications.

BTW, this stuff is supported by a server that implements a the full Java EE specification or one that implements the Java EE Web Profile. Payara, WildFly, and TomEE are good. Avoid using Tomcat…it’s just Servlet/JSP container and as such lacks may of the Java EE features.

As the Java EE specification evolves, it’s looking like the having a separate specification defining the EJB components will eventually go away and a lot of the functionality that EJBs provide will move into the CDI specification. Every application (typically) needs thread-safe transaction management so in my opinion they are essential. Question is do you use functionally provided to you by your EE server or roll your own solution?

Confusion-2: I see that EJB's are sometimes referred to as CDI beans. What are these CDI creatures actually?

Context and Dependency Injection (CDI) is a completely different specification from EJBs. CDI is the Java SE and Java EE standard for doing dependency injection for your code. As the Java SE and Java EE standard, its preferable to use over other 3rd party dependency injection frameworks because your code is much more portable for use with either Java SE or Java EE applications because it avoids class path and backward compatibility issues.

From the standpoint of history, EJB components were part of the Java EE specification right from the beginning because of critical need for a component to handle transactional operations. A few years later, CDI was added to the Java EE specification to provide a standard for dependency injection.

Confusion-3: Are all types of beans (EJB, managed, entity, CDI, others I have not seen yet) sup posed to conform to the Java Beans Model by defining SET and GET methods? Is that a mandatory requirement?

No, it’s not a requirement. The Java Beans model is most heavily used by JPA and JSF. JPA is the Java SE and Java EE ORM standard, so it’s @Entity classes typically follow the Java Beans getter/setter because you need to get and set your data. JSF is the Java EE standard web view technology and it relys on the Java Beans model for mapping data coming in from HTTP GET/POST to Java objects.

Confusion-4: From my Java EE client application, I can easily obtain a reference to a stateless session bean with the @EJB annotation. But I am having a hard time trying to distinguish between @EJB, @Inject, and @Resource.

@EJB was the very first dependency injection supported by Java EE. @EJB came before the CDI specification existed for Java EE. Once the CDI specification became part of Java EE, it’s @Inject tag could anything, including instances of EJBs. So there is some overlap between the two. There are some very subtle differences between using @EJB and @Inject and it’s one of those things that if you have a need for the subtle difference then you’ll know about it – you’re using a remote EJB. Using @Inject is preferred and will be correct the majority of the time. Using @Inject is used for injecting instances of classes from you’re application’s code. The @Resource annotation also does dependency injection but thing of using @Resource as a way to get something from your application server – an EntityManger for JPA, a JNDI variable, etc.

Confusion-5: Regarding message driven beans, what is the difference between a MessageDrivenContext and transaction context? When would I prefer one to the other?

I’m not too familiar with messaging so I won’t comment on this one.

Confusion-6: Where does a messaging service provider fit in the n-tier hierarchy? The EIS tier? Aren't queues/topics part of the messaging service provider? Then why is a queue configured separately for use with Glassfish MQ?

GlassFish comes with its own messaging server and yes, you use the GlassFish admin console to setup queues and topics your application needs to use. How you use messaging in your application is outside the scope of a quick discussion, but, in general your code should always connect to a topic or queue provided by the application server and not have any concern for how the queue or topic is actually configured. For example, the queue may be using the messaging server provided by GlassFish or the queue may be connecting to a messaging server at another company you want to do business with. Your application doesn’t care about the details…it just know that the queue I want to connect to is bound to “java/com/env/jms/myqueue” and that’s it. The messaging servers take care of all the nasty details of making sure no message gets lost and all messages eventually get delivered.


Confusion-7: This is giving me a really hard time. JDNI. I know that java:comp/env is a naming space/environment that is private to each EE component, but what is its role actually? Is it us ed when a component attempts to find a reference by using portable global JDNI lookup? Is it used when a component attempts to find a reference by using @EJB?

JNDI namespaces are confusing. Here’s a summary:

java:comp
Lookups in this namespace are scoped per component. For example, an EJB is a component, so each EJB in a JAR file gets its own unique java:comp namespace. This means both AccountEJB and CartEJB can look up java:comp/LogLevel and get different values. For backward compatibility, this isn’t true for the web module. All components deployed as part of a WAR share the same java:comp namespace. It’s unlikely you’ll use this namespace very often. It’s mostly there for backward compatibility. Prior to Java EE 6, java:comp was really the only standard namespace.

java:module
Lookups in this namespace are scoped per module. All components in the module share the java:module namespace. An EJB-JAR file is a module, as is a WAR file. For backward compatibility, the java:comp and java:module namespaces are treated identically in web modules and refer to the same namespace. You should favor the use of java:module over java:comp when possible.

java:app
Lookups in this namespace are scoped per application. All components in all modules in the application share the java:app namespace. An EAR is an example of an application. All WARs and EJBs deployed from the EAR would share
this namespace.

java:global
Lookups in this namespace are global and shared by all components in all modules in all applications.


In general, Java EE applications are supposed to be configured like this. Suppose you need a database DataSource so you can read/write from a database. Your application code can use a JNDI lookup like this to get it: ctx.lookup(“java:module/env/jdbc/myoracledb”). Now when you go to your application server’s admin console and you create a database connection pool, your application server (this is application server specific) may put the DataSource in JNDI at “java:global/jdbc/OracleProdDB”. At this point your code is different than the application server, but that’s OK. At this point you would look at what application server-specific configuration files you can include in you WAR that specify a configuration to map java:module/env/jdbc/myoracledb to java:global/jdbc/OracleProdDB so your application code can actually find the resource.

Because this can get so confusing, it’s typically better to stick with the annotations which inject the resources and figure it out for you.
 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Michael, so so much for going through the trouble of writing a long, long post.

So vibrant that I read it in one go!

Would you kindly touch on "managed beans" that I mentioned in my confusion-1?

Also, in confusion-6, does GlassFish MQ (the built-in messaging service provider in Glassfish) belong to the EIS tier?

___ softwarelover
 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In JSF, the term "Managed Bean" means a POJO (bean) that is managed by the JSF framework itself. JSF constructs such objects (using the bean's no-arguments constructor) whenever they are needed. For example, as View Backing Beans.

I suppose that CDI might be extending that term if the CDI framework instantiates the beans in question. I don't get along well with CDI, so I'm not as intimate with the terminology as I might be.

I've never heard that term applied to EJBs, which predate JSF by many years.


As Mr. Robbins has noted, EJBs (as such) are not all that popular. They were a local fad, but were misused horribly, mostly as façades for database stored procedures. Building them was messy (I wrote a GUI utility to help me) and the overhead of remoting was expensive. A lot of people got burned and swore off of them. Plus, neither of the popular lightweight servers Tomcat and jetty supported them.

Since then, EJBs have been through 2 major revisions. Revision 2 cut down on remoting, making EJBs less expensive to use in many cases. EJB3 subset itself to provide the JPA standard, effectively merging at least 3 previously distinct ORM systems (EJB, JDO and Hibernate).

So although EJBs themselves are relatively rare, the JPA subset of the standard is doing quite well. You can use JPA frameworks such as Hibernate JPA and Apache OpenJPA even in Tomcat and jetty.

As for JNDI, Java has a whole package subtree devoted towards naming and directory services. It serves not only JNDI, but also LDAP and I think a couple of less-commonly used directory lookup services. JNDI serves as a way to get a handle on remote objects. Either remote as in a different JVM (possibly on a different machine) or remote as in a different classpath (such as database connection pools provided by a webapp server). By using a symbolic pathname to specify a resource, the actual type and location of the resource can be abstracted.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!