EJB Clients and Remote Objects

A remote object is an object that can have messages sent to its methods from a client across a network. For the remote object to be useful, those methods must provide some useful service.
An example of a remote object could be a BankAccount or a ShoppingCart. A BankAccount object might have methods such as:

1. public void credit(amount)
2. public void debit(amount)
3. public amount getBalance()

This would allow a client to deposit money to an account, withdraw it, and get the balance.
(In practice, there would be other methods that are ignored here for clarity.)

• Clients depend on Remote Objects
  The client can be another object or program somewhere out on the network. The client is dependent on the services provided by the remote object, but the remote object does not necessarily know who its client is or where that client is actually located.
  This is similar to when you go to a store: if you pay cash, no one needs to know who you are, but if you pay by check, the clerk will want more information.

From a security perspective, the remote object may want to know much more about its client. Most distributed environments provide the hooks for the remote object to acquire this type of information.

1. Remote object','An object that provides a service through its methods and is located on another host on the network. The location of the object needs to be known before its methods can be called.
2. Object semantics:The term implies that the objects have typical behavior as implemented in programming languages such as Java, C++ and SmallTalk.

• Remote Objects wait for Clients
  The remote object waits for messages that arrive from a client. It processes the message and then returns any data or simply an acknowledgment to the client. If the remote object is not waiting for a message, the client will not be able to send a message to the remote object. The analogy is that, if the gas station is not open, you can go there but you will not get service.
  Messages are sent to remote objects using object semantics. For example, if the client needs to get the balance from the BankAccount object, it generates a message that effectively invokes

balance = act101.getBalance()

, assuming the remote object is named "act101".

In Java EE 8, the paradigm for building distributed applications and accessing business logic has shifted away from the direct use of EJB Clients and remote objects in the traditional J2EE sense. The new approach emphasizes looser coupling, standard web protocols, and a more integrated development experience. Here's how the legacy mechanisms have been largely replaced:

1. Shift Towards Web Services and REST (JAX-RS):
   • Legacy Approach: J2EE often relied on tightly coupled remote interfaces defined by EJBs and accessed via RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol). This required specific client-side stubs and knowledge of the EJB implementation details.
   • Java EE 8 Paradigm: The preferred approach is to expose business logic through RESTful web services using JAX-RS (Java API for RESTful Web Services).
     • EJBs or other backend components can be easily exposed as RESTful resources.
     • Clients interact with these services using standard HTTP methods (GET, POST, PUT, DELETE) and data formats like JSON or XML.
     • This promotes interoperability across different platforms and technologies, as clients don't need to be Java-based or have specific EJB client libraries.
     • JAX-RS simplifies the development of service endpoints through annotations.
2. Embrace of Contexts and Dependency Injection (CDI):
   • Legacy Approach: EJB clients often involved JNDI (Java Naming and Directory Interface) lookups to obtain references to remote objects and Home interfaces for managing EJB lifecycle.
   • Java EE 8 Paradigm: CDI (Contexts and Dependency Injection) plays a central role in managing components and their dependencies.
     • EJBs and other managed beans (including those exposed via JAX-RS) can be easily injected into client components (servlets, other EJBs, JAX-RS resources) using the @Inject annotation.
     • This eliminates the need for manual JNDI lookups and reduces coupling between components.
     • CDI provides a unified dependency injection mechanism across the Java EE platform.
3. Simplified EJB Development:
   • Legacy Approach: Earlier EJB versions (pre-EJB 3.0) required verbose interface definitions (Home and Remote) and deployment descriptors.
   • Java EE 8 Paradigm: EJB development has been significantly simplified through annotations:
     • Annotations like @Stateless, @Stateful, and @Singleton directly on the bean class define their type and lifecycle.
     • The need for separate Home and Remote interfaces is reduced, especially with the focus on web service interfaces.
     • No-interface view: EJBs can expose their public methods directly as local business methods without requiring a separate interface, further simplifying local client access (though remote access typically still benefits from a defined interface, often a web service contract).
4. Focus on Standard Protocols:
   • Legacy Approach: RMI-IIOP, while standardized, was a Java-specific protocol for remote communication.
   • Java EE 8 Paradigm: The emphasis on HTTP and standard data formats (JSON, XML) for communication through JAX-RS promotes wider interoperability and aligns with modern web architectures.

In essence, Java EE 8 promotes a more decoupled, web-centric approach to building distributed applications. Instead of direct, tightly coupled interaction with remote EJB objects, the paradigm has shifted towards:

• Exposing business functionality as coarse-grained RESTful services.
• Using CDI for managing and injecting dependencies between components, including those that implement and consume these services.
• Leveraging simplified EJB development with annotations.
• Communicating over standard web protocols like HTTP.

This new paradigm leads to more maintainable, scalable, and interoperable applications compared to the more tightly coupled EJB client and remote object approach of legacy J2EE. While EJBs still exist and are crucial for transactional and concurrent business logic, their interaction with external clients and other tiers within the application has largely moved towards these modern, web-friendly patterns.

If you want a more complete discussion of the principles described in this lesson, please refer to the great book Essential Guide to Object Monitors. Now is the time to learn more about Enterprise Java Beans. In the next lesson, you will be introduced to the mechanism used when a client accesses a remote object.