Help

Matt Corey writes:

Whew, it's been a while since I've started looking at what's new in Java EE 6, partially because I've been fiddling with the newest addition to the Java EE portfolio -- JSR-299, aka CDI, f/k/a Web Beans, and this one could be big... Let's start with a bang -- CDI will eventually push EJB to obscurity...

The good news is that Matt seems to like CDI. The bad news is that for now there are questions out there about how CDI and the new managed beans spec affect the future of EJB.

Matt goes on to say:

CDI has the potential, I believe, to provide all of the most commonly used services that the EJB spec provides, and let's face it, this mean transactions, timers, asynchronous process with MDB's, and now Singleton Startup beans.

My take on this is a bit different. First of all, it's important to understand that there is no such thing as a CDI bean. 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, and away we go. Nevertheless, it doesn't seem necessary to require this lifecycle annotation if all we want to do is add declarative security or transaction management to a bean.

My view, for now, is that we can divide the functionality defined by the EJB spec into two categories:

  1. functionality which makes most sense for components which are entrypoints to the application - endpoints for remote invocations delivered via RMI, HTTP or message-oriented middleware, and
  2. functionality which should be available to beans which are part of the internal implementation of the application.

In the first category I include things like:

  • the basic stateless/stateful/singleton lifecycle model, which has always made most sense for entrypoints,
  • remote and web service endpoint interfaces, and
  • message-driven beans.

In the second category, I would put:

  • declarative concurrency management,
  • declarative transaction management, and
  • declarative security.

Even though these things are most useful at system entrypoints, they are also needed at a finer grain. And they're also needed for entrypoints which are not EJBs - for example, Servlets. So I think it's very likely that Java EE 7 will generalize these features to work for all Java EE components. That's certainly what we'll be arguing for.

If EE 7 does move in this direction, you'll be able to use plain managed beans in many cases which currently require EJB, and EJB itself will take on a clearer role in the EE architecture. EJB will be the spec with defines the programming model for remote and asynchronous invocation endpoints. It's likely that with this more focused identity, EJB will be a more manageable technology.

Of course, there's going to be couple of things which don't fit clearly in either category. The ones I'm most doubtful about are timers and asynchronous methods. These could, perhaps, be generalized to all managed beans, but it's not clear to me that there's a real need.

17 comments:
 
05. Dec 2009, 11:36 CET | Link

Ha, you didn't give me time for a follow up post, Gavin -- my next entry was going to discuss areas where EJB is still viable, and in fact preferable -- distributed and JMS-oriented systems, for example... these are the areas where I feel EJB was really intended, and where it fits quite well, although let's face it, the majority of applications don't fall into those areas...

CDI's ability to work with all component types is a major strong point in my opinion, and is one of the things that will help to promote its' use -- while the first attempt at dependency injection was a major step forward, for example, the fact that it only incorporated EJB's and a handful of Resource types was a huge drawback, and resulted in patterns and suggestions (including from myself) where all components are defined as EJB's... this is mostly harmless, and far, far better than in prior versions, but it is not without its' side effects, including context mismatches and resource pooling...

As for EE 7 generalizing things like declarative transactional and security management, I think it's a no-brainer... the problem is, we'll probably already have plenty of implementations already written around CDI :)

M

 
05. Dec 2009, 12:49 CET | Link
my next entry was going to discuss areas where EJB is still viable, and in fact preferable -- distributed and JMS-oriented systems, for example

I hope you go ahead and write it anyway :-)

while the first attempt at dependency injection was a major step forward, for example, the fact that it only incorporated EJB's and a handful of Resource types was a huge drawback, and resulted in patterns and suggestions (including from myself) where all components are defined as EJB's... this is mostly harmless, and far, far better than in prior versions, but it is not without its' side effects, including context mismatches and resource pooling

Look, I'm obviously going to be the first to agree that the dependency injection provided in EE 5 had its flaws and limitations, and that the contextual lifecycle model provided by CDI is a huge improvement.

And let me preface the following defense of EJB by saying that I was the guy who pushed really, really hard to get dependency injection for plain classes (now called managed beans) into EE 6. So I'm not unsympathetic to what you're saying.

But I don't think that the notion that you could (and still can) use EJBs in the internal implementation of the application is really far off base. Certainly, at the time, when people were comparing the architecture of EJB 3.0 to Spring 1.x, there was not a whole lot of difference between a Spring bean and a local EJB. I mean, the semantic differences between an injected local EJB @Stateful bean and Spring prototype are extremely small. Likewise, there is almost zero semantic difference between the new EJB @Singleton beans and Spring singletons.

