• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

Distributed framework and EJBs

 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

Thanks,
Dan
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Cheers,
Terry
SCEA/SCBCD/SCWCD/SCJP
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Terry!
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

http://www.soe.ucsc.edu/classes/cmpe080n/Fall03/LAN.pdf

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



Thanks,
Dan
 
Won't you be my neighbor? - Fred Rogers. tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic