Adam Bien's Weblog

Are @Local and @Remote EJB Interfaces Deprecated?

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.
Also the landscape changed. HTML 5, native clients and microservices became the standard which further influenced the application design:
  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.


NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.

Newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

Hi Adam,
Thanks for following up. I'm locked in behind corp firewall when your show is on and can't watch it live and reply. I don't disagree with what your saying, but I'm stuck with a legacy java client.
My question was really how interface inheritance works. If I declare

@Remote
public interface RemoteDuke {
String hiDuke();
}

@Local interface LocalDuke extends RemoteDuke {
}

@Inject
LocalDuke duke;

public void sayHello() {
duke.hiDuke(); // Will this call be local or remote?
}

Posted by retepnemsi on June 08, 2016 at 10:55 PM CEST #

Well even if someone stuck with Java2EE 1.4 specs there is no real reason to keep Local interfaces.

Most of app containers has a custom flag to treat remote interfaces using pass-by-reference when the caller is in the same EAR/WAR as the service. It adds minimal runtime overhead when compared to using local interfaces, but this overhead is constant (a few microseconds per call) and does not depend on the length of the passed arguments (as there is no serialization).

Posted by Laszlo Kishalmi on June 10, 2016 at 03:21 PM CEST #

Thanks, nice post

Posted by Binh Thanh Nguyen on June 14, 2016 at 06:09 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
Online Workshops
...the last 150 posts
...the last 10 comments
License