EP0940748A2 - Objektverteilung in einer dynamischen Programmierbetriebsumgebung - Google Patents

Objektverteilung in einer dynamischen Programmierbetriebsumgebung Download PDF

Info

Publication number
EP0940748A2
EP0940748A2 EP99301529A EP99301529A EP0940748A2 EP 0940748 A2 EP0940748 A2 EP 0940748A2 EP 99301529 A EP99301529 A EP 99301529A EP 99301529 A EP99301529 A EP 99301529A EP 0940748 A2 EP0940748 A2 EP 0940748A2
Authority
EP
European Patent Office
Prior art keywords
proxy
objects
computer
remote
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP99301529A
Other languages
English (en)
French (fr)
Other versions
EP0940748A3 (de
Inventor
Geoffrey Alexander Cohen
David Louis Kaminsky
Richard Adam King
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of EP0940748A2 publication Critical patent/EP0940748A2/de
Publication of EP0940748A3 publication Critical patent/EP0940748A3/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99938—Concurrency, e.g. lock management in shared database

Definitions

  • moving objects allows the system to load balance among computers.
  • it allows the system to dynamically cluster objects that communicate frequently, reducing network traffic and improving overall system performance.
  • the present invention relating to Dynamic Object Distribution (DOD), describes a system that suffers neither of these limitations.
  • the programmer simply writes his program in the Java programming language (Java is a trademark of Sun Microsystems) without adding any special syntax or notations.
  • the program then executes on standard Java Virtual Machines (JVMs) which are widely deployed in the industry.
  • Object migration has been studied extensively in academia as well as in industry.
  • Systems such as the v-kernel enable page-based migration on systems running the v-kernel, however, systems without the v-kernel cannot perform migration. Because the v-kernel requires operating system modification, it is not widely used.
  • Systems such as Amber from the University of Washington migrate objects among nodes of a multi-processor computer. However, Amber requires the program to be written in a special language. The Amber runtime is also not widely used.
  • a major benefit of the present invention is that it requires no kernel modifications and works in Java which is a widely-deployed language.
  • DOD Dynamic Object Distribution
  • the DOD system From the bytecode files, the DOD system generates local and remote "proxies" for the object.
  • the proxies intercept method calls to and from the object, and route the calls to the object.
  • the local proxy When the object is local (it has not been migrated), the local proxy routes calls directly to the object; when the object is remote (it has been migrated), the local proxy routes calls to the remote proxy, which routes the calls to the object.
  • a bytecode modification tool adjusts the names of the objects and references to the objects to ensure that name collisions do not occur between objects and their proxies.
  • figure 1a illustrates calls from a method on an standard Java object to another standard Java object, in the illustration, calls from A 101 to B 105 .
  • Figures 1b and 1c show a typical scenario of calls before and after an object has been migrated.
  • Figure 1b shows calls being indirected through a local proxy 103 to the local object 105.
  • Figure 1c shows calls being sent from the local proxy 103 to a remote proxy 104 , then to the object itself 106 residing on the remote machine.
  • a "migration thread” determines when an object should be migrated. It monitors the resources on the computer to determine when a predicate is satisfied. (Optionally, the migration thread can also gather information about remote computers. For example, it could gather such information using the standard Unix command 'ruptime,' which returns information about the processor load,of remote computers. Such information can be used for migration decisions.) To migrate the object, the migration thread instructs the local proxy to route method calls to the remote proxy, and to send a serialized version of the object and its remote proxy to the remote computer. At the remote computer, both objects are unserialized.
  • Serialization is illustrated in Figure 7 and described further in Java in a Nutshell, second edition, O Reilly, May 1997, pp. 172-177. It is the flattening of an object so that it may be transmitted more efficiently through a network. An unserializer then reconstructs the original object at its destination.
  • FIG 1a illustrates calls between methods (prior art).
  • Figure 1b illustrates calls between methods in objects prior to migration (prior art).
  • Figure 1c illustrates calls between methods after migration (prior art).
  • Figure 2a depicts a standard object oriented (OO) program with three objects.
  • Figure 2b depicts a local configuration with one relocatable object.
  • Figure 2c depicts a migration thread for the configuration of figure 2b.
  • Figure 3 demonstrates operation after method C has been migrated to a remote host.
  • Figure 4 illustrates proxy generation and bytecode generation.
  • FIG. 5 illustrates call return preparation
  • Figure 6 exemplifies a migration thread.
  • Figure 7 depicts object serialization.
  • DOD uses a proxy scheme similar to Automatic Object Distribution (AOD, described in application serial number 08/852,263 referenced above), therefore, a brief review of AOD is presented herein.
  • AOD allows a programmer or system administrator to determine at any time before a program begins executing, how the program should be distributed onto a client and a server computer. AOD then automatically creates the code that allows the application to run as a distributed application.
  • AOD does not permit objects to be migrated between client and server at run-time. It requires the distribution to be complete prior to execution. It would be beneficial to move objects during runtime to adjust to varying conditions such as server load. That is, when the server becomes busier, more classes are moved to the client, reducing the server load.
  • an enhancement to AOD that allows objects to be moved during runtime is described.
  • Dynamic Object Distribution is an enhancement to AOD.
  • DOD Dynamic Object Distribution
  • the programmer identifies not only which classes should initially be on the client, and which should initially be on the server, but also which classes might be moved dynamically from one to the other. This identification as to which classes might be moved can be made any time up until the program is run.
  • the programmer identifies these classes not by changing the program itself (this is known art, see below), but by (e.g.) typing the list into a separate file. Other methods of specification will be apparent to those skilled in the art.
  • programmer-specified "predicates" are used to trigger the automatic migration of the objects.
  • the DOD process is comprised of the following steps. These steps, as the preferred embodiment of current invention, are expressed in the Java programming language and execution environment, although other embodiments in other object-oriented programming systems are possible.
  • the DOD process automatically moves objects when the predicates of step 4 are satisfied.
  • DOD contains a "migration thread.” This thread is responsible for monitoring system resources to determine when the predicates (described in step 4, and further described below) have been satisfied. It also initiates object migration.
  • Steps 1 and 2 are standard parts of the application development for Java.
  • the application would be executed by a user.
  • that application would lack the ability to move objects dynamically.
  • Objects instantiated from mobile classes are candidates for migration by DOD. If the programmer chooses not to enter any list, then DOD assumes that all objects can be migrated. Thus, by default, the programmer needn't make any source changes, nor need he do any additional work to enable object migration. This is a departure from known art. However, as we describe below, preparing an object for possible migration entails system overhead. The programmer can reduce this overhead by noting which objects will not be migrated. Still, requiring no changes to the program, even if a separate listing is required, provides significant benefit over the current art.
  • the predicates are specified. These predicates are used to control the dynamic behavior of the system.
  • the programmer identifies the conditions under which objects are migrated. For example, if objects designated O1 through O9 are to be executed on the server, the programmer can specify that DOD is to migrate O1 and O2 if the server load exceeds some threshold T1; O3, O4 and O5 are to be migrated if it exceeds T2; and O6 is to be migrated if it exceeds T3. O7, O8 and O9 are not migrated. In the preferred embodiment, this information is simply specified in a file called the "migration file," although other specification methods are clearly possible and would be obvious to one skilled in the art.
  • migration files may be specified on a per user basis as well as on a more global basis. That is, in the preferred embodiment, each version of the migration file (alternatively, each section within a single migration file) is associated with one or more users of the application. Thus, the application can optionally exhibit different behavior when executed by different users.
  • Step 5 designates the initial configuration for the system. That is, the programmer tells the system which classes spawn server objects, and which spawn client objects. In the preferred embodiment, this information is also stored in the migration file.
  • An example of a migration file might be: User1 MyClassOne CPU > .5 # move if CPU over half utilized User1 MyClassTwo CPU > .7 # move if CPU over 70% utilized User1 MyClassThree CPU > .9 # move if CPU over 90% utilized User1 MyIOClassOne Disk ⁇ .4 # move if disk is 60% full User1 MyIOClassTwo Disk ⁇ .2 # move if disk is 80% full ('#' indicates the beginning of a comment; subsequent text on the line is ignored.)
  • B' is then constructed to allow both local and remote calls.
  • B' looks like:
  • code must be added to migrate the object.
  • code must be added that protects method calls against timing conflicts -- that is, calls against methods in the object are not permitted while the object is migrating. This is done by making the proxy class "synchronized," (a standard Java term) thus protecting the class against race conditions, and adding a migration method.
  • the local proxy must register itself with the migration thread. This allows the migration thread to locate the proxy when an object must be migrated.
  • Each proxy is constructed such that it implements the Migratable interface. This allows the migration thread s register method to accept a single type of object as a parameter, that is, a proxy class implementing the Migration interface. The migration thread s register method then stores references to the parameters (proxy objects) in a table for use when an object must be migrated.
  • proxy object B' is synchronized, by standard Java semantics, the migration method cannot be executed while another method in the object is being called; similarly, no method can be called while the object is being migrated.
  • Serialization of an object, and passing serialized objects over sockets is well-known art in Java. After the object is serialized and sent over the network (using a standard Java method called writeObject ), it is received by a DOD component on the remote computer using another standard Java method (readObject ). The unserialized object is now ready to execute on the remote computer.
  • serializable interface typically, to be serialized, classes must implement the Serializable interface provided in the standard Java release. However, instances of classes that do not implement the Serializable interface will not be serialized by the JVM. Yet, DOD requires that objects be migratable without source change, and Java requires that Serializable objects implement the Serializable interface.
  • an object 401 is processed by a proxy generator 403.
  • the proxy generator creates a local proxy 405 and a remote proxy 407 as well as retaining the unmodified object 401.
  • the bytecode modifier 409 then processes the unmodified object 401 to create a serializable object 411 from it.
  • the remote proxy (B", in the example) accepts calls from the local proxy, and makes local calls to the original object (B).
  • the remote proxy must include code to redirect calls from the remote object, through the remote proxy, through the local proxy, and finally to the callee.
  • the process of generating code for return calls is very similar to the process used in AOD and to the process used here for incoming calls.
  • the bytecodes for the migratable object are inspected, and all method calls to other objects are extracted.
  • both a local proxy 510 and a remote proxy 520 are constructed containing similarly named methods to that discovered in the bytecodes.
  • Code in the remote proxy ensures that when the method is called, a remote (RMI) call to the local proxy is executed.
  • Code in the local proxy ensures that when it receives a remote call, it makes a local call to the actual callee.
  • this process is nearly identical to the process for generating proxies for incoming calls, except that the object is inspected for outgoing calls instead of for potential incoming calls (that is, public methods). Note that normal functions of the local and remote proxies are reversed in this case.
  • Migrating the object back to the local machine simply entails reversing the process.
  • the process is initiated by the migration thread when it detects that an "unmigration" should occur.
  • the migration thread calls the "unmigrate” method on the local proxy.
  • the call to the unmigrate method will not execute (that is, it will block) until a time when it will be the only method executing in the local proxy. Since all calls to the remote callee must pass through the local proxy, we know that the remote callee will not be executing when the unmigration occurs.
  • the unmigrate method on the local proxy simply calls the migrate method on the remote proxy. The call to the unmigrate method on the local proxy does not complete until the entire migration is complete.
  • the migrate method on the remote proxy performs the same function the migrate method on the local proxy performs. It serializes the object, transmits it to the local machine, which then unserializes the object. At that point, the local proxy sets its "local" boolean.
  • DOD monitors the predicates specified in the migration file. When a predicate is satisfied (e.g., when a load threshold is satisfied), the migration process is triggered.
  • the migration file is used to determine which objects are to be moved or migrated. They then call the migration method (shown above) on the proxies for each of these objects.
  • the migration thread executes pseudocode illustrated in Figure 6.
  • the migration method on the local proxy serializes the object, it s proxies and the proxies of any objects which it calls and sends it to the remote node for execution.
  • the JVM on the remote machine calls the "ReadObject” method to read the serialized objects, and registers the remote proxies with the Remote Method Invocation (RMI) Registry.
  • RMI Remote Method Invocation
  • the local proxy is constructed such that it contains all of the public methods contained by the object which it is proxying. Each of these methods either calls a method on the actual object (if the actual object is local) or remotely calls (via RMI) a method on the remote object (if the object was migrated and is now remote).
  • the proxy takes the name of the object for which it is acting as a proxy.
  • any calls originally destined for the migratable objects will be retargeted at the proxy simply by the standard Java semantics.
  • Java does not permit two objects to have the same name.
  • both the proxy and the object being proxied will have the same name. That is impermissible.
  • a renaming process is executed. Using a bytecode modification tool, the original (migratable object) is renamed by appending an arbitrary string to its name in its bytecode file. The constructors for the class are renamed similarly. The proxy then makes calls to this newly named object.
  • Figure 2a shows a simple object oriented program comprised of 3 objects, A, B and C.
  • Object A has three methods labeled a1-a3; B has four methods labeled b1-b4; and
  • Object C has two methods labeled c1 and c2.
  • the following method calls exist: a1 calls b3 and b4 a2 calls b2 b2 calls c2 c1 calls a2
  • Figure 2b depicts the same program after the programmer has specified that C is the only migratable object.
  • the system automatically generated a local proxy specified in the figure as CL, containing two methods specified as cl1 and cl2. Note that, per the discussion of naming conflicts, the local proxy and its methods are named with the original names of the object and its methods; the original object C was renamed by the bytecode modification tool (object renaming is not illustrated in the figure).
  • the method call list is thus adjusted to: a1 calls b3 and b4 a2 calls b2 b2 calls cl2 cl2 calls c2 cl1 calls c1 (unused) c1 calls a2
  • calls from the caller e.g., B
  • CL local proxy
  • C callee
  • Figure 2c shows the migration thread detecting a satisfied predicate and sending a message to the "migrate" method in the local proxy for C (CL). This causes the migration of C to the remote machine, and the transition to the configuration illustrated in figure 3.
  • Figure 3 shows the same configuration operating after C has been migrated to a remote computer.
  • the method call list becomes: a1 calls b3 and b4 a2 calls b2 // Call from b2 to c2 indirected remotely b2 calls cl2 cl2 calls cr2 using RMI cr2 calls c2 // Potential, but unused, calls into c1 cl1 calls cr1 using RMI (unused) cr1 calls c1 (unused) // Calls from c1 to a2 c1 calls ar2 ar2 calls al1 using RMI al2 calls a2
  • DOD consists of the following main steps: the programmer writes and compiles an application. The result is a set of Java bytecode (class) files. This is a standard development phase for Java applications, and is not strictly a part of the present invention.
  • the programmer identifies which objects can migrate, and the conditions under which they are to migrate.
  • DOD generates the local and remote stubs.
  • DOD performs bytecode modification to ensure that the appropriate classes implement the Serializable interface and that all name conflicts are resolved.
  • the stubs contain the code to direct method calls to the object whether it is local or remote. It also contains the code necessary to migrate the object.
  • the migration thread monitors the system resources, and determines when a predicate is satisfied.
  • the migrate method When a predicate is satisfied, it calls the migrate method on the object's proxy, causing a migration. Next the migration method serializes the remote object, along with the required remote proxies, and transmits them to the remote JVM (Java virtual machine), where the objects are reinstantiated. The application can then be restarted with its new configuration.
  • JVM Java virtual machine
  • a method and system which allow programs to become dynamically reconfigurable without programmer intervention.
  • the programs can be dynamically distributed among multiple computers within a computer network without modification to the source code of the programs running on the system.
  • the method and system described allow an administrator of the system to specify conditions under which reconfiguration is to occur without modification to the source text of the program to be dynamically reconfigured.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Multi Processors (AREA)
EP99301529A 1998-03-06 1999-03-02 Objektverteilung in einer dynamischen Programmierbetriebsumgebung Ceased EP0940748A3 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/036,270 US6324543B1 (en) 1998-03-06 1998-03-06 Dynamic object migration method using proxy object links to support automatic object distribution in an object-oriented environment
US36270 1998-03-06

Publications (2)

Publication Number Publication Date
EP0940748A2 true EP0940748A2 (de) 1999-09-08
EP0940748A3 EP0940748A3 (de) 2004-04-14

Family

ID=21887650

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99301529A Ceased EP0940748A3 (de) 1998-03-06 1999-03-02 Objektverteilung in einer dynamischen Programmierbetriebsumgebung

Country Status (3)

Country Link
US (1) US6324543B1 (de)
EP (1) EP0940748A3 (de)
JP (1) JPH11312088A (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019104A1 (fr) * 2000-08-28 2002-03-07 Sony Corporation Dispositif et procede de communication, systeme de reseau et appareil robotise
US7051341B2 (en) 2001-12-14 2006-05-23 International Business Machines Corporation Method, system, and program for implementing a remote method call
EP1672499A1 (de) 2004-12-20 2006-06-21 Sap Ag Verteilte Systemarchitektur zur Realisierung von variabler Kopplung unter Verwendung von Datenobjektmigration

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567861B1 (en) * 1997-09-17 2003-05-20 International Business Machines Corporation Method and apparatus for remotely running objects using data streams and/or complex parameters
US7155662B1 (en) * 1998-08-31 2006-12-26 Xerox Corporation Representing an entity as a document using a data source having active properties
US6993774B1 (en) * 1998-10-19 2006-01-31 Recursion Software, Inc. System and method for remote enabling classes without interfaces
US6691165B1 (en) * 1998-11-10 2004-02-10 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US6801949B1 (en) 1999-04-12 2004-10-05 Rainfinity, Inc. Distributed server cluster with graphical user interface
JP4546009B2 (ja) * 1999-06-11 2010-09-15 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー ソフトウエア要素間の通信
US6850953B1 (en) * 1999-08-23 2005-02-01 Sun Microsystems, Inc. Creating multiple sets of data by spawning a secondary virtual machine
US6947965B2 (en) 1999-11-30 2005-09-20 Recursion Software, Inc. System and method for communications in a distributed computing environment
US6678743B1 (en) * 1999-11-30 2004-01-13 Recursion Software, Inc. Method for moving objects in a distributed computing environment
US7469278B2 (en) * 2000-01-21 2008-12-23 Scriptlogic Corporation Validation of portable computer type prior to configuration of a local run-time environment
US6871221B1 (en) * 2000-01-21 2005-03-22 Scriptlogic Corporation Method and apparatus to manage network client logon scripts using a graphical management and administration tool
US7353262B2 (en) * 2000-01-21 2008-04-01 Scriptlogic Corporation Validation of configuration settings prior to configuration of a local run-time environment
US7293087B2 (en) 2000-01-21 2007-11-06 Scriptlogic Corporation Event-based application for performing configuration changes in a networked environment
US7016922B1 (en) * 2000-04-27 2006-03-21 Autodesk, Inc. Intelligent object versioning
JP2002189608A (ja) * 2000-08-28 2002-07-05 Sony Corp 通信装置及び通信方法、情報処理システム、プログラム作成方法、ネットワークシステム、並びにロボット装置
US7080159B2 (en) * 2000-12-15 2006-07-18 Ntt Docomo, Inc. Method and system for effecting migration of application among heterogeneous devices
US7325047B2 (en) * 2001-05-23 2008-01-29 International Business Machines Corporation Dynamic undeployment of services in a computing network
US7647597B2 (en) * 2001-06-28 2010-01-12 Microsoft Corporation Transparent and sub-classable proxies
GB2381154B (en) * 2001-10-15 2004-06-30 Jacobs Rimell Ltd Object distribution
US8166185B2 (en) * 2002-03-05 2012-04-24 Hewlett-Packard Development Company, L.P. System and method for enterprise software distribution
US6983449B2 (en) * 2002-03-15 2006-01-03 Electronic Data Systems Corporation System and method for configuring software for distribution
US7590618B2 (en) 2002-03-25 2009-09-15 Hewlett-Packard Development Company, L.P. System and method for providing location profile data for network nodes
US7096249B2 (en) * 2002-03-29 2006-08-22 Intel Corporation Method and system for distributing applications
US20030204582A1 (en) * 2002-04-29 2003-10-30 Shimoda Marion H. Wireless personal area network scalable migration of resources
US7039644B2 (en) * 2002-09-17 2006-05-02 International Business Machines Corporation Problem determination method, system and program product
US7373632B1 (en) * 2003-12-01 2008-05-13 Sun Microsystems, Inc. System and method for dynamic generation of proxies for isomorphic interfaces
US8429253B1 (en) 2004-01-27 2013-04-23 Symantec Corporation Method and system for detecting changes in computer files and settings and automating the migration of settings and files to computers
US7984107B2 (en) * 2005-09-09 2011-07-19 Microsoft Corporation Proxy assembly for simulating real assembly features on a remote device
US20090007081A1 (en) * 2006-05-26 2009-01-01 Lau Allen N L System and Method of Generating Applications for Mobile Devices
US8621427B2 (en) 2010-06-30 2013-12-31 International Business Machines Corporation Code modification of rule-based implementations
CN102495757A (zh) * 2011-11-15 2012-06-13 深圳市融创天下科技股份有限公司 一种适用于java远程调用对象传输的优化方法、装置
US8966211B1 (en) * 2011-12-19 2015-02-24 Emc Corporation Techniques for dynamic binding of device identifiers to data storage devices
US9378034B2 (en) 2013-05-16 2016-06-28 Sap Se Dynamic bytecode modification of classes and class hierarchies
US20150268989A1 (en) * 2014-03-24 2015-09-24 Sandisk Enterprise Ip Llc Methods and Systems for Extending the Object Store of an Application Virtual Machine
US10146448B2 (en) 2014-05-30 2018-12-04 Sandisk Technologies Llc Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device
US10114557B2 (en) 2014-05-30 2018-10-30 Sandisk Technologies Llc Identification of hot regions to enhance performance and endurance of a non-volatile storage device
US10656840B2 (en) 2014-05-30 2020-05-19 Sandisk Technologies Llc Real-time I/O pattern recognition to enhance performance and endurance of a storage device
US10162748B2 (en) 2014-05-30 2018-12-25 Sandisk Technologies Llc Prioritizing garbage collection and block allocation based on I/O history for logical address regions
US10521200B2 (en) * 2017-01-09 2019-12-31 Oracle International Corporation Unambiguous proxying of interface methods

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3365576B2 (ja) * 1993-06-14 2003-01-14 インターナショナル・ビジネス・マシーンズ・コーポレーション オブジェクトの実行方法および装置
JP2682811B2 (ja) * 1994-03-22 1997-11-26 インターナショナル・ビジネス・マシーンズ・コーポレイション データ記憶管理システム及び方法
GB2305271A (en) * 1995-09-15 1997-04-02 Ibm Proxy object recovery in an object-oriented environment
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US5881230A (en) * 1996-06-24 1999-03-09 Microsoft Corporation Method and system for remote automation of object oriented applications

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
PHILIPPSEN M ET AL: "JavaParty-transparent remote objects in Java" JAVA FOR COMPUTATIONAL SCIENCE AND ENGINEERING - SIMULATION AND MODELING II, LAS VEGAS, NV, USA, 21 JUNE 1997, vol. 9, no. 11, pages 1225-1242, XP008020895 Concurrency: Practice and Experience, Nov. 1997, Wiley, UK ISSN: 1040-3108 *
SCHILL A B ET AL: "DC++: DISTRIBUTED OBJECT-ORIENTED SYSTEM SUPPORT ON TOP OF OSF DCE" DISTRIBUTED SYSTEMS ENGINEERING, IEE, LONDON, GB, vol. 1, no. 2, 1 December 1993 (1993-12-01), pages 112-125, XP000607911 ISSN: 0967-1846 *
WOLLRATH A ET AL: "Java-centric distributed computing" IEEE MICRO, MAY-JUNE 1997, IEEE, USA, vol. 17, no. 3, pages 44-53, XP002265477 ISSN: 0272-1732 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019104A1 (fr) * 2000-08-28 2002-03-07 Sony Corporation Dispositif et procede de communication, systeme de reseau et appareil robotise
CN100380324C (zh) * 2000-08-28 2008-04-09 索尼公司 通信设备和通信方法、网络系统、以及机器人设备
US7388879B2 (en) 2000-08-28 2008-06-17 Sony Corporation Communication device and communication method network system and robot apparatus
US7051341B2 (en) 2001-12-14 2006-05-23 International Business Machines Corporation Method, system, and program for implementing a remote method call
EP1672499A1 (de) 2004-12-20 2006-06-21 Sap Ag Verteilte Systemarchitektur zur Realisierung von variabler Kopplung unter Verwendung von Datenobjektmigration
US8239503B2 (en) 2004-12-20 2012-08-07 Sap Ag Distributed system architecture for variable coupling

Also Published As

Publication number Publication date
US6324543B1 (en) 2001-11-27
EP0940748A3 (de) 2004-04-14
JPH11312088A (ja) 1999-11-09

Similar Documents

Publication Publication Date Title
EP0940748A2 (de) Objektverteilung in einer dynamischen Programmierbetriebsumgebung
KR100285223B1 (ko) 프로그램에입각하여분산오브젝트프로그램을생성하는방법
JP3072709B2 (ja) 要求伝達方法
US6230160B1 (en) Creating proxies for distributed beans and event objects
US6496871B1 (en) Distributed agent software system and method having enhanced process mobility and communication in a computer network
Golm et al. The JX Operating System.
EP1756713B1 (de) Gemeinsame benutzung von objekten in laufzeit-systemen
AU2005292418B2 (en) Method and apparatus for moving processes between isolation environments
EP1763741B1 (de) Gemeinsame benutzung von objekten in laufzeit-systemen
US6636900B2 (en) Method and apparatus for executing distributed objects over a network
US7039911B2 (en) Hybrid threads for multiplexing virtual machine
KR20010034514A (ko) 원격 메소드를 식별하는 해시 판정 방법 및 시스템
US6208994B1 (en) Supporters providing extensible classes without recoding for object-oriented applications
Dave et al. Proxies, application interfaces, and distributed systems
US7552434B2 (en) Method of performing kernel task upon initial execution of process at user level
EP0628907B1 (de) Verfahren zum Ausführen einer nicht für das Rechnersystem konzipierten Anwendung auf einem Rechnersystem
US7546600B2 (en) Method of assigning virtual process identifier to process within process domain
JPH0855035A (ja) マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置
Evans et al. Zones, contracts and absorbing changes: An approach to software evolution
US6513157B1 (en) System and method for dynamically aggregating objects
US7039673B1 (en) Method and apparatus for dynamic command extensibility in an intelligent agent
Pase Dynamic probe class library (dpcl): Tutorial and reference guide
Gray et al. Native‐language‐based distributed computing across network and filesystem boundaries
Van Heiningen et al. Exploiting dynamic proxies in middleware for distributed, parallel, and mobile Java applications
JP3242376B2 (ja) 暗黙的なエージェント再配置を用いてリモート・ネットワーク・コンポーネントへのアクセスを自動的にローカライズするためのシステムおよび方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17P Request for examination filed

Effective date: 20040510

17Q First examination report despatched

Effective date: 20040921

AKX Designation fees paid

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20090305