murali@catamaran.cis.ohio-state.edu (S Muralidharan) (08/23/89)
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.
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/24/89)
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
murali@yacht.cis.ohio-state.edu (S Muralidharan) (08/29/89)
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