<ul>        <li> Update internal state.        <li> Send a message.        <li> Create a new object.      </ul></ul><p> Further, the Java virtual machine may itself be thought of as anactive object/machine. Due to the wonders of Universal TuringMachines, the virtual machine object can ``pretend'' that it is any orall of the passive objects specified in a given program, so has aninterpretor loop specialized to:<UL>    <LI> Accept an instruction    <LI> Execute the instruction:    <UL>      <LI> If it is a passive object construction instruction, create a new            (passive) object with the required initial states and            attributes.      <LI> Else if it is a thread construction instruction, create a            new interpretor.      <LI> Else if it is an elementary operation on a            primitive object, then directly perform it it.      <LI> Else accept (and perform) all of the component instructions            listed in the body of the instruction    </UL></UL>According to this view, the strategy of choice for supporting Javaover multiple hosts would be via direct virtual-machine tovirtual-machine interaction, which is unfortunately hard to pull offin Java. The next section explores some alternatives.<p>(See, for example, OOSD<a href="javascript:if(confirm('http://g.oswego.edu/dl/oosdw3/ch6/node5.html  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/oosdw3/ch6/node5.html'" tppabs="http://g.oswego.edu/dl/oosdw3/ch6/node5.html">chapter 6</a>,<a href="javascript:if(confirm('http://g.oswego.edu/dl/oosdw3/ch15/node2.html  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/oosdw3/ch15/node2.html'" tppabs="http://g.oswego.edu/dl/oosdw3/ch15/node2.html">chapter 15</a>, and<a href="javascript:if(confirm('http://g.oswego.edu/dl/oosdw3/ch24/node1.html  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl/oosdw3/ch24/node1.html'" tppabs="http://g.oswego.edu/dl/oosdw3/ch24/node1.html">chapter 24</a> formore discussion.)<h2><a name="secMix"></a>Mixing Concurrency and Distribution</h2>Most Java programs communicate with other programs. For example, eventhe act of firing up an Applet intrinsically involves communicationamong different programs typically residing on different machines.Additionally, each of these Java programs typically involves severalconcurrent threads.<p> Developing frameworks that support this can be attacked bytreating each Java program itself as a (distributed) object designedusing a per-object concurrency approach, that may in turn supportinternal concurrency, designed using a per-activity approach. Theremainder of this section introduces and surveys some of the basicissues and alternatives for doing this.<h3>Handles  (Names, References, Channels, Capablities, ...)</h3>Distributed objects pass each other directed messages.  That is,each message is meant to be received by some particular destinationobject(s). So you need a way of tagging or prefacing each messagewith a <em>handle</em> -- some kind of indication that controls whichobject(s) should receive the message.   <p>Handles can take any of a lot of different forms, for example:<ul>  <li> Long (say, 128 bit) integers serving as universally unique       object identifiers (UUIDs).  <li> (machine, port, local-id) tuples.  <li> URL/URI style designations.  <li> Hardware-level ports and channels (for ``physical'' connections).  <li> Uniquely scoped Java class names.  <li> Extensions of Java object references.  <li> <em>Capabilities</em>: Names with intrinsically associated        information that helps control their use.  <li> Locally scoped names that are resolved into more        direct form via registries or other mediators (as in        CORBA-style ORBs).</ul>While such implementation mechanics are arbitrary, they are centralto the construction of any object system. Once you decide on arepresentation, you have to live with it, and/or find ways of copingwith other people's representations.<h3>Acceptors</h3>Java object references serve as handles inside single Javaprograms (or Applets or whatever), but they have no `external'form, so cannot be used for distributed messaging. For purposes ofdeveloping most distributed object systems, thisrestriction is a feature rather than a bug in Java.Usually, you don't want most normal Java objects in aprogram to directly receive external messages anyway. <p>In fact, it logically suffices to have exactly one such object perJava program. This <a href="acceptor.html" tppabs="http://www.foi.hr/~dpavlin/java/mirrors/g.oswego.edu/dl/pats/acceptor.html">Acceptor</a> object canaccept any kind of external message, and then internally relay it toany normal object to perform the indicated action.<p>Single-Acceptor based designs often simplify external namingproblems since only one object needs an external handle.  Forexample, this is how http works.  Machines that can serve httptraffic almost always have a single handle(<code>http://internet.addr:80</code>) corresponding to a singleacceptor object that sometimes relays requests to other internal orexternal helpers (for example replicate daemon processes, CGIs).<p>The Single-Acceptor approach implements a version of a meta-objectdesign. The acceptor serves as a shared meta-object, interpretingmessages and then executing them by dispatching to actions on otherground-level objects. From this perspective, this approach limitsinterprocess communication to interactions among meta-objects, notground objects. This vastly simplifies implementation.  <p>This approach also easily generalizes to designs with some small(perhaps fixed) number of acceptors, not just one.<h3>Handle-passing</h3>First, a trivial-looking but fundamental observation:<blockquote>     To support `open' distributed object systems, objects must be     able to pass handles as values to other objects.</blockquote><p>For example, object A may send a message to object B containing thehandle for object C. After receiving this message, B can communicatedirectly with C since it knows C's handle. This applies even in thetwo-party round-trip case -- Object A needs to send its own handle to object Bfor B to even talk back to it.<p>Another way of saying this is that a handle-based system shouldallow one object X to have a handle allowing it to communicate withanother object Y in only three ways:<ol>  <li> X is `born' knowing the handle for Y.  <li> X itself somehow created Y, thereby assigning or otherwise        knowing  Y's handle.  <li> Some other object passed X the handle to Y.       For example, this other object may be some kind of registry       object that X is born knowing, or perhaps one that       spontaneously sends messages to X.  The registry may maintain       lots of handles, organized in some useful fashion; for example       hierarchically (analogous to Yahoo) or via a searching/matching       service (analogous to Lycos) or whatever.</ol><h3>Limiting Message-Passing</h3>Open systems are great, but sometimes you want or need to ``closeoff'' part of a system for functionality, security, or efficiencyreasons.  There are only a few basic approaches for doing this:<dl>  <dt> Leakage Control  <dd> Disable or restrict one or more of the above three mechanisms       by which objects can know of handles.  <dt> Structured Handles (<em>capabilities</em>)  <dd> With the cooperation of the underlying infrastructure      or per-system design conventions, structure handles themselves      in a way that intrinsically restricts their usage. Such handles      are often termed <em>capabilities</em>. They are an extension of      the notion of an interface reference in Java: A holder may only      invoke operations on a capability that are known by the      infrastructure to be supported.  You can further add ``transfer      rights'' as part of any capability to disallow passing it as an      argument from one machine to another, or even from one Java      method to another. There are lots of specific forms of such      capabilities possible. For example those that contain      originating information, access lists, passwords, tunable      rights-transfers, etc. And several existing standard      implementations to choose among.        <dt> Self-Protection  <dd> Arrange that destination objects need not always accept or act       upon messages sent to them.  Handle-passing is necessary, but       not sufficient for useful communication.  For example, the       destination object may require that senders engage in some kind       of authentication protocol before or while sending normal       messages. Or for a functionality-based example, a destination       object may refuse to perform one method until it has first       performed another; as in an `open' being required before a       `read' of a file.  This approach is in keeping with the OO       design philosophy that each object is responsible for       maintaining its own integrity.  <dt> Interpositioning  <dd> Support only a three-party message passing scheme in which all       messages from X to Y must actually pass through object Z, that       does anything it likes with the messages from X, including       failing to pass them on to Y. This is usually implemented       `transparently' with respect to X and Y; for example, various       `invisible' proxy mechanisms and security agents that may       intervene in addition to the usually-many packet routing       machines between X and Y. </dl>    <h3>Messages</h3>So far, we've described only the handles used for directing messages, not themessages themselves.  Theoretically, the only kind of value you needever send in a message is another handle. (See for example, papersby <a href="javascript:if(confirm('ftp://ftp.cl.cam.ac.uk/users/rm135  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='ftp://ftp.cl.cam.ac.uk/users/rm135'" tppabs="ftp://ftp.cl.cam.ac.uk/users/rm135">Robin Milner</a>.)Everything else (even things like numbers) could in principal bebuilt up using handle-based encoding schemes. But this isn't a verypractical result.<p>A message could consist of anything that is sendable over a connection.Connections are usually set up to transport raw bytes representinganything at all, so the medium itself does not impose much structureon messages. Which means that you need to define or adopt particularformats yourself, and live within them.<p>The usual strategy for setting up distributed object messaging isto use messages of the same form as normal internal Java messages:<pre>methodName(arg1, arg2, ...)</pre>    <p><em>(To be continued ...)</em><p><a href="aopintro.html" tppabs="http://www.foi.hr/~dpavlin/java/mirrors/g.oswego.edu/dl/pats/aopintro.html">[Concurrent Programming in Java]</a><hr><address><A HREF="javascript:if(confirm('http://g.oswego.edu/dl  \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.  \n\nDo you want to open it from the server?'))window.location='http://g.oswego.edu/dl'" tppabs="http://g.oswego.edu/dl">Doug Lea</A></address><!-- hhmts start -->Last modified: Tue Feb 20 06:28:59 EST 1996<!-- hhmts end --></body> </html>