Brian writes:
>
>CORBA perhaps has the advantage that it doesn't seduce you into
exposing your
>fine grained objects to direct remote integration.
Please explain.
EJB encourages one to expose components as fine grained remotable objects,
by making domain objects (enity beans) directly remote.
One could do the same thing with CORBA, but there is no entity bean like
framework which would encourage one to expose fine grained business objects
remotely as a matter of course.
Any reasonable scale projects that have been successful with CORBA, have
treated remote objects as with a coarse grained "service" orientation. These
services
typically act as a facade to a fine grained object model running on the
server, which is
in turn mapped to an RDBMS, or directly persisted in a OODB (for those that
have the luxury). So CORBA clients that invoke on these service objects
(which
are remotable CORBA objects) typically pass as arguments and receive
as return values shallow copies of object state from the underlying business
objects, using IDL structs and sequences to build them up.
* Historical Perspective, warning: some vendor plugs here *
Our flagship GemStone/Smalltalk server provides a totally transparent
client/server
partitioning capability. One's object model can be transparently replicated
to
the client, and changes to objects are flushed to the server automatically.
The client programmer can be operating on a local copy or remote object
and remain oblivious. This is a super easy to use programming environment,
but seduces developers in these issues:
- Typically a long transaction model, ties up server resources
- Lots of network traffic
- Performs well on a small scale, but doesn't scale up
Over the years we have done zillions of customer engagements to tune
applications that were constructed niavely based on this product capability.
We'd like to blame the customer here, but the fact is that the tool seduced
them into thinking they were getting away with something. We found that
for customers to be succesful with this tool, they had to take more direct
control of what flowed back and forth over the network, and usually had
to move to shorter transaction models.
If we look at client/server SQL, it suffers from the same issues. Typically
larger scale implementations move to stored procedures or tp monitors
to move the fine grained interactions off the clients on onto the server.
My concern is that EJB suffers from the same issue. It provides perceived
ease
of use in remoting of fine grained components, and seduces the practitioner
into a design that won't scale up. EJB is cool, but it's no panacea.
Practioners
must take responsibility in the area of client/server partitioning. Luckily
we have lots of experience here, and are developing intellectual property
(patterns and such) to help our customers through the issues. Products
are one thing, but expertise is priceless.
At the risk of pi??ing off Sun, the network ain't the computer yet. When
bandwidth is virtually unlimited, and server resources approach infinity,
the game will change.
Regards,
-Chris.
> -----Original Message-----
> From: Brian N. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 05, 1999 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Granularity of EJBObjects
>
> Chris Raber <[EMAIL PROTECTED]> wrote:
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
