SUlecture.tom - New Npac.org

hedgebornabaloneΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 4 μήνες)

56 εμφανίσεις

Introduction to

Distributed Component Models

Tomasz Haupt


Overview


What is a software component?


Two examples: AWT and JavaBeans


Distributed objects: CORBA


Distributed components: EJB


Academic example: WebFlow

What is a component?


Very intuitive, but often vaguely defined


A semiconductor chip is a component

The chip vendor publishes manuals that tell developers the functionality of each pin


A0
-
A16 I/O Address bus

D0
-
D8 I/O Data bus

ACK O Acknowledge: Accepted when low

Building complex systems


Hardware system integrators connect pins of chips together
according to their functions to build complex electronic
devices such as computers.







Pins functionality defines behavior of the chip.


Pins functionality is standardized to match functionality of
the board (and take advantage of common services).

Component

one

Component

two

Software components


The software component model takes a very similar
approach:


the “pins” of software components are called interfaces


an interface is a set of methods that the component implements








software integrators connects components according to the
descriptions of the methods within the interface.

Component

one

Component

two

component’s interface

methods

Software components (2)


Component technology is still young, and there isn’t even
agreement on the definition of its most important element
-

the component.


“a component is a software module that publishes or
registers its interfaces”
,
a definition by P. Harmon, Component
Development Strategy newsletter (1998).


Note: a component does not have to be an object!

An object can be implemented in any language as long as
all the methods of its interface are implemented.


Often COM (Microsoft) components are not objects.


For Java developer, a component is a specialized object.

Component

one

Component

two

Component wiring




The traditional programming model is caller
-
driven (application calls
methods of a component’s interface, information is pulled from the
callee as needed). Component never calls back.


In the component programming model, connecting components may
call each other (connection
-
oriented programming).


The components can interacts with each other through
event
notification
(a component pushes information to another component as
some event arises). This enables wiring components at runtime.


Pragmatic definition


Software Components:


predictable behavior: implement a
common

interface


embedded in a framework that provides
common services (events, persistence, security,
transactions,…)


developer implements only business logic


Examples of component models


Before discussing
distributed

components
let us see our definition at work:


AWT components


JavaBeans

AWT Component model:

common behavior

Start

Submit

Exit

Save

This is a text area. The user can display and

modify a text




Java.lang.Object

everything in Java is an object



Java.awt.Component


specialized object; knows its position


on the screen, how to paint itself,


knows its parent, fires events


Java.awt.Button


Java.awt.Canvas


Java.awt.TextArea


Java.awt. Container


specialized component type


that can contain other AWT


components; methods: add, remove,


getComponents


Java.awt.Panel


Java.awt.Window


Java.awt.Frame

Java.lang.Object

everything in Java is an object



Java.awt.Component


specialized object; knows its position


on the screen, how to paint itself,


knows its parent, fires events


Java.awt.Button


Java.awt.Canvas


Java.awt.TextArea


Java.awt. Container


specialized component type


that can contain other AWT


components; methods: add, remove,


getComponents


Java.awt.Panel


Java.awt.Window


Java.awt.Frame

AWT Component model:

common behavior

Predictable behavior

Framework:

event mechanism

JavaBeans: Power of the container


Generic Java objects that follow the JavaBeans
coding conventions. This allows introspection.
Thus no specific “common interface”.


Container (environment in which beans live


BeanBox, JSP, Java Development Environment)


discovers bean properties, methods and events


properties editors (bean customization)


event based communication


persistence (object serialization)


Take an off
-
shell bean and use it in your application

Distributed objects


What if the objects live in different address
spaces?






Standard Java method invocation will not work.
We need a
remote

method invocation (RMI)
mechanism.

Class A {

B b =new B();

Object c = b.m(); }

Class B {

Object m() {…;

return Object o}; }

?

Distributed Objects (2)

Class A {

B b =new B();

Object c = b.m(); }

Class B {

Object m() {…;

return Object o}; }

interface B {

Object m() ; }

Class A {

B b =new b();

Object c = b.m(); }

Class StubB implements B {

Object m() {


send request;


return Object o;}

}

