davis@COMMUNITY-CHEST.MITRE.ORG (dave davis) (08/08/89)
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
vladimir@inteloc.intel.com (Vladimir G. Ivanovic) (08/17/89)
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.
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/19/89)
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
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
vladimir@inteloc.intel.com (Vladimir G. Ivanovic) (08/26/89)
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.
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