Distributed Objects in EJB(Enterprise Java Beans) - Explicit vs Implicit Middleware

Last Updated : 16 Dec, 2021

A distributed object is an object that is callable from a remote system. An in-process client, an out-process client, or an elsewhere located client (on a network) can call it. The following figure shows how a client can call a distributed object.

Stub is a client-side proxy object. It masks the network communications from the client. Using the sockets, messaging parameters, the stub can call over the network.

Skeleton is a server-side proxy. It masks the network communications from the distributed object. Skeleton is responsible to receive calls on a socket & it knows how to do it. It knows how to message parameters from their network representations to their Java representations.

Steps involved in calling a distributed object from the client-side are as follows:

The client calls a stub.
The Stub calls over a network to a skeleton.
The skeleton then delegates the call to the appropriate implementation object. After completing the work, this object returns the control to the skeleton, which returns to the stub & which then returns control back to the client.

Note: Both stub & server-side implementation object must implement the same interface which is called remote interface.

This implies that cloning of the distributed Object's signature is done by the stub. The client here thinks that he is calling the distributed object directly, but actually, he calls a method on the stub. Thus, we can conclude that the distribution object is an abstraction that is created by the cooperation between the stub, skeleton & implementation objects. No single entity here is the distributed object.

Middleware services: Middleware services such as transactions & security are needed as the distributed Object's application gets larger. There are 2 ways to get it:

Explicit Middleware where we are getting middleware explicitly
Implicit Middleware where we are getting middleware implicitly

Explicit Middleware: You can purchase the middleware & write the code that calls the middleware's API. Such a process was used by traditional distributed object programming(such as CORBA).

Example: You could gain transactions by writing to a transaction API as shown :

transferAmount(Account acc1, Account acc2, long amount)
{
    // 1. Call middleware API to perform a security check
    // 2. Call middleware API to start a transaction
    // 3. Call middleware API to load rows from the database.
    // 4. Subtract the balance from one account(acc1), add to the other(acc2)
    // 5. Call middleware API to store updated rows in the database
    // 6. // 1. Call middleware API to end the transaction
}

Output explanation:

Here transferAmount() is a method that takes 3 input parameters acc1 of Account type, acc2 of Account type & amount of long type. This method is called to transfer the amount from acc1 to acc2.

Example: One can think of Account as a class here whose each object refers to different account numbers.

Here, business logic is intertwined with the logic to call the middleware APIs.

Implicit Middleware is where without writing to middleware APIs, you can harness complex middleware in your enterprise applications. One needs to follow these steps to harness the power of middleware as shown in the figure below

Procedure: The steps are as follows:

Do not write to complex middleware APIs, write the distributed object to contain only business logic.
In a separate descriptor file, such as a plain text file, declare middleware services that your object needs. Example: You can declare that you need transactions, security & persistence checks.
Middleware vendor provides you command-line tool, run that. This tool takes your descriptor file as input & generates an object. We call that object a request interceptor.
The client's requests are incepted by the request interceptor. It then performs the middleware that your distributed object needs & delegate the call to the distributed object

Example: The code that would run inside distributed object is:

transferAmount(Account acc1, Account acc2, long amount){
// 1. subtract the amount from the balance of acc1 & add amount to balance of acc2
}

Differences between Explicit & Implicit Middleware are shown below in a tabular format

Explicit Middleware	Implicit Middleware
Here, business logic is intertwined with the logic to call the middleware APIs.	Do not write to complex middleware APIs, write the distributed object to contain only business logic.
Difficult to maintain: Need to rewrite your code if you want to change the way you do middleware.	Easy to maintain: No need to rewrite your code if you want to change the way you do middleware.
Difficult to write: To perform simple operations, it requires a large amount of code.	Easy to write: No need to write any code to middleware APIs, just declare what you need in the descriptor file
Difficult to support: The customers cannot change their middleware( such as changing how security works)	Difficult to support: The customers can change the middleware they need by tweaking the descriptor file.
No descriptor file is required here.	We need to write a separate descriptor file.
Request interceptor is not required.	Request interceptor is required.