Modular Internet Programming with Cells Ran Rinat Scott Smith - - PowerPoint PPT Presentation

modular internet programming with cells
SMART_READER_LITE
LIVE PREVIEW

Modular Internet Programming with Cells Ran Rinat Scott Smith - - PowerPoint PPT Presentation

Modular Internet Programming with Cells Ran Rinat Scott Smith http://www.jcells.org Motivations Persistent language-level network connections Tightly coupled Internet protocols keep a persistent socket connection; no language-layer


slide-1
SLIDE 1

Modular Internet Programming with Cells

Ran Rinat Scott Smith http://www.jcells.org

slide-2
SLIDE 2

9/24/15 Cells @ ECOOP 2002 2

Motivations

Persistent language-level network connections

è Tightly coupled Internet protocols keep a persistent socket

connection; no language-layer protocols do this

Java/.NET are first generation Internet languages

è Lets work on the second generation

Modules and components have commonalities

è Unify them

Code architecture that mirrors deployment architecture

è Current practice declares module interface but not network

interface

slide-3
SLIDE 3

9/24/15 Cells @ ECOOP 2002 3

Our Proposal: Cells

Deployable containers of objects and code Implicitly distributed Connectors for forming persistent links

è Can be dynamically linked and unlinked è Can be linked locally or across the network

Unifies notions of module and component May be dynamically loaded, unloaded, copied Serve as principals in a security architecture

slide-4
SLIDE 4

9/24/15 Cells @ ECOOP 2002 4

Cells Unify Existing Technologies

Technology Commonalities Modules Import and export, linking, namespaces Components Advertise services, support distribution RMI Invocation of remote cell services Applets Code shipment via cell shipment Serialization Cells serialize with their serialized objects Mobile Objects Cells move as Code+object packages Object prototype Cells are prototyped, cloned

slide-5
SLIDE 5

9/24/15 Cells @ ECOOP 2002 5

Basic Cell Elements

Cell 1 Cell 2

= Class = Object = Operation Connector = Service =

plugout plugin code state

  • r
slide-6
SLIDE 6

9/24/15 Cells @ ECOOP 2002 6

The CVM (Cell Virtual Machine)

“JVM/CLR for cells” Many CVMs concurrently running on the Internet Cells are loaded into a CVM Cells in different CVM’s may communicate

transparently, as if they were local

è Invoke services on remote cells è Connect to remote cells

CVM controlled by a distinguished President Cell

slide-7
SLIDE 7

9/24/15 Cells @ ECOOP 2002 7

Cell Connectors

  • Cells upon first loading have no connections
  • Can connect and disconnect dynamically
  • Multiple connections on a single connector possible

when it is unambiguous

Cell connectors serve multiple purposes

1.

Code import, a la packages/modules

è

Cell-module additionally has state associated with it

è

In this model all module linking is at run-time

2.

Code plugin for dynamic extensibility

3.

Persistent (network) data connections

slide-8
SLIDE 8

9/24/15 Cells @ ECOOP 2002 8

CVM B

Chatter Example

Chatter 1

receive chatLink sendOut Chat send receive

Chatter 2

receive chatLink sendOut Chat CVM A send-receive receive-send

slide-9
SLIDE 9

9/24/15 Cells @ ECOOP 2002 9

Chatter with AV_Extension

Chatter

receive chatLink sendOut Chat

CVM

AV

AV_Extension

AV AV code imported

slide-10
SLIDE 10

9/24/15 Cells @ ECOOP 2002 10

JCells

New cell-based programming language 90% the same as Java in syntax and semantics Java concepts replaced: RMI, ClassLoader,

CLASSPATH, applet, package, security arch., … Implemented by compilation to Java

CVM (Cell Virtual Machine) implemented by JVM Basic features now implemented Full implementation in progress

slide-11
SLIDE 11

9/24/15 Cells @ ECOOP 2002 11

JCells Chatter Code Fragment