My biggest problems with advising people to use EJBs everywhere were the following:

  1. EJB 3.0 had a hard requirement for a local interface, and
  2. injected stateful EJBs required explicit destruction via the @Remove method.

I remember trying to argue that we should drop the requirement for local interfaces in EJB 3.0, but by the time we had dealt with all the JPA stuff, the clock had simply run out on this one. But finally, EJB 3.1 solves this problem and eliminates the requirement for a local interface.

And CDI eliminates the second problem.

So at this point, the fear of using an EJB because it might be heavyweight is just completely unjustified to the point of irrationality. I've talked to so many people who tell me that they don't want to use EJB like this because it will have a performance impact. When I ask them why they believe that an EJB would be slower than, for example, a Spring bean, they simply can't explain it to me. At best, they mumble something about heavyweightness. When I tell them that I have actually done micro-benchmarks of this stuff and found no major overheads involved in creation/destruction/invocation of stateful beans in JBoss, they are shocked, and forced to admit that they have not actually tried it themselves. Even after I explain all this, I still hear folks saying stuff like well, I find that hard to believe, there just has to be some overhead to using a stateful bean. So we've now crossed over into the realm of religious belief, where actual evidence and reasoning are irrelevant.

But I'm also not quite sure what you're referring to when you say context mismatches and resource pooling. So perhaps I'm missing something in your argument. Precisely what is it in EJB that you believe makes it unsuitable for ubiquitous use in the internal implementation of the system? (Yes, I understand that this is now more of an intellectual question, since with CDI and managed beans, it's not something that we now advocate.)

As for EE 7 generalizing things like declarative transactional and security management, I think it's a no-brainer... the problem is, we'll probably already have plenty of implementations already written around CDI

Right, well, that's where I think there's a massive unsolved problem. Like I've said before, it's hugely problematic that everyone's inventing their own transaction managers, whether they're implementing them over CDI, Spring, Seam, whatever. We've got to find a way out of this vicious cycle of abstractions of abstractions of abstractions.

 
05. Dec 2009, 12:54 CET | Link

I suppose another major issue with EJB 3.0, which for some dumb reason I didn't really forsee at the time, was the requirement for an EJB jar. The ear format really is nothing more than a PITA for many people, and requiring it was a major misstep. That's also now fixed in EE 6. You can just put them in the war (duh). Of all the things we did to make EJB simpler to use, this was the easiest win. I can't believe it took us so long to get that right.

 
05. Dec 2009, 14:23 CET | Link

Another important aspect with EE 6 is that (hopefully) it has shown that if there are defects and room for improvement (which, there always is), it can be fixed within the platform. No need to re-invent your proprietary wheel. Arguably, the message would have been stronger without the 330-deal but I guess the situation played out as well as it could have, given the circumstances.

 
07. Dec 2009, 11:47 CET | Link
Arbi Sookazian
Gavin King wrote on Dec 05, 2009 06:49:
So at this point, the fear of using an EJB because it might be heavyweight is just completely unjustified to the point of irrationality. I've talked to so many people who tell me that they don't want to use EJB like this because it will have a performance impact. When I ask them why they believe that an EJB would be slower than, for example, a Spring bean, they simply can't explain it to me. At best, they mumble something about heavyweightness. When I tell them that I have actually done micro-benchmarks of this stuff and found no major overheads involved in creation/destruction/invocation of stateful beans in JBoss, they are shocked, and forced to admit that they have not actually tried it themselves. Even after I explain all this, I still hear folks saying stuff like well, I find that hard to believe, there just has to be some overhead to using a stateful bean. So we've now crossed over into the realm of religious belief, where actual evidence and reasoning are irrelevant.

Well lets compare Spring app (stateless) vs. Seam app (stateful). Seam 2.x makes extensive use of EJB 3.0 SFSBs. The passivation/activation via the MRU/LRU algorithms for the SFSBs requires the state of the object to be serializes to disk to save memory in the server (each client requires its own SFSB typically, thus no pool like with SLSBs). So in a production cluster, with sometimes dozens of nodes, the state is typically replicated at the end of each public interface method call. So there is overhead associated there as well as during passivation/activation.

Perhaps, in this case of SFSB and state replication and passivation/activation, the Spring folks are correct about the performance advantages of using Spring vs. EJB in a production clustered envmt?

Otherwise, I agree with your comments: I find it strange that I never see any concrete statements/analysis on performance in Spring beans vs. EJB 3.0. Both containers are using proxies to decorate the objects with container services, no?

I would love to see an independent study by load testing and comparing Seam3 vs. Spring3 performance on equivalent apps/usecases running on equivalent app server (Tomcat as LCD), and equivalent hardware/clusters... Or even Spring vs. JSF/CDI/EBJ 3.1, etc. The study should be independent of MVC frmwk if possible...

 
07. Dec 2009, 11:51 CET | Link
Arbi Sookazian

And now the counter-argument will be the advantages/disadvantages of stateless vs. stateful frmwks. With EJB, you can architect either/or or both. Not sure how to architect a stateful app in Spring. It's nice that the local interface and EAR are now optional in EJB 3.1...

 
07. Dec 2009, 13:09 CET | Link
Well lets compare Spring app (stateless) vs. Seam app (stateful). Seam 2.x makes extensive use of EJB 3.0 SFSBs.

Wrong, and wronger. A Spring app is not necessarily stateless (people put stuff in the HTTP session), and a Seam app is not necessarily stateful (you don't have to use the conversation scope, and plenty of Seam apps don't.) And it's just misleading to say that Seam makes extensive use of SFSBs. Not true. Rather, Seam lets your application use stateful beans, if and where you like.

The passivation/activation via the MRU/LRU algorithms for the SFSBs requires the state of the object to be serializes to disk to save memory in the server (each client requires its own SFSB typically, thus no pool like with SLSBs). So in a production cluster, with sometimes dozens of nodes, the state is typically replicated at the end of each public interface method call. So there is overhead associated there as well as during passivation/activation. Perhaps, in this case of SFSB and state replication and passivation/activation, the Spring folks are correct about the performance advantages of using Spring vs. EJB in a production clustered envmt?

Arbi, everything you just wrote is totally irrelevant, since we're clearly not talking about components which hold client-visible state across requests. This is the kind of bad thinking that is the root of so much nonsense and FUD about EJB. If we're comparing an EJB stateful bean to a Spring bean, we're obviously not talking about a stateful bean that survives across requests, because there is no equivalent construct in Spring. Rather, we're talking about a bean that is destroyed before the end of the request.

You should be comparing equivalent constructs in the two architectures. If architectures A and B both have construct X, but architecture B also has construct Y, you don't get anywhere by showing that Y has performance implications that X does not have, and thereby concluding that B is slower than A. That's just bad reasoning, the kind of thing we see a lot of whenever the topic of performance comes up.

 
08. Dec 2009, 13:24 CET | Link
Arbi Sookazian

Ok, I stand corrected. I meant to say that Seam apps typically make extensive use of SFSBs (not that the Seam core framework itself makes extensive use of SFSBs, but I think that should be fairly obvious). And yes, I'm sure there is some facility for state management (perhaps other than HTTP Session only) in Spring, but generally speaking, Spring is known as a stateless frmwk whereas Seam is known as a stateful frmwk. If you don't believe me, read this article by DAllen on Spring/Seam integration: Spring into Seam, Part 2: When stateless and stateful collide: http://www.javaworld.com/javaworld/jw-04-2008/jw-04-spring-seam2.html.

I'm not necessarily stating that Seam/CDI/EJB apps are less or more performant than Spring apps, I honestly don't have any data to support such a conclusion. I think it really depends on the requirements and the specific project/usecases/architecture/design patterns/cluster, etc.

The point I was making is that there is additional overhead involved when using SFSBs vs. Spring beans or SLSBs: passivation/activation and state replication in a cluster.

I'm actually somewhat surprised that there is no equivalent (yet) of a SFSB in Spring, however.

Oh, here we go:

Our plan with respect to conversation management is to introduce a core abstraction that we'll then build a custom BeanFactory Scope as well as a Spring MVC SessionAttributeStore adapter on top of. This will be smoothly integrated with Web Flow 3.0's conversation management as well. We also expect some Spring 3.x conversation support for JSF 2.0, but this has not been fleshed out yet. This won't be nearly as extensive as MyFaces Orchestra in terms of JSF support, though. Maybe a future Orchestra version will specifically integrate with Spring 3.0 for optimal interoperability.

http://blog.springsource.com/2009/02/25/spring-framework-30-m2-released/

In any event, I am looking forward to using CDI and EJB in the near future but it would be nice to see some performance benchmarks or load testing results released by JBoss for the new EE6 platform and test apps...

 
07. Oct 2010, 06:45 CET | Link
Bob

