Meera has posted 70 posts at DZone. You can read more from them at their website. View Full User Profile

EJB 3.1 – EJB New and Improved!

12.01.2008
| 71367 views |
  • submit to reddit

The EJB 3.0 specification was a huge improvement from what we were used to in the early versions of EJB. Available as an early draft, EJB 3.1 has many more features and is even easier to use.


Let’s take a brief overview of a few interesting topics being considered in this new and improved version of EJB.

Optional Session Bean Business Interfaces:

Writing enterprise applications using EJB 2.1, EJB 3.0 or Spring always promoted the idea of writing component interfaces.  In many cases, you could do with just a POJO without an interface. This new version of EJB allows you to write Session beans with no interfaces; just like you write your JPA entities and Message Driven beans. So, let’s see an example of how this can be accomplished:

package ejb31.samples.stateless.ws;

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;

import ejb31.samples.entity.Customer;

@Stateless
@WebService
public class CustomerManager
{

@WebMethod
public Customer getCustomer()
{
Customer customer = new Customer();
customer.setFirstName("FirstName");
customer.setLastName("LastName");
return customer;
}

}


Global JNDI Names:

I remember blogging about the issues I had to face due to the portability issues caused by vendor-specific JNDI names. I had to work around a solution for testing on three different application servers: JBoss, Oracle and GlassFish. Each of these application servers has completely different naming convention for remote interfaces.

The GlassFish AS uses the fully qualified name of the remote business interface as default: 

Object obj = initialContext.lookup("com.os.ent.CustomerManagerRemote");

JBoss on the other hand uses the application (EAR) name, followed by the EJB name and followed by a ‘/remote’ constant.

Object obj = initialContext.lookup("ejb3sampleapp/CustomerManager/remote");

Oracle uses the name specified in the @Stateless annotation.

Object obj = initialContext.lookup("CustomerManager");

In EJB 3.1, the global JNDI names would follow a standard pattern that is portable across all the different application servers: 

java:global[/<application-name>]/<module-name>/<bean-name>#<interface-name>

Singleton Session Beans:

In all the earlier versions of EJB’s, we could use two session bean types: Stateless and Stateful. With EJB 3.1, we have the one which many of us felt a need for from time-to-time called the Singleton. Yes, Singletons are POJOs just like our Session beans, and the container is guaranteed to maintain a single shared instance of this Singleton. These Singletons are thread safe and also transactional. Like all other EJB’s, singletons have all the services such as security, remoting, dependency injection, web services, interceptors and so on.

package ejb31.samples.singleton;

import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;

import javax.ejb.Singleton;

@Singleton
public class StateRegistryBean implements StateRegistry {

private final Map<String, String> states = new HashMap<String, String>();


public Collection<String> getStates() {
return new ArrayList<String>(states.values());
}


public void removeState(String state) {
states.remove(state);
}


public void setState(String name, String value) {
states.put(name, value);

}

}

Calendar Based Timer Services:

One of the most important changes in EJB 3.1 is the ability to declaratively create cron-like schedules to trigger EJB methods. All that is needed is to annotate an EJB method with the @Schedule annotation to implement the timer.
For example the following schedule represents "Every Monday at 6:15": @Schedule(minute=”15”, hour=”6”, dayOfWeek=”Mon”) send a weekly newsletter to everyone in the list:

@Stateless
Public class NewsLetterBean
{
@Schedule(minute=”15”, hour=”6”, dayOfWeek=”Mon”)
Public void sendNewsLetter()
{
}
}

 


Asynchronous Session beans:

In many enterprise applications I was involved, asynchronous processing was a must. And the only way to accomplish this was by using Message Driven Beans.  Even though writing MDBs was very trivial, configuring all the necessary server resources like connection factories, topics and queues made it a little bit of a chore, especially since all I needed was an asynchronous method invocation.
With EJB 3.1 these issues are easily solved by a simple annotation placed on the Session Bean: @Asynchronous. Under normal circumstances, a Session bean method call blocks the client for the duration of that call. With this annotation in place, the container returns control to the client and executes the method on a separate thread.
The Session bean method call which is annotated with the @ Asynchronous annotation can return a java.util.Future object that allows the client to retrieve a result value, check for exceptions, or attempt to cancel an in-progress invocation.

EJB Lite:

A vast majority of clients I have worked with recently use EJB applications. Most of them use injection, JPA, stateless session beans and transactions, but not necessarily messaging, remoting or web services. EJB Lite is perfect for such applications. The best part of EJB Lite is that you can write your enterprise application with no XML at all, and knowing a very small number of basic annotations.
The following is a list of features proposed for EJB Lite:
•    Stateless, Stateful, and Singleton session beans
•    Only local EJB interfaces or no interfaces
•    No support for asynchronous invocation
•    Interceptors
•    Declarative and programmatic security
•    Declarative and programmatic transactions
•    No support for Timers and scheduling

