models.html

Concurrent Programming in Java

      <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 an
active object/machine. Due to the wonders of Universal Turing
Machines, the virtual machine object can ``pretend'' that it is any or
all of the passive objects specified in a given program, so has an
interpretor 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 Java
over multiple hosts would be via direct virtual-machine to
virtual-machine interaction, which is unfortunately hard to pull off
in 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> for
more discussion.)

<h2>
<a name="secMix"></a>
Mixing Concurrency and Distribution
</h2>

Most Java programs communicate with other programs. For example, even
the act of firing up an Applet intrinsically involves communication
among different programs typically residing on different machines.
Additionally, each of these Java programs typically involves several
concurrent threads.

<p> Developing frameworks that support this can be attacked by
treating each Java program itself as a (distributed) object designed
using a per-object concurrency approach, that may in turn support
internal concurrency, designed using a per-activity approach. The
remainder of this section introduces and surveys some of the basic
issues 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 destination
object(s). So you need a way of tagging or prefacing each message
with a <em>handle</em> -- some kind of indication that controls which
object(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 central
to the construction of any object system. Once you decide on a
representation, you have to live with it, and/or find ways of coping
with other people's representations.

<h3>
Acceptors
</h3>

Java object references serve as handles inside single Java
programs (or Applets or whatever), but they have no `external'
form, so cannot be used for distributed messaging. For purposes of
developing most distributed object systems, this
restriction is a feature rather than a bug in Java.
Usually, you don't want most normal Java objects in a
program to directly receive external messages anyway. 
<p>

In fact, it logically suffices to have exactly one such object per
Java program. This <a href="acceptor.html" tppabs="http://www.foi.hr/~dpavlin/java/mirrors/g.oswego.edu/dl/pats/acceptor.html">Acceptor</a> object can
accept any kind of external message, and then internally relay it to
any normal object to perform the indicated action.

<p>
Single-Acceptor based designs often simplify external naming
problems since only one object needs an external handle.  For
example, this is how http works.  Machines that can serve http
traffic almost always have a single handle
(<code>http://internet.addr:80</code>) corresponding to a single
acceptor object that sometimes relays requests to other internal or
external helpers (for example replicate daemon processes, CGIs).

<p>
The Single-Acceptor approach implements a version of a meta-object
design. The acceptor serves as a shared meta-object, interpreting
messages and then executing them by dispatching to actions on other
ground-level objects. From this perspective, this approach limits
interprocess communication to interactions among meta-objects, not
ground 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 the
handle for object C. After receiving this message, B can communicate
directly with C since it knows C's handle. This applies even in the
two-party round-trip case -- Object A needs to send its own handle to object B
for B to even talk back to it.

<p>
Another way of saying this is that a handle-based system should
allow one object X to have a handle allowing it to communicate with
another 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 ``close
off'' part of a system for functionality, security, or efficiency
reasons.  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 the
messages themselves.  Theoretically, the only kind of value you need
ever send in a message is another handle. (See for example, papers
by <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 be
built up using handle-based encoding schemes. But this isn't a very
practical result.

<p>
A message could consist of anything that is sendable over a connection.
Connections are usually set up to transport raw bytes representing
anything at all, so the medium itself does not impose much structure
on messages. Which means that you need to define or adopt particular
formats yourself, and live within them.

<p>
The usual strategy for setting up distributed object messaging is
to 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>