adam bien's blog

Implementing both: @Local and @Remote EJB interfaces at the same time is a pragmatic approach to separate coarse grained public, from finer "private" views.

With the introduction of Java EE 6 in 2009, the WAR replaced the EAR with the following implications:

1. Server side frameworks like e.g. JSF (if used) and the business logic are residing in the same WAR.
2. REST resources are accessing boundaries (EJBs) locally.
3. WARs do not require any further modularization. JARs within WARs are more an exception than a rule.

1. High level, REST APIs are the portable way for HTML 5 and native mobile clients integration.
2. WARs are the new modules. There is no binary dependencies (=shared JARs) between WARs. RMI-IIOP communication (@Remote) relies on serialization and introduces binary coupling.
3. REST endpoints are used to communicate between WARs aka microservices.
4. Remote CORBA clients are getting less and less popular.
5. Remote communication requires serialization, what introduces security risks.
6. Remote communication with an application server usually requires the distribution of a proprietary Java library.

REST interfaces effectively replaced binary @Remote EJB communication.

With Java EE 6 all public methods of an EJB class comprise the default "public view" of an EJB. This "conventional, virtual interface" introduced with Java EE 6 makes the @Local interfaces effectively superfluous.

From Java EE 6+ design point of view @Local and @Remote interfaces became deprecated. Actually all interfaces with a single implementation should be considered as, at least, suspicious. Interface-less EJBs remain the perfect boundary.

This post was inspired by a question in the 27th airhacks.tv.

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.