Java EE or Spring Framework – Rule #5

I came across a Java EE / Spring Framework post on DZone the other day.

It wasn’t the first, and it won’t be the last.

I want to get in the ring, but first we need some rules.

Rule #4 – Modular Java EE Application Servers

J2EE to Java EE, Monolithic to Modular

J2EE is a mess. The configuration is complicated. The API is complicated. EJB 2 is overly complex, and it defines J2EE.

I had to purchase Head First EJB.

J2EE implementations are provided via monolithic application servers.


Java EE rises from the ashes of J2EE. The configuration is simple. The API is simple. EJB 3 is simple, and it does NOT define Java EE.

Java EE 5 includes JAX-WS, JAXB, JPA, and more. However, it does not include dependency injection. I, myself, want JAX-RS.

JBoss takes steps towards a modular application server with JBoss EAP 5 and the JBoss Microcontainer kernel. JBoss EAP 5 allows administrators and / or developers to enable or disable individual features.


Java EE continues to evolve. The configuration is simpler. The API is simpler. EJB 3 is simpler.

Java EE 6 includes JAX-WS, JAXB, JPA, JAX-RS (finally), CDI / DI, Bean Validation, Interceptors, and more.

JBoss releases a modular application server with JBoss EAP 6 and the JBoss Modular Service Container (MSC) kernel.

Modular v Modular

Spring Framework is a modular implementation. An application includes only those modules that provide the features that it requires. For example, with Maven.

Java EE is a modular API. However, applications do not include the implementation. This can lead to the assumption that a) Java EE implementations are NOT modular and b) application servers make every single Java EE technology available to the application regardless of whether or not it requires them. This is a valid assumption for monolithic application servers. However, it is NOT a valid assumption for modular application servers. A modular application server makes available only those Java EE technologies that provide the features that the application requires. It’s like the application server is executing Maven when the application is deployed.

JBoss EAP 6 makes Java EE technologies available via services. When an application is deployed, it scans the application to determine what services are required and thus need to be started. For example, if a persistence.xml file is found it will start the JPA service. These services are configured as subsystems via extensions. The only difference between the web profile and the full profile is the subsystems that are configured. For example, the full profile includes configuration for the messaging (JMS) subsystem whereas the web profile does not.

jboss_eap_arch

The following presentations do a great job of introducing the architecture behind JBoss EAP 6 (JBoss AS 7):

  • JBoss AS7 Reloaded (link)
  • What makes JBoss AS7 tick? (link)

And this is a great document introducing the JBoss EAP 6 (JBoss AS 7) internal architecture and boot processs:

AS 7 Internal Architecture Overview (link)

Feel free to suggest a rule via comments or Twitter (@jboss_tm).


Thin Crust or Deep Dish

Deep Dish. I live in Chicago.

About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 115 other followers

%d bloggers like this: