computational rest meets erlang

Computational REST Meets Erlang

Alessandro Sivieri Gianpaolo Cugola Carlo Ghezzi

DeepSE GroupDipartimento di Elettronica e Informazione

Politecnico di Milano

49th International Conference onObjects, Models, Components and Patterns

June 30, 2011

IntroductionThe CREST-Erlang architecture

A performance assessmentConclusions

1 Introduction

2 The CREST-Erlang architecture

3 A performance assessment

4 Conclusions

Sivieri, Cugola, Ghezzi Computational REST Meets Erlang 2/21



Outline

1 Introduction



4 Conclusions




The scenario

Today’s applicationsLarge-scale and distributed on the Web

Components running on different devicesServices administered by different organizations

Long time executions, without interruptions or failures

We need frameworks able toSupport scalability and reliabilityGuarantee isolation among componentsOffer mechanisms for dynamic update of functionalities




REpresentational State Transfer

The modelClient-server separation for scalability and portability of thecodeStateless communication for reliabilityCaching mechanisms for scalability

The generic interfaceIndependence of applications on specific servicesApplication data must be encoded in a standard formatA host may not be able to correctly interpret these data




Computational REST

Designed as a response to real world problemsAdapts REST for an Internet of applicationsFrom a Web of data to a Web of computationsSame REST principles, different key abstraction

Erenkrantz, J.R., Computational REST: a new model for decentralized,Internet-scale applications, 2009




Scheme

Proposed as the lingua franca for the WebFunctional languageNative support for continuationsHistory of uses for mobile code

DrawbacksNo native support for distributed applicationsThe need to develop many CREST-related concepts (lightprocesses, communication facilities . . . )




Erlang

Erlang as the lingua franca for the WebFault-tolerance and “hot” code updateDistributed applications with an actor-like concurrency modelDesign patterns (generic server, supervisor . . . )




Outline

1 Introduction



4 Conclusions




Overview

The main architecture




A service example

1 my_serv ice ( S ta t e ) −>2 rece i ve3 {Pid , [ {" par1 " , P1} , . . . {"parN" , PN} ] } −>4 %% Do your j ob a c c e s s i n g par1 , . . . parN5 %% e v e n t u a l l y c r e a t e a new s t a t e6

7 %% I f ne c e s s a r y , spawn mys e l f on a hos t8 invoke_spawn (Hostname , ?MODULE,9 fun ( ) −> my_serv ice ( NewState )

end ) ,10

11 %% F i n i s h wi th a t a i l r e c u r s i o n12 my_serv ice ( NewState )13 end .




So far so good

Full implementation of the Computational REST architecturalstyleErlang is the proposed language of choice for a Web ofcomputationsMinor development effortCREST-Erlang prototype outperforms the CREST-Scheme one




Security concerns

The problemMobile code may cause two kinds of problems:

Security of the host with respect to the codeSecurity of the code with respect to the host

Neither of these have found, as of today, a stable solution.




CREST security proposals

CREST-SchemeJVM sandbox (implemented)Bytecode inspection and self-certifying URLs (ideas)

CREST-ErlangTrusted network: mutual authentication with SSL.




CREST security proposals

CREST-SchemeJVM sandbox (implemented)Bytecode inspection and self-certifying URLs (ideas)

CREST-ErlangTrusted network: mutual authentication with SSL.

In both cases they are not enough.




Outline

1 Introduction



4 Conclusions




Implementation effort

Stateful and stateless servicesService composition

Framework Framework source code Demo source codeCREST-Scheme 5938 817CREST-Erlang 2957 768

# of lines of code comparison




Performances

CREST-Scheme demo performances

(a) Response time (b) Throughput

There is no caching mechanism.




Performances

Test application performances

(a) Response time (b) Throughput

There is no caching mechanism.




Outline

1 Introduction



4 Conclusions




CREST-Erlang

ErlangNative support for

distributionconcurrencyfault-tolerance

The security problem

Computational RESTA possible evolution addressing the growing presence ofapplications interfacing through the WebIs HTTP the right protocol for transmitting computations?




Future work

Caching mechanism, for improving performances especially forstatic contentIntroduce the concept of subpeer, part of the latest CRESTdefinitionAdd more security mechanisms, for example for avoidingpossible attacks to a host




Thank you

Questions?


Appendix

Related works

Dynamic adaptationPublish-subscribeMap-reduce

Web applicationsRESTService-Oriented Architecture

Context-oriented languagesContextErlangDynamic Aspect-Oriented Programming


Appendix

Selected bibliography

J.R. Erenkrantz.Computational REST: a new model for decentralized, Internet-scaleapplications.California State University at Long Beach, 2009.

R.N. Taylor, P. Oreizy and N. Medvidovic.Runtime software adaptation: framework, approaches, and styles.ICSE Companion 2008, 899–910, 2008.

J. Armstrong.Programming Erlang: Software for a Concurrent World.Pragmatic Bookshelf, 2007.

J. Zachary.Protecting mobile code in the world.Internet Computing, IEEE, 7(2):78–82, 2003.


Appendix

Code

The CREST-Erlang code can be found at:https://github.com/sivieri/crest-erlang


https://github.com/sivieri/crest-erlang

Appendix

Licenses

This presentation is licensed under:

The image on slide 21 can be found at:www.flickr.com/photos/29890539@N07/4648496819/


www.flickr.com/photos/29890539@N07/4648496819/

computational rest meets erlang

Technology

cresterlang architecture3

c e s t

f n e c e s s

y c r e

e v e n t u

rest principles

r e c u r s i o n

c c e s s i n g par1