Easy packaging:

Even for the simplest web application, EJB 3.0 required that we have the components of the web application in a war file, EJB’s packaged in a jar file, and this war and jar in turn be packaged into an ear and deployed. This is very cumbersome, especially for new-comers to Java EE.
This isn’t the case anymore, all you would need to do is to drop all your EJB’s within the WEB-INF/classes directory and deploy these along with your web application.
If you have an ejb-jar.xml file, which again is optional, it would be placed within the WEB-INF directory just like the web.xml file.

EJB 3.1 Embeddable Container:

Testing EJBs was a herculean task all these years. It isn’t anymore with the timely and useful innovation of the embeddable container. The embeddable container allows you to use JPA and EJB 3.1 outside a container.  There are already a number of open source embeddable EJB 3 containers that can run in any Java SE environment. To name a few: Open EJB, GlassFish, JBoss. For unit testing as well as running all the examples included in this article, I used Apache OpenEJB communities latest release of OpenEJB 3.1. OpenEJB is an embeddable, lightweight EJB 3.0 implementation with partial support of EJB 3.1.
Let’s take a look at how I was able to successfully test my Singleton Beans. The listing below shows the test class.

 

package org.ejb31.samples;

import java.util.Properties;

import javax.naming.Context;
import javax.naming.InitialContext;

import junit.framework.Assert;

import org.junit.Test;

import ejb31.samples.singleton.StateRegistry;

public class StateRegistryTest {

	@Test
	public void testStates() throws Exception {
		Properties props = new Properties();
		props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
				"org.apache.openejb.client.LocalInitialContextFactory");

		InitialContext context = new InitialContext(props);

		StateRegistry stateOne = (StateRegistry) context
				.lookup("StateRegistryBeanLocal");

		StateRegistry stateTwo = (StateRegistry) context
				.lookup("StateRegistryBeanLocal");

		stateOne.setState("MaryLand", "MD");
		stateTwo.setState("Virginia", "VA");
		Assert.assertEquals(2, stateTwo.getStates().size());
		Assert.assertEquals(stateTwo.getState("MaryLand"), "MD");
		Assert.assertEquals(stateOne.getState("Virginia"), "VA");


	}

}

In the above test class, the org.openejb.client.LocalInitialContextFactory used as the JNDI provider, will automatically embed OpenEJB into the testing VM. The same instance of OpenEJB is used for all the tests within that VM.

And below is the output from within the Eclipse IDE when you run the above test:

Apache OpenEJB 3.1    build: 20081009-03:31
http://openejb.apache.org/
INFO - openejb.home = C:\dev\ejb3.1\samples
INFO - openejb.base = C:\dev\ejb3.1\samples
INFO - Configuring Service(id=Default Security Service, type=SecurityService, provider-id=Default Security Service)
INFO - Configuring Service(id=Default Transaction Manager, type=TransactionManager, provider-id=Default Transaction Manager)
INFO - Found EjbModule in classpath: C:\dev\ejb3.1\samples\build
INFO - Beginning load: C:\dev\ejb3.1\samples\build
INFO - Configuring enterprise application: classpath.ear
INFO - Configuring Service(id=Default Singleton Container, type=Container, provider-id=Default Singleton Container)
INFO - Auto-creating a container for bean StateRegistryBean: Container(type=SINGLETON, id=Default Singleton Container)
INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container)
INFO - Auto-creating a container for bean HelloBean: Container(type=STATELESS, id=Default Stateless Container)

INFO - Configuring PersistenceUnit(name=DemoPU)
INFO - Configuring Service(id=Default JDBC Database, type=Resource, provider-id=Default JDBC Database)
INFO - Auto-creating a Resource with id 'Default JDBC Database' of type 'DataSource for 'DemoPU'.
INFO - Configuring Service(id=Default Unmanaged JDBC Database, type=Resource, provider-id=Default Unmanaged JDBC Database)
INFO - Auto-creating a Resource with id 'Default Unmanaged JDBC Database' of type 'DataSource for 'DemoPU'.
INFO - Adjusting DemoPU <jta-data-source> to 'Default JDBC Database'
INFO - Adjusting DemoPU <non-jta-data-source> to 'Default Unmanaged JDBC Database'
INFO - Enterprise application "classpath.ear" loaded.
INFO - Assembling app: classpath.ear
INFO - PersistenceUnit(name=DemoPU, provider=org.apache.openjpa.persistence.PersistenceProviderImpl)
ERROR - JAVA AGENT NOT INSTALLED. The JPA Persistence Provider requested installation of a
ClassFileTransformer which requires a JavaAgent.  See http://openejb.apache.org/3.0/javaagent.html
INFO - Jndi(name=StateRegistryBeanLocal) --> Ejb(deployment-id=StateRegistryBean)
INFO - Jndi(name=HelloBeanRemote) --> Ejb(deployment-id=HelloBean)
INFO - Created Ejb(deployment-id=HelloBean, ejb-name=HelloBean, container=Default Stateless Container)
INFO - Created Ejb(deployment-id=CustomerManager, ejb-name=CustomerManager, container=Default Stateless Container)
INFO - Created Ejb(deployment-id=StateRegistryBean, ejb-name=StateRegistryBean, container=Default Singleton Container)
INFO - Deployed Application(path=classpath.ear)