I'm really excited about CDI. But I think EE 7 needs to come up with a unified Bean plan. I don't really understand why, as a developer, I need to distinguish between a @SessionScoped CDI bean, or a @Stateful EJB, or likewise a @RequestScoped Bean vs. a @Stateless EJB... I shouldn't need to care about the container's technologies as much as being able to meet the needs of my app. If I need the tranactional support, why not let me just add @Transactional at the class or method level, or likewise a @Pooled vs. @Named annotation.

When I look at @Stateless, @Stateful, and @Singleton EJBs, they seem pretty much like @Request, @Session, and @Application scoped ManagedBeans. If we just add optional pooling, tranaction, and async/message driven support, aren't they the same?

Also why aren't JPA entities able to have beans injected? This ability is required to allow us to go back to real OO Design.

 
07. Oct 2010, 10:51 CET | Link
Bob wrote on Oct 07, 2010 00:45:
I'm really excited about CDI. But I think EE 7 needs to come up with a unified Bean plan. I don't really understand why, as a developer, I need to distinguish between a @SessionScoped CDI bean, or a @Stateful EJB, or likewise a @RequestScoped Bean vs. a @Stateless EJB... I shouldn't need to care about the container's technologies as much as being able to meet the needs of my app. If I need the tranactional support, why not let me just add @Transactional at the class or method level, or likewise a @Pooled vs. @Named annotation. When I look at @Stateless, @Stateful, and @Singleton EJBs, they seem pretty much like @Request, @Session, and @Application scoped ManagedBeans. If we just add optional pooling, tranaction, and async/message driven support, aren't they the same?

I agree with the premise of this -- and for example we are considering building EJB on top of CDI for JBoss AS 7. And, as you say adding @Stateful and @Singleton to get EJB services seems like overkill (@Stateless is somewhat different, as indicates not to hold any state, but to use pooling).

Also why aren't JPA entities able to have beans injected? This ability is required to allow us to go back to real OO Design.

I'm not aware of the reason for this tbh, I will tr to find out.

 
07. Oct 2010, 17:24 CET | Link
Also why aren't JPA entities able to have beans injected? This ability is required to allow us to go back to real OO Design.

I think the main use case for this would be domain driven design where it would be typical for an entity to persist itself. A good example of this is the way Spring ROO generates entities (not advocating any technology over the other, just an example)... they are able to inject an EntityManager into an entity, and also apply the @Transactional attribute to a method of an entity. There is no way I know of to implement this approach with Java EE 6.

Example:

@Entity
public class Person { 
...

@PersistenceContext
private EntityManager em;

 ...

@Transactional
public void save() {
  em.persist(this);
}

}

Controllers would interact directly with the domain objects and not need layers of services and domain objects.

 
21. Mar 2011, 09:22 CET | Link
Yannick Majoros | yannick.majroos(AT)gmail.com
Also why aren't JPA entities able to have beans injected? This ability is required to allow us to go back to real OO Design.

That's not real OO Design, this is a violation of the Single Responsability principle. It clutters the design, couples the entities with specific persistence code, etc.

A cake shouldn't know how to bake itself.

 
24. Mar 2011, 14:24 CET | Link
Fabrício Lemos

Yes it is real OO Design. It is very difficult to add behavior to an Object (Entity Beans) if it cannot collaborate to others objects, and this collaboration sometimes are better implemented or even requires other beans to be injected.

And if these collaborations are well modularized it doesn´t violates the single responsibility principle. For example, I do not have to add specific persistence code to my entity beans. Instead I can inject a DAO/Repository that abstracts this kind of service, not coupling my designs in any way.

 
24. Jun 2014, 12:00 CET | Link

Rates offered to mini Forex trading accounts by the brokerages are less advantageous compared to those offered to regular clients. Today all best forex brokers do their best to provide all clients with the same service quality regardless of their Forex account size The important currency trading strategies is to determine what time frame we are trading on. Many traders get in the market without thinking when they would like to get out, after all the goal is to make money

 
05. Oct 2014, 09:18 CET | Link
lkdj

As a non-distressed house's supplier, it behooves you to ensure that your house's appeal is at it's best and that throughout the interior, the customer is able to imagine the charming lifestyle they can, the begining that, WILL remain once they buy and shift into your house. Cash for homes

 
11. Oct 2014, 14:10 CET | Link

Precision customer, invented the electric service truck, and convinced Robichaud to test-drive the truck that he felt would be a perfect fit for the service industry because of the short routes service technicians drive daily. Property Buying company

 
20. Oct 2014, 12:48 CET | Link
xeun

Click This is a great article thanks for sharing this informative information. HD mxf files conversion software mxf converter pdf conversion to Office pdf to word w.