Re: Handling objects in a distributed system

Re: Handling objects in a distributed system

[S Muralidharan]

Vladmir G. Ivanovic writes:

>>Ed Berard poses an issue in dealing with objects in a distributed 
>>system:  how to send an object to another node.  
>>...

>Maybe there is something I'm missing, but why on earth would one want
>to send an object to another node?  Isn't it like passing an array to
>a procedure?  Why not just pass the name of the object?  In a truly
>distributed system, the name server will provide the access path.
>Then there is only one copy and no consistency problem.


	A very good question. In fact, in the context of reusable software
there are several problems with any object movement. 
	Any approach which advocates object movement generally assumes
that a single person is both the developer and a client of a
component. This assumption is certainly invalid, if software reuse
is based on component specifications and not source code, 
as done in Ada. While only the developers know the details of the software, 
only the clients know the nature of the hardware architecture where 
the software would be executed.
	We have proposed an approach to distributing programs built
from reusable software components whereby most short-lived objects
are never moved. Details of this work can be found in the following
technical report:

S. Muralidharan and B. W. Weide, On Distributing Programs Built from
Reusable Software Components, Technical Report OSU-CISRC-11/88-TR36,
Department of Computer Science, The Ohio State University, Columbus, 
OH 43210, November 1988.

	If you are interested in getting a copy of the report, please
send me mail to murali@cis.ohio-state.edu.

Cheers,

Murali

PS: I am cross-posting this article to comp.sw.components.

Re: Handling objects in a distributed system

[Edward Berard]

In article <58310@tut.cis.ohio-state.edu>,
murali@catamaran.cis.ohio-state.edu (S Muralidharan) writes:

> 
> Vladmir G. Ivanovic writes:
> 
> >Maybe there is something I'm missing, but why on earth would one want
> >to send an object to another node?  Isn't it like passing an array to
> >a procedure?  Why not just pass the name of the object?  In a truly
> >distributed system, the name server will provide the access path.
> >Then there is only one copy and no consistency problem.
> 
> 	A very good question. In fact, in the context of reusable software
> there are several problems with any object movement. 

I agree. These problems will impact both class and system design.

> 	Any approach which advocates object movement generally assumes
> that a single person is both the developer and a client of a
> component.

As Murali says later, this is indeed an invalid assumption. I am not
sure, however, whether anybody actually makes this assumption. If
someone is unfamiliar with object-oriented technologies, specifically
with the issues of object, class and system design, they might make
this mistake.

> This assumption is certainly invalid, if software reuse
> is based on component specifications and not source code, 
> as done in Ada. While only the developers know the details of the software, 
> only the clients know the nature of the hardware architecture where 
> the software would be executed.

I agree.

As I said in a previous posting, depending on the situation, "object
[and class] movement" may be a necessity. Please note, that I am not
advocating that objects and/or classes be moved without some technical
justification. Nor am I saying that "object movement" will be the
norm. I am merely suggesting it be an option which is selected based
on some sound technical judgement.

				-- Ed Berard
				   (301) 353-9652

Re: Handling objects in a distributed system

[S Muralidharan]

eberard@ajpo.sei.cmu.edu (Edward Berard) writes:

>murali@catamaran.cis.ohio-state.edu (S Muralidharan) writes:

>>       Any approach which advocates object movement generally assumes
>> that a single person is both the developer and a client of a
>> component.

>As Murali says later, this is indeed an invalid assumption. I am not
>sure, however, whether anybody actually makes this assumption. If

I believe that there are distributed systems/languages which profess
concerns for spec-based software reusability, but also aid object movement.
It is not obvious (to me) how this is possible if it is agreed that
neither the developers nor clients of reusable components can independently
decide when to move an object.

Murali

Re: Handling objects in a distributed system

[Vladimir G. Ivanovic]

In article <555@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>Yes, "call by reference" makes sense many times. However, "call by value," 
>"call by name," and redundancy have their places.

I (belatedly) agree.  The situations with which I am most familiar are
networked (not truely distributed) real-time applications where the cost of
maintaining the consistency of the database is high enough already without
having to deal with multiple writable objects, hence my intial skepticism.  