I haven't seen anything as easier than this to run tests against EJB's. 

Conclusion:

I, like most developers, dreaded working with EJB 2.x. EJB 3 was a big step in the right direction. I myself was involved in writing a couple of enterprise applications in EJB 3.0, which I greatly enjoyed. With this latest, not yet released EJB 3.1 version, it took me less than an hour to explore all the examples shown in this article. I used OpenEJB 3.1 for this article and was even able to test some of the examples as shown above.


What are your thoughts about this upcoming version of EJB? Have you tried using EJB 3.1? The expert group in my opinion has done a tremendous job, what do you think?

You can also send your feedback directly to the expert group at jsr-318-comments@jcp.org. In case you like to know more about EJB 3.1, you can take a look at the EJB 3.1 public draft.
 

 

Published at DZone with permission of its author, Meera Subbarao.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bhaskar Karambelkar replied on Mon, 2008/12/01 - 4:04am

When you say "These Singletons are thread safe",

Do you mean each method is automatically synchronized ? Isn't that a big overhead, to synchronize each method ?

Per Olesen replied on Mon, 2008/12/01 - 7:29am

To answer your question: I think the expert group have improved EJB spec nicely from EJB3.0 til 3.1, yes.

To  answer the second question, have I used EJB3.1: No. And also not EJB3.0. Not for anything larger than testing it out at least.

Why? Because again, I think the EJB expert group and EJB spec is beginning to lack behind, when compared to what the world wants. 

Much of the developer community is talking DDD or simply want to put even more power to the POJOs in their model. We want to be able to express our logical models better in code. And EJB3 still follows the "old" programming model, of a services and data-access layer, which kind-off leads to procedural code.

What you can do with spring 2.5, load-time-weaving and injection into *all* POJOs, even JPA entities created by the ORM mapping tools or classes that are simply new'ed, you cannot do with EJB3.

Martijn Verburg replied on Mon, 2008/12/01 - 7:53am

I have to agree with Per, although 3.0 is an improvement on 2.x and 3.1 is an improvementon 3.0, I still have to ask "Are we there yet?".  The following presentationexplains really nicely why EJB3.x still doesn't quite cut it (well for some of us anyhow)

http://www.infoq.com/presentations/rod-johnson-are-we-there-yet

 

Andy Leung replied on Mon, 2008/12/01 - 8:29am

Good information!  In my experience, the most useful improvement is this list is the Asynchronous session bean.  Now I do not have to create tons of managed resources on server to just use separate threads to do some tiny calculations without blocking client interactions.  Imagine how easy it is for developers and deployers to manage multiple projects on different servers; well at least you don't have to mess with bunch of MDB resources (I think MDB is still very useful but what I meant was the usefulness of creating something tiny with asynchronous capability).

Ryan Developer replied on Mon, 2008/12/01 - 9:10am in response to: Per Olesen

[quote=pulesen]

Much of the developer community is talking DDD or simply want to put even more power to the POJOs in their model. We want to be able to express our logical models better in code. And EJB3 still follows the "old" programming model, of a services and data-access layer, which kind-off leads to procedural code.

What you can do with spring 2.5, load-time-weaving and injection into *all* POJOs, even JPA entities created by the ORM mapping tools or classes that are simply new'ed, you cannot do with EJB3.

[/quote]

Java EE 6's answer to that is WebBeans.  If you spend some time giving it a serious look you will find it to be very strong competition to Spring.  When features such as transactions, concurrency, timers, security, MDBs, etc. are needed then it ties in nicely with EJB 3.1.  I think the combination of Web Beans and EJB 3.1 is perfectly suitable for DDD. Use WebBeans most of the time and only use EJB when you need enterprisy things. 

Don't forget that using POJOs in Spring with AOP, weaving, etc. is no more "POJO" than EJB 3.1 or WebBeans annotated POJOs.   Also, like Spring, EJB 3.1 and WebBeans can be done entirely with XML configs. 

