Java EE 7 Platform and Web Application Architecture
Domain 1 asks you to place a requirement in the correct profile, container and packaging unit rather than to write code. Expect questions on which APIs ship in the Web Profile versus the Full Platform, which descriptor or annotation wins, and how JNDI and class loading resolve at runtime.
Profiles
- Java EE 7 (JSR 342) defines the Web Profile and the Full Platform; both include Servlet 3.1, JSP 2.3, EL 3.0, JSF 2.2, CDI 1.1, EJB 3.2 Lite, JPA 2.1, JTA 1.2, Bean Validation 1.1, JAX-RS 2.0, WebSocket 1.0 and JSON-P 1.0.
- The Full Platform adds JMS 2.0, JAX-WS 2.2, Batch 1.0, Concurrency Utilities 1.0, JCA 1.7, JavaMail and JASPIC. Any requirement needing timers, message-driven beans or SOAP endpoints forces the Full Platform.
Packaging and resolution
- A WAR holds web components with classes in WEB-INF/classes and jars in WEB-INF/lib; an EJB JAR holds enterprise beans; an EAR aggregates modules and exposes EAR/lib to all of them.
- Class loading is parent-first; a WAR cannot see a sibling module unless the jar sits in EAR/lib or the WAR manifest names it.
- web.xml overrides annotations, and metadata-complete=true disables annotation scanning entirely.
- JNDI scopes run from java:comp through java:module and java:app to java:global.
Worked example
A design needs a nightly timer, a JMS queue consumer and a SOAP endpoint. @Schedule, @MessageDriven and @WebService all fall outside EJB 3.2 Lite and outside the Web Profile, so the answer is a single EAR on the Full Platform: a WAR for the servlet front end, an EJB JAR for the timer bean and MDB, and JMS administered objects declared with @JMSDestinationDefinition.
Traps
- Claiming the Web Profile supports JMS or JAX-WS.
- Forgetting that metadata-complete=true stops annotation processing.
- Copying a library into one WAR's WEB-INF/lib and expecting sibling modules to resolve it.