Ejb's - when to use Remote and/or local interfaces?

java

remote-interfaces

ejb-design

scalability

byNikita Barsukov·Feb 6, 2025

@Local interfaces – best for EJB and clients cohabiting within the same JVM; known for its efficiency and pass-by-reference attribute. On the contrary, @Remote EJB interfaces are excellent when interfacing with external clients across a network due to its secure data serialization.

Key Ideas:

Local: Intra-app communication on a diet.
Remote: Inter-app interaction on a spin class.

Snippet:

@Local // Like your coffee machine. Fast, in the same JVM
public interface MyLocal { /* ... */ }

@Remote // Like your pizza delivery. Across the city, but totally worth it
public interface MyRemote { /* ... */ }

Summing up, local for efficiency and speed, remote for flexibility and availability across borders. Just remember, speed comes with staying local, while remote is your ticket to scalability, albeit at a performance cost.

From Local to the Unknown: Evolving to Remote

Realize that as your application expands, so might your need for scaling up. Therefore, begin with local interfaces for the simplicity they bring and use remote interfaces when your application's scaling needs demand it. Keep an eye on the traffic patterns and performance measures to guide your transition.

Cluster? More like Clustering!

In the context of Java EE, clustering doesn't always equate to distributing components across JVMs. Depending on your configuration, if your EJBs have to be on multiple nodes for high availability or failover, remote interfaces become necessary. So, use clustering wisely and remember, @Remote doesn't always mean crossing server boundaries.

Designing for the Future

Design your EJB methods with "remote" semantics upfront to allow for a smoother transition to remote if it becomes necessary. Keep in mind to avoid coupling and maintain abstraction levels for future reconfiguration without much code rewriting.

Annotations and the Defaults

@Remote designates the remote access interfaces.
Conversely, @Local denotes interfaces meant for local usage within the same application.
If no annotation is used, it implies local by default but always aim for being explicit for clarity and maintainability.

Interface Types vs Performance

The interface types you choose could greatly impact the your performance metrics. When traffic between your EJBs and clients is significantly high, local interfaces can help reduce overhead and speed up interactions. On the other hand, for lower traffic volumes or less concern over network latency, remote interfaces' broader reach and flexibility might be more appealing.

Semantics Matter

The semantic differences in local and remote interfaces can be paramount. Paying heed to transaction boundaries, security contexts, and the data marshalling/unmarshalling overhead when deciding to use remote interfaces is crucial. For EJBs that are integrated tightly, and communicate frequently within the same application, local interfaces should be the go-to.

Transition with IoC

In contemporary architectures, IoC (Inversion of Control) containers such as Spring can simplify transitions between local and remote interfaces. They provide the buffer or abstraction needed to keep your application's business logic from being knotted up with EJB interface types, thus making transitioning a breeze.

Practical Applications

Starting a new project:

Identify your application's scope (intra- or inter-JVM), future scalability requirements and EJB-to-client communication patterns
Implement @Local for in-app EJB-to-EJB communication and @Remote, when the EJB's calls transcend JVM boundaries
Evolve: As your app begins to outreach JVM boundaries or needs a distributed deployment, you can refactor your interfaces to use @Remote.