Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!gatech!news.emf.net!overload.lbl.gov!lll-winken.llnl.gov!osi-east2.es.net!cronkite.nersc.gov!qiclab.scn.rain.com!slc.com!servio!servio!marcs
From: marcs@slc.com (Marc San Soucie)
Subject: Re: The role of Smalltalk on a Server
Message-ID: <marcs.821055386@servio>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <4ce8nh$rdp@locutus.rchland.ibm.com> <30EACE66.5D8A@bridge.bellsouth.com> <gollmann-0401961018270001@go.edvz.tuwien.ac.at> <4cjvhv$10ap@locutus.rchland.ibm.com>
Date:  7 Jan 96 22:56:26 GMT
Lines: 65

mikej@justv.rchland.ibm.com (Michael Jacobs) writes:

gollmann@edvz.tuwien.ac.at (Georg Gollmann) writes:

|> <faisal.waris@bridge.bellsouth.com> wrote:
|> 
|> > I think there is a definite need for Smalltalk server apps. There may be
|> > a blurred 
|> > boundry between active OODBMS like Gemstone and Smalltalk servers that may 
|> > be distinguished by factors such as cost, performance, concurrency,
|> > persistent object size, etc.

|> The boundary is definitely blurred (or not existent at all). GemStone is
|> called an "object application server" which sums it up very nicely.

|> > Also OODBMS lack certain capabilities which can be supplemented via Smalltalk 
|> > servers. For example, PPD's VisualWave deploys Smalltalk severs to support 
|> > web apps. This is not currently possible with OODBMS (As far as I know.
|> > I know Oracle and Next have some support).

|> Not true. See <http://ftp.tuwien.ac.at/~go/Implementation.html> for a
|> description of my GemStone WWW Gateway which is written entirely in
|> SmalltalkDB.


> These two examples (data propagation and WWW request server) are interesting.
> 
> [Q] How are simultaneous requests handled? For example, are the requests
> serialized and then handled by a single copy of your application or are you
> forking a process running the same application or ?? The reason I am asking
> is to understand how existing server Smalltalk applications scale. Various
> approaches could be taken with available products (VW, GemStone,
> distributed Smalltalk,...) but my impression is that today's experience has
> been that the scale of these approachs tend to saturation in the 10's of
> simultaneous users.

The number of users that can run an application concurrently in a given
system configuration is of course dependent on the nature of the
application, data access and transaction rates, expected response times,
and so on. But GemStone-based systems are scaling up over 1000 users these
days.


> The 'fat client' approach can be appropriate for many applications. Because
> of the heritage of the relation database it becomes the mechanism for data
> security, concurrency, transactions, etc. The performance of the 'fat
> client' approach often suffers because of the sheer size of the image and
> the time it takes to map objects to/from the RDB (and in some cases
> translating data representation differences between the client and the
> server). It seems that some of these problems could be solved if some of
> the domain objects could be closer to the RDB.

This is one of the primary problem spaces addressed by GemStone. GemStone
allows the developer to move much of the data-intensive processing out of
the clients and into shared classes and methods running on a middle-tier
server. Clients receive service from GemStone in the form of objects, which
may well be proxies for data actually managed by an RDB or other data
server. The clients can be smaller and nimbler, GemStone can support the 
high-volume objects and shared business logic, and the data servers manage 
high-volume non-object data. And yes, this scales well beyond 10 users.

    Marc San Soucie
    GemStone Systems, Inc.
    Beaverton, Oregon
    marcs@gemstone.com