Ryan Developer replied on Mon, 2008/12/01 - 9:27am in response to: Bhaskar Karambelkar

[quote=vkbhaskar2.myopenid.com]

When you say "These Singletons are thread safe",

Do you mean each method is automatically synchronized ? Isn't that a big overhead, to synchronize each method ?

[/quote]

No it does not synchronize every method.  It uses Java 6 concurrency features, and gives developers a lot of per-method control.  You can also completely disable it and do bean managed concurrency. 

This link is almost a year old now so it may be a bit out of date, but it explains singletons in a lot more detail:

www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1

Reza Rahman replied on Mon, 2008/12/01 - 10:58am

Per,

I think the viewpoint you express is a little misinformed. EJB 3.0 fits quite elegently into DDD. As for the DI features most often asked for, Spring or Seam integration with EJB 3.0 can accomplish that when it is really needed. That being said, a lot of DI features are indeed being slated for WebBeans in Java EE 6.

Best regards,

Reza

Meera Subbarao replied on Mon, 2008/12/01 - 11:03am

I forgot to add links to the deatiled articles Reza Rehman has written on Server Side. Here is the link for Part 5, which again has links for all the previous ones as well:

New Features in EJB 3.1

 

Dave Macpherson replied on Mon, 2008/12/01 - 11:42am

I suppose it would be too much to hope for that changes to a singleton EJB's state are automatically replicated across a cluster (with low latency!), so as to give us a true, shared, cluster-wide singleton? I can see this as being a REALLY beneficial value-add for the appserver vendors.

Reza Rahman replied on Mon, 2008/12/01 - 12:11pm in response to: Dave Macpherson

Dave,

You may or may not know this, but the spec does not address "high-end" features like clustering, load-balancing and fail-over. However, I think this is a valuable comment to send to the EG comments email alias.

As far as I know, major vendors do plan to implement clustering, load-balancing and fail-over for EJB Singletons, so you should have your wish :-).

Regards,

Reza

Shreedhar Ganapathy replied on Mon, 2008/12/01 - 12:50pm

You can consider using Shoal's clustering capabilities to bring instances with singleton EJBs together through its messaging APIs.

https://shoal.dev.java.net

Although not a part of the spec mandated implementation, it is Java based and hence portable with your code until appserver vendors provide their own solutions for it.  

Project GlassFish is working to provide this as part of its EJB container level support when running in a clustered environment using Shoal as part of GlassFish v3

 

Per Olesen replied on Mon, 2008/12/01 - 3:06pm in response to: Reza Rahman

EJB 3.0 fits quite elegently into DDD

 I fail to see that. When coding EJBs, I feel more constrained, than I need to be. If I want DI to wire my application together, everything has to be an EJB, since only EJBs are eligible for injection in EJBs. I cannot simply do:

 

class Foo {

Bar bar; // dependency injected

}

new Foo();

 

unless I make Foo an entity bean.

If I need to integrate EJBs with spring, I would rather simply use spring.

Per Olesen replied on Mon, 2008/12/01 - 3:22pm in response to:

WebBeans.  If you spend some time giving it a serious look you will find it to be very strong competition to Spring

Maybe I am misinformed regarding WebBeans, but last time I looked, it looked pretty much like a specification for Seam, just with other names. Not suprising, given the spec lead :-) That makes Web Beans pretty much, well, "a web thing". I don't need a technology for gluing a web framework to EJBs. I need something to model and execute my domain model.

Don't forget that using POJOs in Spring with AOP, weaving, etc. is no more "POJO" than EJB 3.1 or WebBeans annotated POJOs

I am not sure exactly what you are getting at her!?

Sure, the implementation underneath, is pretty much the same. Classes proxied, either by a JDK proxy based on an interface or a class based proxying mechanism.That doesn't make the EJBs more capable. I inly get what the spec says, and that is not as much as I need.

 

Reza Rahman replied on Mon, 2008/12/01 - 4:06pm

Per,

The point is that for 99.9% of practical cases, it is quite sufficient  for both Foo and Bar to be Java EE managed objects. Also, I am not sure why you don't find it constraining that both Foo and Bar need to be Spring managed beans? What's the big difference really?

That being said, the more legitimate use-case that I see is integrating with third party components, which is what I find Spring or Seam useful for (I find Seam userful for other things too).

Regards,

Reza

Reza Rahman replied on Mon, 2008/12/01 - 4:12pm in response to: Per Olesen

Per,

I would suggest taking a look at WebBeans in greater detail. It is not "merely" Seam standardized or even specific to web applications. One of it's primary features is adding the cabality to inject non-managed objects in managed objects and vice-versa (that's what you were asking for and were equating to DDD, right?). A lot of the very futuristic DI features came from Guice, not Seam.

