SOFACharles University, Prague

26
SOFA Charles University, Prague SOFA Overview Petr Hnetynka, Frantisek Plasil Distributed System Research Group Charles University, Prague http://nenya.ms.mff.cuni.cz

description

SOFACharles University, Prague. SOFA Overview Petr Hnetynka, Frantisek Plasil Distributed System Research Group Charles University , Prague http://nenya.ms.mff.cuni.cz. SOFA overview. SOFA Sof tware A ppliances Component model DCUP D ynamic C omponent Up dating - PowerPoint PPT Presentation

Transcript of SOFACharles University, Prague

SOFA Charles University, Prague

SOFA Overview

Petr Hnetynka, Frantisek Plasil

Distributed System Research GroupCharles University, Prague

http://nenya.ms.mff.cuni.cz

SOFA overview

• SOFA – Software Appliances

• Component model– DCUP

• Dynamic Component Updating

• Component distribution/delivery– SOFA node(s)

• Multiplatform– Prototype in Java– Experimental impl. in C++

TIRBrowser SOFA example

Controller

TIRQuery

Cache

TIR

TIRQueryBody

Stock Market Simulator SOFA example

Central UnitAdministrator Server

Configuration File Parser (P)

Log Viewer Server

Database Interface

Client Interface

Administrator Interface

Central Player Services Interface

Login Interface

Log Viewer Interface

Configuration File Parser Interface

Connectors Ex.:MediaPlayer

Controller ReadingUnit Display

Speaker

CSProcCall EventPassing

DataStream

Component Model SOFA

• Hierarchical components• Provides/requires interfaces• Ties

– Binding– Subsume– Delegation

• Connectors– Predefined

• ProcCall• EventPassing• DataStream

– User defined

• Protocols

Primitive component Implementation

CM

implementationobjects

CB

Composed component Implementation

CM

CB

Logical View Component Delivery

• SOFAnode(s)

Physical View Run part

• Deployment Dock & Registry~ container

~ naming

RUN TR

Prototype in Java

• Component model– Hierarchical components– Provides/requires interfaces– Ties– Connectors– Protocols

• SOFAnode (partially)– Run part– Made part

• TIR• CDL Compiler• Code Generator• Protocol Verifier

– TR (primitive)

Running a demo

• CDL spec By hand• Compiling CDL

– Check Protocol Compliance

• Generating Code fragments– Types– Component builders– Assembly descriptors

• Primitive components• Assembling

– Filling out Assembly descr

• Deploying application to Depl. Docks– Filling out Deployment map– Connector generation

• Launching

CDL spec Running a demo

interface TIRAccessInterface {

void init();

string query(in string name);

void finish();

protocol:

init; (query)*; finish

};

frame TIRQueryBody {

provides:

TIRQueryInterface query;

requires:

TIRAccessInterface tir;

CacheInterface cache;

protocol:

!tir.init;

?query.query{ !cache.get; (!tir.query+NULL) }* ; !tir.finish

};

frame TIRQuery {

...

}

architecture CUNI TIRQuery

implements TIRQuery {

inst TIRQueryBody body;

inst TIR tir;

bind body:tir to tir:access;

delegate query to body:query;

subsume body:cache to cache;

}

Coding Running a demo

public class TIRImpl implements TIRAccessInterface { Repository rep; public TIRImpl() {}

public void init(){ rep = (Repository) Naming.lookup(...); System.out.println("TIR opened"); }

public void finish() { rep=null; System.out.println("TIR closed"); }

public String query(String name) { return TIRPrint.printKind( TIRAccess.lookupContained(rep, "cdl", name)); }}

Assembly dscr Deployment map

<sofa_system name="TIRBrowserDemo">

<architecture_ref>...</architecture_ref>

<frame_ref>...</frame_ref>

<version>0.0.1</version>

<sofa_component name="frontend">

<architecture_ref>...</architecture_ref>

<frame_ref>...</frame_ref>

<version>0.0.1</version>

<connector name="query" ...>

<transport type="LOCAL"/>

</connector>

</sofa_component>

