@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.
Web Apps, SPA, PWA with vanilla Java Script (ES 6+), CSS 3 and WebStandards only. As simple as possible, but not simpler. See you at: (Progressive) Web apps, Single Page Apps and WebStandards airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.