Regards,

Reza

Reza Rahman replied on Mon, 2008/12/01 - 4:20pm in response to: Per Olesen

Per,

[quote=pulesen]I inly get what the spec says, and that is not as much as I need.[/quote]

So care to elaborate what exactly it is that you need that EJB 3.1 and WebBeans does not offer (that's really the point of the article)? As I mentioned, the non-managed injection case that you mentioned is already met by WebBeans if and when it is even needed.

[quote=pulesen]I am not sure exactly what you are getting at her!?[/quote]

The point as clearly stated is that Spring beans are no more POJOs that EJB or WebBeans by definition. All are managed by an add-on runtime of some sort.

Regards,

Reza

Ryan Developer replied on Mon, 2008/12/01 - 4:27pm in response to: Per Olesen

[quote=pulesen]

Maybe I am misinformed regarding WebBeans, but last time I looked, it looked pretty much like a specification for Seam, just with other names. Not suprising, given the spec lead :-) That makes Web Beans pretty much, well, "a web thing". I don't need a technology for gluing a web framework to EJBs. I need something to model and execute my domain model.

 [/quote]

WebBeans takes the best ideas from Seam, Guice and Spring to create the next generation of IoC/DI to model and execute your domain model. It purposely doesn't duplicate functionality in EJB such as transaction management, concurrency, timers, and security.  If you need those features you simply add one or two annotation to your POJO, or if you prefer then do it in XML. Despite the name having Web in it, it doesn't need to have anything to do with web applications.  If you choose to use it in web applications, then you get additional functionality similar to Spring WebFlow.

I invite you to read the 102 page WebBeans book, and share with us exactly what it is that WebBeans can't do that Spring can.  I think you will find that WebBeans + EJB 3.1 offers a viable and full featured alternative to Spring. 

docs.jboss.org/webbeans/spec/PDR/pdf/Web%20Beans%2020081029.pdf

 

[quote=pulesen]

Don't forget that using POJOs in Spring with AOP, weaving, etc. is no more "POJO" than EJB 3.1 or WebBeans annotated POJOs

I am not sure exactly what you are getting at her!?

 [/quote]

Ok... lets have a look at the comments that caused me to write that:

[quote=pulesen]

What you can do with spring 2.5, load-time-weaving and injection into *all* POJOs, even JPA entities created by the ORM mapping tools or classes that are simply new'ed, you cannot do with EJB3.

[/quote]

Great, so can WebBeans. 

[quote=pulesen]

Much of the developer community is talking DDD or simply want to put even more power to the POJOs in their model. We want to be able to express our logical models better in code. And EJB3 still follows the "old" programming model, of a services and data-access layer, which kind-off leads to procedural code.

[/quote]

Spring still follows the "old" programming model of services and data-access layer, which kind of leads to procedural code.  Does that statement make any sense to you?  No, because it's up to how the developer chooses to write the code.   Like Spring, WebBeans gives you the ability to express your logical models in better code.  Add one or two annotations (or configs to XML) when you want container managed transactions, concurrency, timers, etc. Those features are provided by the EJB container.  

 

Reza Rahman replied on Mon, 2008/12/01 - 4:46pm in response to: Per Olesen

Per,

[quote=pulesen]What you can do with spring 2.5, load-time-weaving and injection into *all* POJOs, even JPA entities created by the ORM mapping tools or classes that are simply new'ed, you cannot do with EJB3.[/quote]

I think you are shoe-horning an argument here a little bit :-). Most domain objects *do not need DI services* in the first place. Please do keep in mind, JPA and it's predecessors is what enabled DDD, not Spring. It is a rather strange statement that EJB 3.0 doesn't support DDD.

Regards,

Reza

Per Olesen replied on Mon, 2008/12/01 - 4:50pm in response to:

Okay, I will try to address both Ryan and Reza here.

I guess I will need to have a look at the WebBeans spec again then. If you say that WebBeans can do all spring 2.5 can today with DI, then I will simply have to trust you on that. Now, JSR-299 is not done yet (but I see the public review finishes soon). It then needs to be implemented. Neither is JSR-316 even near finished. When finished sometime, it will then need to be implemented.

This article is about EJB3.1. Not Web Beans. I find it strange, that the EJB-spec, which should be enough to model the business logic in my application, will let another Web Beans spec take care of the real interesting DI abilities.

Please correct my if I am wrong, but when I say that I find EJB3 lacking, the answer is by pointing to another spec that purposedly is going to "fix" this.

Here is an except from the JSR-299 Web Beans description:

The goal of this work is to enable EJB 3.0 components to be used as JSF managed beans, unifying the two component models and enabling a considerable simplification to the programming model for web-based applications in Java.

 Web Beans might be usable to enable what I need, but its goal seems to be focused around simplifying EJB usage from JSF-based web applications.

Nevertheless, I need to look into Web Beans again.

Reza Rahman replied on Mon, 2008/12/01 - 5:14pm in response to: Per Olesen

Per,

First and foremost, it makes perfect sense to me to put DI in a completely separate spec. The point is that DI should *not* be specific to business component development. Also, the EJB spec has never been "self-contained", neither should it ever try to be.

Secondly, I think WebBeans implementations are strongly underway and targeted for Java EE 5 environments. I would venture to guess both the Red Hat and Apache implementations will be out by JavaOne next year. And yet again, if DI is the only concern, that can be met today in Java EE 5 systems through existing tools without much trouble at all.

I never take anything personally, I hope you don't either. It is just that some of what you are saying is really not correct/very lopsided.

Regards,

Reza

Per Olesen replied on Mon, 2008/12/01 - 5:18pm in response to: Reza Rahman

Most domain objects *do not need DI services* in the first place

I strongly disagree. The @Entity annotated classes are only part of the domain model. And these will need injection too. We haven't been able to until lately, and are still unable to with EJB3 alone. Most, if not all, ORM mapped classes in todays systems are simple data bearers, mapping to and from the db. They should be able to contain logic too. Logic that sometimes need access to more than what can be accessed through navigating the mapped model to the db. When the systems of today need to place some domain logic that they can't place on a ORM mapped class (where they would like to have had it actually), we invent some "service" class and place it there, as this can be transacted, injected, ... aka: Is a container managed bean.

JPA and it's predecessors is what enabled DDD, not Spring

Again, I disagree. If any, it was JPAs predecessors that enabled anything, JPA only standardized a subset. But in fact, neither ORM mapping tools nor EJB or spring is enabling DDD. We have always been able to do DDD. But not neccessarily following the programming model we would like.

I can access an EJB from a ORM mapped class by using Service Locator if I want to. But I dont. Cause I want the DI programming model.

Before LTW in spring, I could also use Service Locator to lookup a spring-managed bean myself from a ORM mapped class. But I didn't. Because I want DI programming model and not the "old" Service Locator of previous EJB standards.

Today, I can utilize a technical solution like LTW in spring to do DDD even more to the point, without compromising in the programming model I want to follow.

Reza Rahman replied on Mon, 2008/12/01 - 5:48pm in response to: Per Olesen

Per,

[quote=pulesen]But in fact, neither ORM mapping tools nor EJB or spring is enabling DDD. We have always been able to do DDD.[/quote]

Glad we are able to see eye-to-eye :-). "EJB doesn't support DDD" is just an old recycled argument that applied to EJB 2.x entity beans, not EJB 3 and JPA.

As I have said, I don't contend that non-managed component DI is a gap left in EJB 3.0. In fact, no matter what the practical need, it is unfortunnate that it was narrowly defeated at the time. That all being said, even that's being solidly addressed in Java EE 6/WebBeans 1.0/EJB 3.1.

If you have any other concerns that you think the EG should meet, definitely feel free to sound off :-).

Regards,

Reza

Reza Rahman replied on Mon, 2008/12/01 - 6:13pm in response to: Per Olesen

Per,

[quote=pulesen]Because again, I think the EJB expert group and EJB spec is beginning to lack behind, when compared to what the world wants.[/quote]

Just for the record, this is blatantly incorrect. Let alone the tremendous number of changes in Java EE 6, Java EE 5 had plenty of genuine innovation. The most prominent one has been sparing the developer community from XML hell via whole-hearted support of annotations (I even got the SpringSource leadership acknowldge this ;-)). Spring 2.5 has barely caught up in this department IMO :-).

Again, nothing personal - just pointing out a flaw in the statement :-).

Regards,

Reza

Meera Subbarao replied on Mon, 2008/12/01 - 6:22pm

I agree 100% Reza. While using EJB 3.0 and now with EJB 3.1, I haven't written a single line of XML. This is truly terrific. Even with the latest version of Spring, you have to write at least a few lines of XML.

Per Olesen replied on Tue, 2008/12/02 - 2:01am in response to: Reza Rahman

Reza, rest assured I am not taking this personal. We are just having a discussion, which is a good thing :-)

I also think we won't come to agree on these issues.

And I will look into Web Beans soon.

Martijn Verburg replied on Tue, 2008/12/02 - 6:49am in response to: Meera Subbarao

[quote=meera]I agree 100% Reza. While using EJB 3.0 and now with EJB 3.1, I haven't written a single line of XML. This is truly terrific. Even with the latest version of Spring, you have to write at least a few lines of XML.[/quote]