Class Bimpl implements B {

Object m() {…;

return Object o};

Class skeletonB {


receive request;


Object o = B.m();


send(o);

}

CLIENT

SERVER

Distributed Objects (3): CORBA

interface B {

Object m() ; }

Class A {

B b =new B();

Object c = b.m(); }

Class StubB implements B {

Object m() {


send request;


return Object o;}

}

Class Bimpl implements B {

Object m() {…;

return Object o};

Class skeletonB {


receive request;


Object o = B.m();


send(o);}

Language independent IDL

(Interface Definition Language)

Vendor provided classes

ORB:

object request broker

IIOP

Client

Server

INTERNET INTER
-
ORB PROTOCOL

CORBA IDL


Language independent, totally declarative
language to define object interface (contract
with a potential client)


The IDL grammar is a subset of C++ with
additional keywords to support distributed
concepts


Can be mapped to many languages,
including Java

BTW: Java RMI does not need IDL; DCOM uses binary interfaces

Module MyAnimals {


interface Dog:Animal {


attribute integer age;


exception NotInterested {string explanation};



void Bark(in long how_long) raises (NotInterested);


void Sit(in string where) raises(NotInterested);


}


interface Cat:Animal{


string saySomething();


}

}

Example IDL

package

int

String

Java

Java

Java

Developing CORBA applications

Create IDL

definitions


IDL

precompilation


Object

Implementation


Compilation

Client

Stubs

Server

Stubs

Object

Implementations

Interface

Repository

Implementation

Repository

Object Adapter

Client

Server

Developer’s

Task

Extend Skeleton or

implement interface

Dynamic CORBA

Dynamic Stub Invocation (DSI) and Dynamic Skeleton Invocation (DII)

allows constructing applications at runtime, without prior knowledge

of stubs and skeletons.


Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons

Responsible for life cycle of server objects

Distributed Objects (3): CORBA

interface B {

Object m() ; }

Class A {

B b = new B();

Object c = b.m(); }

Class StubB implements B {

Object m() {


send request;


return Object o;}

}

Class Bimpl implements B {

Object m() {…;

return Object o};

Class skeletonB {


receive request;


Object o = B.m();


send(o);}

Language independent IDL

(Interface Definition Language)

Vendor provided classes

ORB:

object request broker

IIOP

Client

Server

Yes, you have seen this slide!

B b = getObjectReference(…);

How to get an object reference


IOR: interoperable object reference


part of IIOP definition


includes all information needed to invoke


created when the object is created


orb.object_to_string(o);


can be stored in a file
(make sure that is not stalled!)


maintained by the CORBA naming service


Simple Client

Public class Client {


public static void main(String args[]) {


ORB orb = ORB.init(args, new java.util.Properties(...));


String masterURL = args[0];

String ref=getIORFromURL(masterURL);


org.omg.CORBA.Object obj=orb.string_to_object(ref);

MyRemoteObject mro=MyRemoteObjectHelper.narrow(obj);


mro.method();


}

Instantiate ORB

(vendor specific)

Read IOR from

a web server

Deserialize IOR

Ready to use

Generated by JIDL

CORBA: the Big Picture

Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons

Distributed Component Models


Hide implementation details


Remove vendor dependencies


Bring power of a container


Focus on business logic


Enable development of third
-
party
interoperable components

Enterprise JavaBeans


Java objects that implement
EJB interfaces


Container

that provides environment for beans


implements common object services such as
life cycle, security, naming, persistence,
communication, transaction processing,
resource pooling, …


provides tools or bean development such as idl
compiler

Enterprise JavaBeans (2)

CORBA enthusiast’s view

Of course, can be implemented in pure Java (RMI, JNDS,…)

EJB Container

Custom Beans

Off
-
shell Beans

Enterprise JavaBeans (3)

home interface

EJB home stub

remote interface

EJB remote stub

home interface

EJB home

remote interface

EJB object

EJB bean





client

server

EJB container

EJB bean implements only business logic

Enterprise JavaBeans (4)


Home interface:


provides methods for a client to create, locate,
and destroy EJB objects that it uses


Remote interface:


defines business methods of the bean

Types of Components


Sessions beans


provide business logic to a client, is accessed
by a single client at a time and is nonpersistent.


Entity beans


representation of persistent data, it can be
accessed by multiple clients concurrently.


Note:


COM: only session components


CCM: services, sessions, processes and entities

WebFlow Component Model


Developed at NPAC, Syracuse University


most of coding done by Erol Akarsu


Used to implement the Middle Tier of
computational Web portals


Build on top of CORBA


Exploits both common behavior and power
of the container

Compare AWT and WebFlow

Java.lang.Object

everything in Java is an object



Java.awt.Component


specialized object; knows its position


on the screen, how to paint itself,


knows its parent, fires events


Java.awt.Button


Java.awt.Canvas


Java.awt.TextArea


Java.awt. Container


specialized component type


that can contain other AWT


components; methods: add, remove,


getComponents


Java.awt.Panel


Java.awt.Window


Java.awt.Frame

Org.omg.CORBA.Object


WebFlow Component


specialized CORBA object


implements BeanContextChild


WebFlow Module


WebFlowContext (a Container)


can contain other WebFlow components


responsible for life cycle,


persistency, communications



Application A

Host A

Host C

Host D

Host B

Context D

Context C

Context B

Application C

Module A

Module B

Module C1

Module C2

Module D

WebFlow Distributed Applications

WebFlow component model


A WebFlow component is a CORBA object implemented in Java


A
WebFlowContext

object implements an extended BeanContext
interface, maintains a persistent state, controls its children life
-
cycle,
and is responsible for inter
-
JVM communications through a custom
event model. The master (“root”) context maintains a hierarchy of
proxy objects to facilitate communication with clients implemented as
Java applets without violating the sandbox restrictions.

Acts both as a CONTAINER and an ENTITY component.


A
WebFlow Module

implements BeanContextChild interface, is
stateless (more precisely, it maintains a conversational state), and has
access to all data maintained by its parent context.

Acts as a SESSION component.

User Context

Problem Context

WebFlow Contexts and Modules (2)

Org.omg.CORBA.Object


WebFlow Component


specialized CORBA object


implements BeanContextChild


WebFlow Module


WebFlowContext (a Container)


can contain other WebFlow components


responsible for life cycle,


persistency, communications



Session Context

Job context

code descriptor, job id,

date submitted, completed,

input file(s), output file(s)

A module in a context extends the
context functionality

Middle Tier Components

Task Specification

Resource Specification

Component Container

XML

parser

File

access &

transfer

job

control

User Context






profile

Credentials

(proxy)

Session Context



Job

object

Job

object

Job

object

batch

script

generator

resource

broker

data flow

manager

NetSolve

Linear Algebra

proxy

PSE

support

Information

services

database

access

data

analysis

Multi
-

disciplinary

task control

archivization

access

control

context

lifecycle

WebFlow Events


WebFlow components (modules) are developed
independently of each other.


They can interact with each other through WebFlow
events. (They can use remote invocation, but it requires the
caller to have reference to the target module, which
violates the WebFlow “module independence” rule).


There is only one type of WebFlow events. An event is an
(self
-
describing) object that encapsulates data to be
transferred from one module to another.


Each module can serve as a sink.


Event sources and sinks are associated at run time.

WebFlow Events

Method m

Client

B

Event

Adapter

uses

CORBA

DSI,DII

Event e

A

Context 1

Context 2

Module A does not care who is
expecting the event; method fire Event
invokes a method of its parent context


Method m is a public method:

anyone can invoke it, including

the Event Adapter of Context 1.

No protection against misuse!

Dynamic

Interfaces

A

B

Summary


A pragmatic definition of software
components:


predictable behavior: implement a
common

interface


embedded in a framework that provides common
services (events, persistence, security, transactions,…)


developer implements only business logic


Summary (2)


Best known distributed component models:


DCOM (Microsoft)


Enterprise JavaBeans (Sun Microsystems)


CCM: CORBA Component Model (OMG)


Academic example:


WebFlow system



End

Distributed Objects are less secure


can play both client and server


in client/server you trust the server, but not the clients


evolve continually


objects delegate parts of their implementation to the other objects (also dynamically composed
at runtime). Because of subclassing, the implementation of an object may change over time


interactions are not well defined


because of encapsulation, you cannot understand all the interactions between objects


are polymorphic
(ideal for Trojan horses!)


can scale without limit


how do you manage the access right to millions of servers?


are very dynamic

CORBA security is built into ORB

Secure Communications

Authentication

Client

Encryption

Audit

Authorization

Server

Encryption

Credentials

Object

Adapter

ORB

Authentication


A principal is authenticated
once

by ORB and
given a set of credentials, including one or more
roles, privileges, and an authenticated ID.


An authenticated ID is automatically propagated
by a secure ORB; it is part of the caller context

Principal

Credentials

Current

Client

Server

set_credentials

get_attributes

authenticate

Privilege Delegation


No delegation


The intermediary uses its own credentials


Simple delegation


The intermediary impersonates the client


Composite delegation


The intermediary uses both

Client

Target

Client

Target

Client

Target

Client

Target

Object

IIOP

Secure CORBA connection

client

server

Instantiate ORB

(creates credentials object)


get IOR and deserialize

(server authentication)


make request receive request

(ORB appends the current (decryption

and encrypts)
=binding=

client authentication)


(client authorization)