• 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
  • Tim Cooke
  • paul wheaton
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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
 
I was born with webbed fish toes. This tiny ad is my only friend:
Clean our rivers and oceans from home
https://www.kickstarter.com/projects/paulwheaton/willow-feeders
reply
    Bookmark Topic Watch Topic
  • New Topic