Writing XML vs Annotations is still a matter of personal preference I feel, it's good to have the choice.  I'm personally perhaps 'old fashioned' by I prefer a majority of my configuration to be in XML and not have 'Annotation source code with some Java sprinkled in between', of course YMMV :)

Bhaskar Karambelkar replied on Tue, 2008/12/02 - 6:06am

To add more fule to this interesting discussion,  here are my thoughts on the whole JEE v/s Spring issues.

 First and  foremeost , the JEE guys should stop touting JEE as the one true standard and shun every other alternative as non-standard. Last I heard Java is now completely open source. So to claim JEE specs and products related to it as standard, is like Redhat claiming that they are the "standard" Linux.

Frankly I don't give 2 cents about industry standards, I think the term is vastly overrated and I have seen so many examples of poor code, just in order to be "standards compliant". So the argument that, JEE specs are "standard  specs" may sell well to management, but won't fly with developer, especialy the ones who have been burned by J2EE.

 Secondly  even the hardcore JEE developers will agree that the JEE specs have not really innovated much, but borrowed ideas and extended them, from popular open source projects, that came in to existence merely to fill up the wide gaps that J2EE specs had. 

From the way I see it, Spring was developed with the intention of giving developers a lot of out-of-box usable components and the ability to integrate seamlessly with a whole bunch of 3rd party libraries/APIs/frameworks. While JEE looks like it is developed with the intention of creating "standards", and it doesn't do a good job even at that, by leaving a lot of desired feature-sets to the discretion of Vendors, and thus ensuring non-compatible vendor specific extensions to the JEE specs/APIs .

Secondly Spring fits very easily into the existing codebase, due to excellent support for various 3rd party APIs/frameworks, so introducing Spring in a legacy application is much easier than introducing JEE.

 To give some concrete examples, here are a few senarios comparing the Spring framework to JEE stack.

1) DI support.

Dependency Injection is not merely being able to inject beans in to one another, what matters is the flexibility to instanciate those dependencies as well as flexibility to inject those depenencies.

e.g. with Spring I can do DI via setter method, variable name, constructor argument , also managed beans can be instanciated using constructors, factories, static methods, JNDI look ups. With Spring 2.5's @Configurable, even unmanaged beans can be brought under the DI domain. Even if web-beans do support all of this (I don't know if it does, but I assume it does), why should I switch from Spring to web-beans ? What added values do web-beans provide that spring doesn't ?

2) Scheduling

EJB 3.1 has only timer based EJBs. While Spring supports quartz, JDK timer, and it's own Task executor, i.e. more choices, more flexibility.

3) Remoting

EJB 3/3.1 have remote interfaces, but Spring has RMI, Burlap/Hessian, HTTP invokers, not to mention the fact that on client side, spring can even talk with a remote EJB.

Can I inject a EJB in a remote client, merely by using EJB API ? NO.

But can I do it using Spring ? YES.

Secondly for remote EJBs, there are no standard client libraries, you have to use different libraries for different app. server vendor, at least with Spring, I can be sure that my client application will work, no mater where the target is located, be it a stand alone application, or running inside a servlet container/application server.

 4)  Messaging

MDBs are nice, but how about some help in the sending of Messages department. With Spring's JMSTemplate, sending JMS messages  is a matter of calling one method on the template object, while there is no such feature in EJB specs. So without spring, I have to open a connection, start a session , send a message, handle errors etc.

Also on the subscriber/receiver side, MDB's don't have retry logic like Spring's DefaultMessageListener, nor does it support automatic message transformation like Spring's MessageConverter.

 4) Web Services

No complaints here, both EJB 3.1 and Spring both have excellent support for JAX-WS, JAX-RPC, as well as the new kid on the block JAX-RS. 

5) AOP

No comparison here, Spring + AspectJ is SO SO SO much more powerful than anything the "JEE land" has to offer for AOP. Mind you I am not talking about using AOP to merely do DI, or tracing. AOP is is much more powerful and capable than that, and Spring makes using AOP a walk in the park.

With spring+AOP I can do some really powerful stuff, like weaving pre-compiled 3-rd party classes with my aspects, or weaving my classes with 3rd party aspects etc. JEE land is no where near to these feature sets.

 6) ORM/DAO support.

EJB 3.1 only supports JPA, while Spring out-of-box supports JPA, Hibernate, iBatis, and good old plain JDBC. This makes it much easier when working with legacy databases. JPA can be a nightmare when working with legacy databases. But with Spring + iBaits  or Spring + JDBC, it is really quite easy. And when you have the option of designing your domain model from ground up, you can go for the fancier Spring + JPA or Spring + hibernate stuff. In fact you can even have a combinataion of multiple ORM/JDBC in the same application and all managed seamless by Spring's excellent Transaction Manager.

