Fernando Lozano's Blog: Community: Java Specification Requests Archives

While everyone praises EJB 3.0 ease of use through annotations and the new POJO persistence model, a ring bells in my head that this new spec could lead to even higher ties to app-servers than previous releases.

The idea of using source-code annotations to replace deployment descriptors is not new. XDoclet did this for years, and it was the preferred tool by EJB 3.0 main drivers, the JBoss Group. But XDoclet allowed for misuses of its capabilities that were replicated by the current EJB 3.0 drafts. These are the specification of app-server dependent configurations on the EJB source code.

The Java platform is about compatibility and interoperability, but the J2EE platform have failed so far on this respect because their standards were not always complete enough to let the app developer do this job without interference from the app deployer. An example of this was the absence of a standard for OO/Relational mapping, but this is being solved by the EJB 3.0 spec.

See this fample from JBoss EJB 3.0 Preview docs: http://docs.jboss.org/ejb3/tutorial/security/src/org/jboss/tutorial

@Stateless
@SecurityDomain("other")
public class CalculatorBean implements Calculator
{
@Unchecked
@TransactionAttribute(TransactionAttributeType.REQUIRESNEW)
public int add(int x, int y)
{
return x + y;
}

The @Stateless, @Unchecked ad @TransactionAttribute annotations are fine. I agree these aspects are deeply affected by business logic so it's easier to deal with then using only one source file instead of two (the bean class and the deployment descriptor). But the annotation @SecurityDomain is not fine: this references a JBoss-specific feature, the use of JAAS-based application policies to configure a security realm. If I want to deploy this EJB using another app server, this won't work at all or this will become noop, just trash inside the class files.

If you take a deeper look at this, why the app developer should worry about application policies? Shouldn't this be the sole concert of the app deployer, or the app server administrator? See that if the app deployer want's to use another policy (say he has just configured the use of LDAP for authentication) he'd have to recompile the source code. Your QA department won't be happy with this.

Another example of misuses of EJB 3.0 capabilities come from the persistence example:

@Entity
@Table(name = "PURCHASE_ORDER")
public class Order implements java.io.Serializable
{

It looks pretty harmless until you talk to your DBA. Why should my persistent object specify the table name? Reading on the example (left out because of space), why should it specify the way relationships are implemented (foreign key, join table) and the look ahead strategy for loading related data? Shouldn't this be left for the DBA to decide, and not the app developer?

If the DBA, after some benchmarks, finds another way to map the relationships will yield better performance, or another read ahead strategy prove better given the current usage pattern of the application, he'll have to recompile all Java sources to effect the changes. I don't expect my DBA to be a senior Java programmer, and I also don't expect my Java programmers to be able to take the DBA job, so should one have to change the artifacts created by the other?

This was about performance. But about portability, the current spec and samples define the SQL column type as an annotation on the Java getter. If I use Oracle, a String property becomes a VARCHAR2 column. But this really matters to the developer, who could well be using MySQL? What about many ERP and CRM systems out there, which have to support whatever database the customer does have? Will they have to provide different binaries (ejb3 or ear) for each supported database? A new port should require recompiling Java sources? Wasn't persistence frameworks about database independence?

The current EJB 3.0 drafts encourages developers to write EJBs that are very dependent on the app server and database used and not portable without changing sources and recompiling. Previous releases, if they did not get real portability because they did not defined important things, allowed the app deployer, DBA and others to adapt the application to new environments without touching Java code, but only deployment descriptors. And in this respect the proprietary deployment descriptors most J2EE app servers require are a good thing: just one new / changed file for each new supported app server. Not many changed Java classes for each server. So the new release is a step backwards as along as a step ahead in ease of use.

I am very worried because the EJB 3.0 specs treats deployment descriptors as useful just for backward compatibility. The syntax is not even described on the latest drafts, although they say something about the descriptor overriding what was specified by source code annotations. If this is left for late including on the specs, we may get a deployment descriptor that's not useful at all.

So, please, EJB 3.0 EC members, take a careful look at this. I don't want to use annotations for everything. I don't think deployment descriptors are a bad thing that should be taken out of J2EE development. I want to use they as the main source of info about security policies and OO/Relational mapping for my EJBs. I want my app developers to work without interfering with app deployers, DBAs and infrastructure administrators, and vice-versa. I want to be able to fine-tune for performance without recompiling Java sources. The only way to do this is having deployment descriptors.

Of course, deployment descriptors needs a simpler, more concise and consistent syntax. There's much room for improvement here, and much to gain.

J2EE developers, beware: many people on the EJB 3.0 EC do work for app server vendors. They won't be hurt if you cannot easily migrate your EJBs from one server to another. That's not to say they will consiously produce a spec that generates non-portable EJBs, but they have a big pressure to offer ease of use to their customers and will easily forget about portability issues.

Don't be fooled by the simplicity of “hello, world” examples, they won't scale to full corporate Information Systems. Everything you may hate today about EJBs was created for a reason, and these reasons may still be valid. Please remember the mess that was created by “source code only” compatibility on Unix standards.

Making an analogy among the current EJB drafts and web development, the url-mapping for Servlet classes would be a source-code annotation. If you do not like the standard “*.do” pattern for Struts actions, you'd have to recompile Struts itself. Would Struts become such a widely deployed and successful MVC framework if it were not the flexibility of web application deployment descriptors?

Powered by
Movable Type 3.01D

java.net RSS Feeds