cell Chatter { … // Type declarations, etc connector Chat { plugins { send … } plugouts { receive … } }; void sendMessage(string m) { … send(m); … } } void unlinkFromChatter() … unlink at Chat; … void linkToChatter(cell Chatter other) { … link other at Chat [receive -> send, send <- receive]; …

slide-12
SLIDE 12

9/24/15 Cells @ ECOOP 2002 12

Cell identifiers (CID’s)

CID is a Universal (string) name for a cell

è With a CID alone you can address a cell that could be

anywhere

Cells transparently addressable by CID after

moving

è Implemented similar to snail mail forwarding

No two cells anywhere can share a CID

slide-13
SLIDE 13

9/24/15 Cells @ ECOOP 2002 13

Universality of CID’s

Susan

Chat send receive

Pete

receive chatLink sendOut Chat

ChatCentral

logon getUser logoff getUser(“Pete”) CIDPete … theCC <- getUser(“Pete”) … … link CIDPete at Chat; …

slide-14
SLIDE 14

9/24/15 Cells @ ECOOP 2002 14

CVM’

ChatCentral

Cell File States

ChatCentral.csc file

compile

ChatCentral.cell file

CVM load serialize load

ChatCentral

Unload

Objects created

slide-15
SLIDE 15

9/24/15 Cells @ ECOOP 2002 15

Cell source code in .csc files Cells can be in two states

1.

Cell active in a CVM, with fixed identity CID

2.

Serialized cell in .cell files, with (or without) CID

.csc files compile to .cell files

è

These .cell’s are anonymous (no CID)

è

They own no objects

Loading and CID’s

è

Anonymous .cell’s get a CID upon loading

Cell (Re-)deployment

slide-16
SLIDE 16

9/24/15 Cells @ ECOOP 2002 16

Cells and their objects

Every object in a CVM is owned by a cell Default policy

“you own the objects your code creates”

Cells serialize with their objects Modulated object references survive cell

movement

aCell

  • wned objects
slide-17
SLIDE 17

9/24/15 Cells @ ECOOP 2002 17

Copying and Moving Cells

Serializing a cell

è Its classes, its objects and CID serialized è “.cell file” produced

This .cell file can then be loaded into another CVM Move is serialize-unload-(transfer .cell file)-load

slide-18
SLIDE 18

9/24/15 Cells @ ECOOP 2002 18

Distribution

Transparency of distribution

è Differs from RMI where parameters implicitly copied if

  • bject is remote

Not all services/connectors support distributed use

è Parameters must all be passed by copy (or modulated

reference - forthcoming)

è Classes cannot be plugged in across the network

Cell movement across the network is supported

slide-19
SLIDE 19

9/24/15 Cells @ ECOOP 2002 19

Object References and Parameters

Hard references

è Your standard object reference è Local (intra-CVM) only; but inter-cell allowed

Modulated references

è Used for more tightly-coupled interactions between cells è Both intra-CVM and inter-CVM (implemented via a proxy) è Can be dynamically revoked (e.g. revoke at disconnect time)

Parameter passing

è Intra-CVM, no restrictions è Inter-CVM, cannot pass hard references è Explicit copy parameter syntax for inter-CVM case

slide-20
SLIDE 20

9/24/15 Cells @ ECOOP 2002 20

Modulated vs hard references

modulated reference invalidated

Cell 1 Cell 2

hard reference modulated reference modulation table

slide-21
SLIDE 21

9/24/15 Cells @ ECOOP 2002 21

Inter-CVM modulation

Cell 1 Cell 2

modulated reference modulation table

No inter-CVM hard references

slide-22
SLIDE 22

9/24/15 Cells @ ECOOP 2002 22

Cell Types

Strongly typed

è No dynamic checks except cast

Cell references have cell types

cell Chatter myChatter;

Cell types in Java spirit except structural subtyping

  • n cells for more universality

è Connector can have unused plugouts

slide-23
SLIDE 23

9/24/15 Cells @ ECOOP 2002 23

New Cell Security Architecture

[FCS, Copenhagen, July 2002]

Each cell is a principal with a public/private key Access control decisions can be cell-based

è “I only will connect on my privChat connector with Joe or Sue”

Uses SDSI/SPKI Internet standard, RFC2693

è Groups, authorization certificates, revocation, delegation

Cells can declare they will not share objects Additional capability layer

è without an initial capability to a cell, can’t even try connection

slide-24
SLIDE 24

9/24/15 Cells @ ECOOP 2002 24

Thorny Issues Galore

If superclass code makes an object, who owns it,

super or subclass’ cell? (super’s)

When a cell is serialized, it could have hard

references to objects it doesn’t own (null them)

When a plugged-in class is unplugged, what

happens to live objects of that class?

è (They become zombies – unusable)

What if cell is unloaded when another cell is

plugging in one of its classes (disallow unload)

slide-25
SLIDE 25

9/24/15 Cells @ ECOOP 2002 25

Related Work

Technologies partly incorporated

è Java è Modules: Modula-3, Units/Jiazzi, . . . è Components: Corba, COM, . . . è Prototype-based languages: Self, . . .

JavaSeal: passive seal = .cell; seals own objects;

J-Kernel XML/SOAP/UDDI/WSDL School

slide-26
SLIDE 26

9/24/15 Cells @ ECOOP 2002 26

jcells.org

slide-27
SLIDE 27

9/24/15 Cells @ ECOOP 2002 27

Cells address Internet needs

Internet Need Cell Solution

Code-level interaction Link via connectors Call-level interaction Service invocation Components move around Cells can be copied/moved Cross-network interaction Supported by cells Cross-component class inheritance (e.g., applets) Supported, between locally linked cells Different political entities Cell-level security, degree of cell isolation controllable Political situation volatile Unlink supported, affects modulated references

slide-28
SLIDE 28

9/24/15 Cells @ ECOOP 2002 28

Cell 1 Cell 2

= Class = Object = Operation Connector: Service:

plugout plugin