7) Web tier,

EJB 3.1 can only be injected in servlets, or JSF managed beans, but Spring managed beans can be injected in Servlets, JSF Managed beans, Struts, Webworks, Tapestry, wicket, Spring web flow,  not to mention excellent support for various view technologies like JSP/JSTL, Tiles,Velocity, Framemaker, jasper reports etc. To use only EJBs in any of these view technologies/ web frameworks (besides JSF/Seam) is going back to the service locator pattern.

8) JMX

Spring's JMX annotations have even inspired the new JMX 2.0 annotation driven MBeans and MBean Server. But with spring I can bring the full DI feature set in to these MBeans, which is not possible with EJBs. EJBs can only be injected in other EJBs/Servlets remember!

 

One argument for EJB 3.1 is the removal of XML based configuration, well the same can be said for Spring. Although in Spring you can't completely get rid of the XML, Spring 2.5's annotation driven configuration, removes the need to define your beans in an XML. The application context merely serves as a bootstrap, with minimal  configuration,which I would argue, rightfully belongs in XML rather than in code.

 

EJB 3.1 and JEE 5/6 have come leaps and bounds compared to the mess that was J2EE, but it is still lacking out-of-box usable components that can ease the development process significantly. A lot of features are left for the vendors to implement , i.e. non portable code. With Spring I know that I am tied to a vendor, but the fact that Spring framework is open source, and can run in any enviroment, from a command line java application , to a Swing/SWT based RCP GUI, to a web or a J2EE/JEE application , makes me much more comfortable using Spring as opposed to JEE stack, as I don't have to worry about which features may or may not be suported by different J2EE/JEE products by different vendors.

 

Hope this detailed write up has provide the EJB/JEE team with some insight in to what exactly the developers are looking for and how there is still a dis-connect with respect to what the EJB/JEE stack delivers.

Meera Subbarao replied on Tue, 2008/12/02 - 7:31am in response to: Martijn Verburg

[quote=karianna]

Writing XML vs Annotations is still a matter of personal preference I feel, it's good to have the choice.  I'm personally perhaps 'old fashioned' by I prefer a majority of my configuration to be in XML and not have 'Annotation source code with some Java sprinkled in between', of course YMMV :)

[/quote]

Oh yes, I agree. No team should make a choice just based on XML to choose Spring or EJB. If you are writing enterprise Java applications, whether you like it or not, you will be writing and usingtons and tons of XML.

Meera Subbarao

Meera Subbarao replied on Tue, 2008/12/02 - 7:35am in response to: Bhaskar Karambelkar

[quote=vkbhaskar2.myopenid.com]

Hope this detailed write up has provide the EJB/JEE team with some insight in to what exactly the developers are looking for and how there is still a dis-connect with respect to what the EJB/JEE stack delivers. [/quote]

The comments are really interesting. I am gald I was able to see different perspectives from many of these comments.Most projects I have been and many clients I have worked with, have for some reason or other used EJB's. They do use Spring, but for just DI. 

Very good discussions. 

Meera Subbarao

David Sills replied on Tue, 2008/12/02 - 7:52am

Meera:

From your description, I can see that EJB 3.1 has indeed improved on 3.0.

As to the discussions about EJB vs. Spring, why does it have to be versus? I use both, even in the same project; each has its uses and downsides. There is no perfect software.

As to DDD, as I understand the concept (I may be wrong, of course) the idea is to decouple the domain model from specific implementation details. There is no requirement that entities be "luggage for data" that I read in the EJB spec. However, there is likely to be at least some logic that involves more than one entity and that cannot readily be parsed into one entity or another, so one doesn't always lose the need for a business layer, even with DDD. (Of course, if you're a fan of naked objects, that's another matter, but my own preference is for people-oriented software.) :-)

While not disagreeing with the points made in the JEE/Spring comparison, I wouldn't want something like the templates that Spring provides for so many things (database access, messaging, etc.) to be part of a specification. These are library functions that can be implemented in a dozen ways; Spring's great advantage is that it is first with many of them and sensibly designed. But it's not always perfect either (see above). Let a thousand flowers bloom!

The one point that I don't see above (again, I may have missed it) is the distinction between specification and software. EJB is whatever it is, but what it isn't is software. If you don't like JBoss, you can turn to an Oracle (either one) or Websphere or now a stand-alone container. There'll be some minor changes, but the process is reasonably painless. But if you don't like the implementation of something in Spring, to what alternatives can you turn that will involve as little alteration? Just a thought.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.