<unit><location>.....</location>

<sofa_component name="backend">

<architecture_ref>....</architecture_ref>

<frame_ref>...</frame_ref>

<version>0.0.1</version>

<connector name="query" ...>

<transport type="LOCAL"/>

</connector>

<sofa_component name="body">

...........

<sofa_system>

<architecture_ref>

::CUNI::SOFA::demos::tirbrowser::TIRBrowserDemo?nenya.ms.mff.cuni.cz!0

</architecture_ref>

<frame_ref>

::SOFA::libs::Application?nenya.ms.mff.cuni.cz!0

</frame_ref>

<version>0.0.1</version>

...

<component_ref inst="frontend" arch="::CUNI::SOFA::demos::tirbrowser::TIRBrowser“

version="0.0.1"/>

<component_ref inst="backend" arch="::CUNI::SOFA::demos::tirbrowser::TIRQuery"

version="0.0.1"/>

</sofa_system>

Connectors Design/Impl detailes

• Generic– Primitive elements– Roles

• Distribution units

cInterceptor

adaptor

stub

skeletonsynchronizer

sInterceptor

sRolecRole

Benefits Connectors

• Middleware interoperability….

<connector name="query" ...>

<transport type=“RMI-Jeremie"/>

<transport type=“CORBA"/>

</connector>

cInterceptor

adaptor

stub

skeletonsynchronizer

sInterceptor

sRolecRole

Benefits Connectors

• Distribution eliminated from component code– In connectors only– Achieved in steps:

• Architecture CDL:

– Connection type

» ProcCall

» EventPassing

» DataStream

» JavaSpaces (??? )

• Assembly descriptor

• Deployment

– Connector generation (based on depl. map)

• Launch

Fractal in SOFA Interoperability

• A Fractal component in a SOFA application– Seen as primitive

• CB directly – instantiates a Fractal component – ties its interfaces

• Calls forwarded via a (generated) adaptor– Granularity: for each interface

• Issue– Mapping Java CDL– Solution: Types limited to those in CDL (~CORBA IDL)

Fractal in SOFA Interoperability

Main

SClient

FHello

FractalHelloWorld

CM

CB

BCLC/CC

SOFA in Fractal Interoperability

• SOFA component in a Fractal application– Seen as primitive

• Wrapper – a Fractal component– forwards calls to the SOFA component through

connectors

• SOFA component “exists“ in a Deployment Dock– local - the same address space as the Fractal

application– remote - separate address space/even node

• Specific way of connector generation

SOFA in Fractal Interoperability

• logical view

Fractal component = wrapper

SOFAcomponentConnector Connector

SOFA in Fractal Interoperability

• Implementation view

Dock

SOFA

JORM

SOFA integration

• SOFA in ObjectWeb (future intentions & options)

Fractal

Monolog JOTM

logging

transactions

persistency

interoperability

ASM

Connectoroptimal.

OSGi

packagemanipulation

SOFA Benefits

• SOFA potential contribution to ObjectWeb

(mostly to Fractal through OSMOSE project)

– Connectors• Transparent component distribution

• Invisible in the code of a component

• Contrary to partial visibility in ProActive

– Protocols

– Dynamic update • to be combined with JORM

– SOFAnode

References

general• SOFA User’s manual, http://nenya.ms.mff.cuni.cz• Plasil,F., Balek,D., Janecek,R.: SOFA/DCUP Architecture for Component

Trading and Dynamic Updating. Proceedings of ICCDS'98, Annapolis, IEEE CS, 1998

protocols• Plasil,Visnovsky: Behavior protocols for Software Components, IEEE

Transactions on SW Engineering, Nov. 2002 (Tools USA, 1999)connectors• Balek,D., Plasil,F.: Software Connectors and Their Role in Component

Deployment. Proceedings of DAIS’01, Krakow 2001, Kluwer 2001• Bures, Bulej: A connector Suitable fro Automatic Generation fo

Connectors, CU TR 01/03design• Plasil, Mencl:Use Cases: Assembling “Whole Picture Behavior”, TR

02/11UNH Durham, submitted