My tendency is not to stray from the "call by reference" model unless special
circunstances prevail, and clearly, as Ed Berard has pointed out, some exist.

Handling objects in a distributed system

[dave davis]

Ed Berard poses an issue in dealing with objects in a distributed 
system:  how to send an object to another node.  As Ed suggests, 
one solution is to have the knowledge of all the objects within the 
system be present at each node.  However, this might be inefficient 
in certain cases, and could cause difficulties if we with to create 
new objects dynamically.

I suggest that an approach would be to transmit "installation
instructions" (or template, or frame) with each transmitted object so
that the recieving node only needs to know a general schema for object
installation.  The instructions would have to contain information
about the object's interface, its last state, and enough information
about its structure to recreate it locally.  Assuming for a moment
that all of the objects in our system are created from more primitive
objects the mechanism need only have a representative of each
primitive object on hand, and know how to apply them in a specific
case.  Such a mechanism could also be two-way, translating objects
to/from non-objective representations.  This mechanism might also be
of use in storing and retrieving persistent objects off-line.

=================================================================
Dave Davis
MITRE Corp;
McLean, VA

Re: Handling objects in a distributed system

[Vladimir G. Ivanovic]

dave davis writes:
>
>Ed Berard poses an issue in dealing with objects in a distributed 
>system:  how to send an object to another node.  
>...
>I suggest that an approach would be to transmit "installation
>instructions" (or template, or frame) with each transmitted object so
>that the recieving node only needs to know a general schema for object
>installation.

Maybe there is something I'm missing, but why on earth would one want
to send an object to another node?  Isn't it like passing an array to
a procedure?  Why not just pass the name of the object?  In a truly
distributed system, the name server will provide the access path.
Then there is only one copy and no consistency problem.

Re: Handling objects in a distributed system

[Edward Berard]

In article <4812@omepd.UUCP>, vladimir@inteloc.intel.com (Vladimir G.
Ivanovic) writes:
> dave davis writes:
> >
> >Ed Berard poses an issue in dealing with objects in a distributed 
> >system:  how to send an object to another node.  
> >...
> >I suggest that an approach would be to transmit "installation
> >instructions" (or template, or frame) with each transmitted object so
> >that the receiving node only needs to know a general schema for object
> >installation.
> 
> Maybe there is something I'm missing, but why on earth would one want
> to send an object to another node?  Isn't it like passing an array to
> a procedure?  Why not just pass the name of the object?  In a truly
> distributed system, the name server will provide the access path.
> Then there is only one copy and no consistency problem.

Admittedly, "passing the 'name' of the object" and having "the name
server provide the access path ... [so that] there is only one copy
[of an object]," will be a recommended solution _part_ _of_ _the_
_time_. However, consider the following situations:

	- An application running on one node in a network needs access
	  to an object on a different node. The shortest path between
	  the node with the application and the node with the object
	  involves many other nodes. Even with the "access path" all
	  operations require an unacceptable amount of time due to the
	  time necessary to traverse the network.

	- The "traffic" (i.e., the amount of information traversing a
	  network) becomes intolerable. Ways are sought to reduce the
	  flow. It is determined that if either the original object,
	  or a copy of it, can be transmitted to a particular node
	  many operations can be performed locally (i.e., on the
	  node), thus reducing the need for some of the traffic.

	- P. Jalote, in the article "Resilient Objects in Broadcast
	  Networks" (IEEE TOSE, Vol. 15, No. 1, January 1989, pp.
	  68-72), describes "resilient objects," i.e., objects whose
	  states exist on multiple nodes in a network with the
	  intention of preserving the ability to continue processing
	  even if one of the nodes containing a necessary object goes
	  down.

The option proposed by Vladimir is only one out of many options in
distributed processing. Software engineers should be free to choose an
appropriate solution for the problem at hand. Yes, "call by reference"
makes sense many times. However, "call by value," "call by name," and
redundancy have their places.

				-- Ed Berard
				   (301) 353-9652