Distributed Objects for Internet Architecture

Mark Madsen (msm@ansa.co.uk)
Tue, 11 Jul 95 17:35:09 BST


From: Mark Madsen <msm@ansa.co.uk>
Message-Id: <9507111635.AA29049@euclid.ansa.co.uk>
Subject: Distributed Objects for Internet Architecture
To: rdaniel@acl.lanl.gov
Date: Tue, 11 Jul 95 17:35:09 BST
Cc: msm@ansa.co.uk, sollins@lcs.mit.edu, uri@bunyip.com
In-Reply-To: <9507110932.ZM28027@idaknow.acl.lanl.gov>; from "Ronald E. Daniel" at Jul 11, 95 9:32 am

Hi Ron, Karen.

Ron Daniel wrote:

> ...basing an Internet object model on CORBA is a good start. In
> discussions with Karen Sollins, she indicated that there were
> particular things CORBA could not do that she thought would be very
> important. One was dynamic mods to objects - add a method without
> bringing the service down. I have not thought about trying to do
> such things, but perhpas you will have insights on that.

To take your points in order: at the very least, any object model we
decide on must fit in with the way that CORBA works, because that is
the way that most of the commercial world is going - not only the
companies mentioned by Rich Salz earlier, but also the telcos.

I'm glad to hear that Karen is also thinking about how to get objects
to work for us.  While I don't wish to claim to be particularly
insightful as far as objects are concerned, I don't think that Karen's
objection applies only to CORBA.  It will be a problem for every
object model.  But then, the problem arises because of the provision
of services, so it actually is a problem for any systemmthat offers
services, regardless of whether it uses objects or not.

Now that we have that point clear, let's see how it could work in a
gedanken experiment.

Object A inserts a service reference AS1 to its service interface S1
in the interface repository of O1, which is an ORB.  O1 cheerfully
passes the ifref to all clients requesting a service of that type.

The owner of object A upgrades its definition to a new version, and
instantiates a new object B, with a new service interface S2.  B
inserts a service reference BS1 into the interface repository of O1.
O1 cheerfully continues to pass the ifref for AS1 to all clients
requesting a service of that type.

The object owner shuts A down.

Clients attempting to bind to AS1, whether existing clients or new
ones just getting the ifref for AS1 from the ORB, all experience
failure.  THIS FAILURE IS THE SAME AS IS EXPERIENCED WHENEVER ANY
SERVICE FAILS.

Clients now request a new ifref from O1, and end up happily bound to
BS1, which works fine for them.  Clients that have cached the ifref
for AS1 realise their mistake the first time they use it, and the
number of cached ifrefs for AS1 dwindles away over time.

Main Points:

1. Nothing in the CORBA standard causes more problems than would occur
in any system capable of passing service failure to a client.

2. Any client anywhere anytime has to be able to cope with failures.
Even ORBs will fail.

3. Requiring a more sophisticated failure detection/recovery algorithm
will simply require something extra to be built on CORBA.  CORBA does
not prevent this.

Short summary: Karen, it's a good question, but I don't think that the
problems resulting from it are challenging enough even to slow us
down.

Mark.

--
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779