@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:
- Server side frameworks like e.g. JSF (if used) and the business logic are residing in the same WAR.
- REST resources are accessing boundaries (EJBs) locally.
- WARs do not require any further modularization. JARs within WARs are more an exception than a rule.
- High level, REST APIs are the portable way for HTML 5 and native mobile clients integration.
- 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.
- REST endpoints are used to communicate between WARs aka microservices.
- Remote CORBA clients are getting less and less popular.
- Remote communication requires serialization, what introduces security risks.
- 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
@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.
NEW MUC Airport Workshop: Migrating Java Client (Swing / Java FX) to Web Standards