[TYPES] Types in distributed systems

[David Ryan]

On Tue, Sep 2, 2014 at 9:31 PM, "Ionuț G. Stan" <ionut.g.stan at gmail.com>
wrote:

> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list
> ]
>
> Thank you very much for this short classification. It does, indeed, add
> some order to my thoughts. I have added a few comments inline.
>
>
> On 02/09/14 12:55, Andreas Rossberg wrote:
>
>> In addition to the good answers you already got, let me add a few
>> clarifications perhaps addressing your question.
>>
>> First, it is worth noting that “distributed” and “open” are quite
>> different properties. A distributed program isn’t necessarily open, and an
>> open program isn’t necessarily distributed. In terms of type system
>> support, they manifest as very different problems. Openness typically
>> necessitates some amount of runtime type checking (or more than that,
>> depending on the possible complexity of the data and the degree of trust),
>> to reconfirm static assumptions at runtime. Type systems for distribution
>> are potentially concerned with notions like locality and mobility.
>>
>> “Open” does not necessarily imply “upgradable”. A system with the ability
>> to e.g. plug in modules at runtime, or communicate with statically unknown
>> principals, is already open. In these scenarios, it should be sufficient to
>> just perform a one-time check when a module is loaded or a connection is
>> established. After that, it stays fixed. Upgrading adds a dimension of
>> _mutability_ to the mix. It will typically be necessary to re-check each
>> upgrade or reconnect.
>>
>
> Right. Part of the same stream of questions I had initially was where
> would the Java Virtual Machine be situated in this picture. A single JVM
> process isn't distributed, and yet, one may still encounter similar
> situations to those that I imagined in original email, but due to classpath
> conflicts this time. I'm pretty confident now that the JVM can be
> classified as an open system.
>

> Case in point. On the JVM, one may end up in a situation where two
> libraries I'm depending upon, depend in turn on the same third library,
> *but* different versions of it. My code will compile just fine, because
> transitive dependencies aren't verified statically. At runtime, though,
> only one of those two versions of the third library will win and one of the
> possible outcomes is the dreaded java.lang.NoSuchMethodException.
>

That's an interesting point.  I've always thought that types in a
distributed system are confined to anywhere the only communication between
systems is via binary buffer.   However, the same problem of contract
negotiation occurs between any system that does runtime linking.  This is
also done in binary library linking when loading dynamic libraries.

>
> Although I cannot articulate it precisely, I feel there's a gap between,
> e.g., having a runtime check for out of bounds array indeces, on one hand,
> and missing method definitions at runtime on the other hand. As a library
> author, if I'm calling a function or method from an external module and my
> code compiles then I have a static *guarantee* that that method will be
> there at runtime, isn't it?
>

It's actually worse than just a missing a method.   If you allow object
references to be passed as parameter to a function then to do complete type
checking requires that every method and referenced object the passed object
connects is also checked against the expected library.  This is the same in
distributed system allowing complex types (e.g. XML).  Every sub type needs
to match the expected version.  The limitations in XML for instance have
given rise to rules about what you can and can't do when changing versions
(e.g http://www.subbu.org/blog/2005/03/versioning-xml-schemas).

There's plenty of interesting problems associated with distributed type
systems. I've always been surprised it hasn't been covered as well as it
should in literature.  I'm also yet to find a mailing list or forum with
enough people interested in investigating it further.  If anyone has any
pointers to such a place let me know.

Regards,
David.