This week's book giveaway is in the Design forum.
We're giving away four copies of Building Microservices and have Sam Newman on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Distributed framework and EJBs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Building Microservices this week in the Design forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Distributed framework and EJBs" Watch "Distributed framework and EJBs" New topic

Distributed framework and EJBs

Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1183
My book says:

When a distributed framework is used, a client makes a call to what appears to be the interface of a business object. What it actually calls, however, is a stub that mimics the interface of that business object. This layer between clients and business objects is added because it is more practical to place stubs in the remote and distributed locations of clients than to place complete copies in the location of business objects.
In a distributed framework, the client calls a business method on a stub as if it were the real object. The stub then communicates this request to a tie. The tie calls the method on the real business object. A result is returned to the stub and the client.

I don't understand how this distributed framework concept relates to EJBs and the J2EE architecture in the 'regular' case in which the client tier presents HTML pages.

I can understand the distributed framework concept when the client tier is an application, but I feel that this is the exception.

So, over all, when the client tier is HTML, I think the EJB framework is just overly complex.

Any thoughts?


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Terry Mullett

Joined: Feb 21, 2003
Posts: 26
The problem is that the word "client" is overloaded. "Client" in the sense that you quote/paraphrase in the beginning is a relative term. Any object A calling a service on object B is a "client" (and B is a "server"). This is not to be confused with "client tier".

Is the EJB framework too complex? Depends on the overall complexity of your application. Managing concurrency, transactions, security, and (as your lead-in suggests) distribution transparency is also complex if you try to build it from scratch. EJB could be a complexity bargain if you need those things. If not, it could be a boat anchor. And that's what you, as an architect, would decide -- case by case.

Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1183
Thanks Terry!
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1183
Good Day,

I'm looking at a definition of the Client-Server Paradigm and it looks very similar to the distributed framework definition.
What makes the distributed framework stand out?

Client-Server Paradigm
- Computers in a network that �provide services� to other computers in the network are called servers; computers that requests and enjoy their services are called clients
- In most cases, server applications wait passively for client applications to initiate communication

I agree. Here's the link:
subject: Distributed framework and EJBs
It's not a secret anymore!