Beans, beans, and more beans...what does what?_问答_开发者

I've recently been given a project to work on that involves writing a web application. I've never done Java EE before. A lot of resources on the web are dated and I'm having trouble figuring out what the current differences are between the various standards and Java technologies.

Originally I thought I really needed EJB 3.1 due to dependency injection, JPA, session management, and web services. I started experimenting with Glassfish but was told that we had to write the thing in Tomcat. So I've been trying to figure out what I need as well as what and how to put into Tomcat to get there. I've begun to question whether I even need EJB at all.

I want to use JFS, I think, for the MVC architecture. In learning about that I've run into both ManagedBeans and CDI, which according to some renders the former obsolete and also seems to provide all the dependency injection stuff I want to enable unit testing. I've also come to realize that I can get JPA outside of EJB in the form of Hibernat开发者_如何学编程e and maybe a few others. Additionally it seems that web services, which I don't know that I need anyway, come in the form of another standard I can't think of the name right now and this also can be installed independently.

My major issue here is session management and state. It seems to me that all which remains for EJB to do is provide @Stateless/@Stateful and @Local/@Remote. However, as I understand it, some of this is already exists in the form of session management in the servlet container...but I don't know how much or what the major differences are that I need to account for in order to decide if I need these things at all.

So my question is, what are the basic, essential differences that I need to know in order to decide if EJB is worth looking at or if I have enough in the form of other libraries and technologies? I've been all over google and Usenet and have not been able to find this information anywhere.

Just thought of another bit. As I understand it, the @Stateful bean annotation provides me thread-safe state saving. I'm probably not going to directly use threads, but I know Java does so behind the scenes a lot and suspect EE especially so. When I need to keep state I don't want to be dealing with threads if this already provides it.

ManagedBean

Java EE 6 has three different ways of defining beans that are managed in one way or another:

@javax.faces.bean.ManagedBean

JSF 2.0 introduced this annotation declaring managed beans in faces-config.xml. This annotation is used to access a bean from the Expression Language.

@javax.inject.Named

In an EE 6 container CDI this annotation is a built-in qualifier types to provide a name to a bean, making it accessible through EL.

@javax.annotation.ManagedBean

This annotation attempts to generalize JSF managed beans for use elsewhere in Java EE.

If you deploy in an EE 6 container (If you use Tomcat or another servlet container, you can also get CDI by adding the Weld jar to your web app), then there is really no reason to use @javax.faces.bean.ManagedBean. Just use @javax.inject.Namedand start taking advantage of CDI sevices.

CDI

One of the objectives of CDI specification is to bring together the Web tier and the transactional services, making easy for developers to use EJB along with JSF in web applications of the Java EE platform. With CDI you have the following services among others : well-defined lifecycle contexts(influenced by seam 2 and conversation scope), Dependency injection, loose coupling facilities like interceptors, decorators and events and portable extensions, which allows third-party frameworks to integrate in the Java EE 6 environment like SEAM 3 extensions

Managed beans and EJB Services

First of all CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a @Stateless, @Stateful or @Singleton annotation. IMO they act as complementary technologies allowing you to have a flexible and gradual development just only adding some annotations.

So, when should we use a session bean instead of a plain managed bean?

When you need some EJB features that CDI is missing : declarative transactions, concurrency management, pooling, remote or web service invocation ,timers and asynchronous method invokation.

Of course you could also get all aspects using third party libraries - but this would introduce additional complexity to your project. In terms of functionality IMHO EJB are the place to implement :

Business logic, allowing you to have a cleaning separation of busniness logic and web tier logic (implemented by "JSF backing beans" which are CDI managed beans but no EJB)
Functionality which makes most sense for components which are entrypoints to the application (endpoints for remote invocations delivered via RMI or HTTP)

Finally if you need EJB services then you need an Aplication Server (eg. GlassFish or Jboss AS) if you only need CDI services you need a Servlet Container(e.g Tomcat) plus CDI libraries.

Do you need the features provided by EJBs, i.e. security and transaction management? If the answer is yes, EJBs might be a good option. If the answer is no, and you only need dependency injection, CDI could then be a good option. You can also get similar capabilities with other 3rd party products, like Spring (dependency injection, Spring security, etc), but deciding whether you use one (EJB) or the other (e.g. Spring) is in many of the cases a matter of previous skillset.

In my opinion, if there are no previous constraints, going Java spec compliant is a good investment.

I would suggest you to start with the CDI and proceed to the EJB's (which is really adding one annotation on top of your POJO) if the requirements needs them (just as it was told - transactionality, web services, JMX, timers, EJB asynchronous invocations).

It's quite reasonable to develop an application in which your entry point is an EJB which encompasses your call in the transaction and allows you to define multiple entry points. The EJB then invokes the CDI beans with the business logic in them.

It's also worth noticing that the TomEE is a certified Java EE 6 Web Profile developed on top of the Apache Tomcat.