introduction to distributed component models tomasz haupt

Introduction toDistributed 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 busD0-D8 I/O Data busACK 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).

Componentone

Componenttwo

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.

Componentone

Componenttwo

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.

Componentone

Componenttwo

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 andmodify a text

Java.lang.Objecteverything 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


Class A {B b =new B();Object c = b.m(); }




Language independent IDL(Interface Definition Language)

Vendor provided classesORB: 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 IDLpackage

int

String

Java

Java

Java

Developing CORBA applications

Create IDLdefinitions

IDLprecompilation

ObjectImplementation

Compilation

ClientStubs

ServerStubs

ObjectImplementations

InterfaceRepository

Implementation

Repository

Object Adapter

Client Server

Developer’sTask

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


Class A {B b = new B();Object c = b.m(); }




Language independent IDL(Interface Definition Language)

Vendor provided classesORB: 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 ClientPublic 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 froma 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


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 CHost D

Host B

Context DContext C

Context B

Application C

Module A

Module B

Module C1 Module C2Module 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 contextcode descriptor, job id,date submitted, completed,input file(s), output file(s)

A module in a context extends the context functionality

Middle Tier ComponentsTask Specification

Resource Specification

Component ContainerXMLparser

Fileaccess &transfer

jobcontrol

User Context

profileCredentials

(proxy)

Session ContextJob

object Jobobject

Jobobject

batchscript

generator

resourcebroker

data flowmanager NetSolve

Linear Algebraproxy

PSEsupport

Informationservices

databaseaccess

dataanalysis

Multi-disciplinarytask control

archivization

accesscontrol

contextlifecycle

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

BEvent

Adapteruses

CORBADSI,DII

Event eA

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

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

ObjectAdapterORB

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

ClientT

arge

t

Clie

nt

Tar

get

Clie

nt

Tar

get

Clie

nt TargetObject

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)

introduction to distributed component models tomasz haupt

Documents