Page 1Component models

Component Models and TechnologyComponent Models and Technology

Component-based Software EngineeringComponent-based Software Engineering Ivica CrnkovicIvica Crnkovic

ivica.crnkovic@mdh.se

Page 2Component models

OverviewOverview

Introduction

ACME Architectural Description Language

Java Bean Component Model

COM, DCOM, MTS and COM+

CORBA Component Model (CCM)

.NET Component Model

OSGI Component Model

Page 3Component models

Architecture Definition LanguagesArchitecture Definition Languages

ADLs primarily address the issues related to the early phases of software engineering:

Design

Analysis

They identify a number of concepts, such as:

Architecture, configurations, connectors, bindings, properties, hierarchical models, style, static analysis and behavior.

Page 4Component models

ACME Architectural Description LanguageACME Architectural Description Language

Components and Ports

Connectors and Roles

Systems and Attachments

Representations and Bindings

Properties, Constraints, Types and Styles

Page 5Component models

Components and PortsComponents and Ports

Components

Represent the computational elements and data stores of a system.

Ports

Are the points of interaction between a component and its environment.

ComponentPort

Page 6Component models

Connectors and RolesConnectors and Roles

Connectors

Represent interactions between components such as method calls or an SQL connection between a client and a database server.

The interface of a connector is defined as a set of roles

Connector

Role

Page 7Component models

Systems and AttachmentsSystems and Attachments

The structure of a system is specified by a set of components, a set of connectors, and a set of attachments.

Attachment

Links a component port to a connector role.

Attachement

Page 8Component models

Representations and BindingsRepresentations and Bindings

Connector

Component

PortRole

AttachementBinding

Page 9Component models

Component InteractionsComponent Interactions

Iteractions withtraditional software entities

Interactions withother

components

Interactions withother

components

Interactions withcomponent infrastructure

Components

Traditional software entities

Component Infrastructure

Page 10Component models

Terms in Components-based technologiesTerms in Components-based technologies

Interface that satisfies contracts

Component implementation

Component model

Independent deployment

Component-typeSpecific interface

Coordination Services (transactions, persistence..)

ComponentFramework

Page 11Component models

Java Bean Component ModelJava Bean Component Model

Page 12Component models

Key FeaturesKey Features

"A Java Bean is a reusable software component that can be manipulated visually in a builder tool”.

The Java Bean was designed for the construction of graphical user interface (GUI).

Explicitly tailored to interact in two different contexts:

At composition time, within the builder tool.

At execution time, with the runtime environment.

Any Java class that adheres to certain conventions regarding property and event interface definitions can be a JavaBean.

Properties of a compiled bean can be obtained by introspection mechanism

Page 13Component models

Interface of a ComponentInterface of a Component

This model defines four types of port:

methods,

properties,

event sources (generate an event)

event sinks called listeners (they receive event)

Read-only property

Write-only property

Property

Method

Event source

Event sink (listener)

Bounded property

v Vetoable property

ro

wo

1 Unicast event source

Ports

Page 14Component models

Implementation of a ComponentImplementation of a Component

Most bean components are implemented by a simple Java object by naming convention

Object

Method

A simple implementation

Propertiespublic void set<Property_name> (PropertyType value)public PropertyType get<Property_name> ()

Eventspublic viod add<ListenerType> (<ListenerType> listener);public viod remove<ListenerType> (<ListenerType> listener);public class Y implements <Y>Listener { public viod <YoccuranceName> (<YObjectType> evt);}

Page 15Component models

Components AssemblyComponents Assembly

Assembly is one of the key features of Java Bean though no not specific solution is provided.

Composition tools (Bean Box)

No composition language

Different ways of assembling components are supplied.

Component-based assembly Heterogeneous assembly

Page 16Component models

Packaging and DeploymentPackaging and Deployment

Java Beans define a model for packaging components into archives.

Includes the definition of dependency relationships between the package items.

Each package item can be marked "Design Only", so that they can be removed in a final application.

Page 17Component models

An exampleAn example

Example of a Cannibal bean, e.g as a part of a computer game

The Example contains:

A simple bean with a simple property and a boolean bound property

A simple test class for the bean

A class which do an introspection on the bean (similar to what a builder tool will do) showing the bean’s services, properties and events

Page 18Component models

import java.beans.*; //for PropertyChangeListener

class Cannibal { private String name; //r simple property private boolean saved; //rw bound boolean property //change listeners list private PropertyChangeSupport change;

public Cannibal() { this("Eddy Merx", false); }

public Cannibal(String n, boolean s) { name=n; saved=s; change=new PropertyChangeSupport(this); }

public String getName() {//property name, get method return name; }

public boolean isSaved() {//property saved, isXxx method, bound return saved; }

Page 19Component models

//property saved, set method public void setSaved(boolean s) { boolean old=saved; saved=s; change.firePropertyChange( "saved", new Boolean(old), new Boolean(s) ); }

//bean services //…

// Property Change Listener Support Methods public synchronized void addPropertyChangeListener( PropertyChangeListener listener) { change.addPropertyChangeListener(listener); } public synchronized void removePropertyChangeListener( PropertyChangeListener listener) { change.removePropertyChangeListener(listener); }}

Page 20Component models

public class Foo implements PropertyChangeListener { private Cannibal can;

public static void main(String[] args) { new Foo(); }

public Foo() { can=new Cannibal(); // create a Cannibal // add self to the Cannibal's listener list can.addPropertyChangeListener(this); // change the cannibal to saved can.setSaved(true); // fires property change event }

public void propertyChange(PropertyChangeEvent event) { if (event.getPropertyName().equals("saved") ) { System.out.println( "The cannibal "+can.getName()+" has been converted.“ ); System.out.println("old saved status was: "+event.getOldValue()); System.out.println("new saved status is: "+event.getNewValue()); } }}

Page 21Component models

Output from execution of Output from execution of FooFoo

The cannibal Eddy has been converted old saved status was: false new saved status is: true

Page 22Component models

import java.lang.reflect.*;

public class IntrospectCannibal { public static void main(String[] args) { try { // obtain class object for class Cannibal Class classObject = Class.forName("Cannibal"); // get Constructor, Field and Method objects Constructor[] cons=classObject.getDeclaredConstructors(); Field[] fields = classObject.getDeclaredFields(); Method[] methods = classObject.getDeclaredMethods(); System.out.println("Class Cannibal"); System.out.println("\nConstructors:\n"); for (int i=0; i<cons.length; ++i) System.out.println(cons[i]); System.out.println ("\nFields:\n"); for (int i=0; i<fields.length; ++i) System.out.println(fields[i]); System.out.println("\nMethods:\n"); for (int i=0; i<methods.length; ++i) System.out.println(methods[i]); } catch(Exception e) {e.printStackTrace(System.out);} }}

Page 23Component models

Output from IntrospectCannibalOutput from IntrospectCannibal

Class CannibalConstructors:

public Cannibal(java.lang.String,boolean)public Cannibal()

Fields:private java.lang.String Cannibal.nameprivate boolean Cannibal.savedprivate java.beans.PropertyChangeSupport Cannibal.change

Methods:public java.lang.String Cannibal.getName()public boolean Cannibal.isSaved()public void Cannibal.setSaved(boolean)public void Cannibal.hunt(java.lang.Object)public synchronized void Cannibal.addPropertyChangeListener(java.beans.PropertyChangeListener)public synchronized void Cannibal.removePropertyChangeListener(java.beans.PropertyChangeListener)

Page 24Component models

Java Remote Method Invocation (Java RMI)Java Remote Method Invocation (Java RMI)

RMI is an interface used over two protocols

Java Remote Method Protocol (JRMP)

Internet Inter-ORB Protocol (IIOP)

JavaClientJavaClient

CORBAObject

CORBAObject

JavaObjectJava

Object

RMIRMI

JRMP, IIOPJRMP, IIOP

Page 26Component models

Enterprise JavaBeansEnterprise JavaBeans

Architecture for distributed applications (distributed components)

Framework for creating middleware

EJB Server

EJB Container

Enterprisebean

EJBclient

Clients accesses JBs via containers

Page 27Component models

Calling an Enterprise BeanCalling an Enterprise Bean

HomeObjectHomeObject

EJB Container/Server

Client Application

Client Application

1. Call a method

EnterpriseBean

EnterpriseBean

EJBObjectEJB

Object

2. Acquire a bean and delegate thecall to the bean

2. Acquire a bean and delegate thecall to the bean

3.Return result

4. Return to client

Page 28Component models

Creating the EJB ObjectCreating the EJB Object

HomeObjectHomeObject

EJB Container/Server

Client Application

Client Application 1. Create EJB Obj.

EnterpriseBean

EnterpriseBean

EJBObjectEJB

Object

2. Create EJB Object

3. Return EJB Obj. Ref.

Page 29Component models

1. Retrivehomeobject

2. Return reference

JNDI

Java Naming and Directory InterfaceJava Naming and Directory Interface

Client Application

Client Application

NamingServiceNamingService

Page 30Component models

1. Retrivehomeobject

2. Return reference

JNDI

One More TimeOne More Time

HomeObjectHomeObject

EJB Container/Server

Client Application

Client Application 3. Create EJB Obj.

EnterpriseBean

EnterpriseBean

EJBObjectEJB

Object

4. Create EJB Object

5. Return EJB Obj. Ref.

NamingServiceNamingService

6. Call a method

7. Acquire a bean and delegate thecall to the bean

7. Acquire a bean and delegate thecall to the bean

8.Return result

9. Return to client

Page 31Component models

Java Application Server TechnologiesJava Application Server Technologies

EJBApplications

EJBApplications

EJB

HTTPListener

HTTPListener

Windows NT, Unix,Others

DBMSDBMS

DBMSDBMS

DBMSDBMS

JSPApplications

JSPApplications

BrowserClient

BrowserClient

RichClient Rich

Client

HTTP

RMI/IIOP

VariousJavaTools

VariousJavaTools

VariousJSP ToolsVarious

JSP Tools

ServletsServlets

JDBCJDBC

JDBCJDBC

JDBCJDBC

Page 32Component models

J2EE (Java 2 Platform, enterprise edition)J2EE (Java 2 Platform, enterprise edition)

Defines an architecture for building large scale multi-tier distributed applications

Uses standardized modular components

Provides standard services for those components

Automatically replaces many aspects of the application programming from the developer

Thinner clients

Page 33Component models

J2EE architecture componentsJ2EE architecture components

J2EE Platform Specification Specification of the APIs to be provided Descriptions of the support levels expected for

containers, clients, and components

J2EE Sun’s Reference Implementation Free implementation of the specified technologies,

sample applications, tools, and documentation

J2EE Compatibility Test Suite Test implementations of the platform

J2EE Sun BluePrint Documentation, examples, and design guidelines

Page 34Component models

J2EE application modelJ2EE application model

Business logic in Enterprise JavaBeans components

Client interaction presented through different technologies

Plain Html

Java applets

Java servlets

JSP

Components communicates transparently using different standards

Html

XML

RMI

Page 35Component models

The J2EE architectureThe J2EE architecture

(Pic. Sun Microsystem, http://java.sun.com/j2ee/overview3.html)

Page 36Component models

COM/DCOM

Page 37Component models

Interfaces and AssemblyInterfaces and Assembly

A COM interface is seen as a C++ virtual class and takes the form of a list of data and function declarations without associated code.

All interfaces are descendants of the IUnknown interface.

Component interface

Interface

Component implementation

Page 38Component models

A Simple COM ObjectA Simple COM Object

A COM interfaces can have methods and properties

Language independent – binary standard

All Access is through the interface

Supports multiple interfaces

Each interface has a GUID

Page 39Component models

IUnkownIUnkown

All COM objects must implement IUnknown

AddRef

Release

QueryInterface IUnknown

Page 40Component models

IUnknownIUnknown

Contains only three methods

HRESULT QueryInterface(GUID iid, void **iptr);

ULONG AddRef();

ULONG Release();

QueryInterface is used for Interface Navigation

AddRef and Release is used for reference counting

A form of collaborative carbage collection

Page 41Component models

IDL ExampleIDL Example

interface ISpellCheck : IUnknowninterface ISpellCheck : IUnknown{

HRESULT check([in] BSTR *word, [out] bool *correct[in] BSTR *word, [out] bool *correct);}; interface ICustomSpellCheck : IUnknowninterface ICustomSpellCheck : IUnknown{

HRESULT add([in] BSTR *word[in] BSTR *word);HRESULT remove([in] BSTR *word[in] BSTR *word);

}; library SpellCheckerLiblibrary SpellCheckerLib{

coclass SpellCheckercoclass SpellChecker{

[[default] interface ISpellCheck;default] interface ISpellCheck;interface ICustomSpellCheck;interface ICustomSpellCheck;

};};

Page 44Component models

Creating a local objectCreating a local object

ObjectObject

Server

Client Application

Client Application

COM LibraryCOM Library

1. CoCreateInstance

3. Return pointer to interface

4. Invoke methods

2. Locate server object

CLSID_X

CLSID_Y Path to server Y

Path to server X

Registry

Page 46Component models

Creating a remote objectCreating a remote object

ObjectObject

Server

Client Application

Client Application

COM LibraryCOM Library

1. CoCreateInstance

2. Locate server object

3. Return pointer to interface

4. Invoke methods

CLSID_X

... ...

C:\X.exe

Registry

CLSID_X

CLSID_Y D:\Y.exe

Idt.mdh.se

Registry

Idt.mdh.semrtc.mdh.se

Page 47Component models

Microsoft Application Server TechnologiesMicrosoft Application Server Technologies

COMApplications

COMApplications

MTS

IISIIS

Windows NT

DBMSDBMS

DBMSDBMS

DBMSDBMS

ASPApplications

ASPApplications

ADOADO

ADOADO

BrowserClient

BrowserClient

RichClient Rich

Client

HTTP

DCOM

VBVC++VJ++

VBVC++VJ++

VisualInterDevVisual

InterDev

Page 48Component models

CORBA CORBA

andand

Component Model (CCM)Component Model (CCM)

Page 49Component models

CORBACORBA

Common Object Request Broker Architecture

Standard for writing distributed object systems

Language independent

Not controlled by one company

Optional value added services

Page 50Component models

CORBA (Common Object Request Broker Architecture)

CORBAapps CORBAdomains CORBAfacilities

CORBAservices

OMA OverviewOMA Overview

TransactionsTransactions EventEvent SecuritySecurity NamingNaming

OMA–Object Management Architecture

Page 51Component models

Page 52Component models

Remote invocationRemote invocation

Page 53Component models

CORBA 3.0CORBA 3.0

Internet Integration

Firewall Specification

Interoperable Name Service

Quality of Service Control

Asynchronous Messaging and Quality of Service Control

Minimum, Fault-Tolerant, and Real-Time CORBA

The CORBAcomponent architecture

Components

Scripting

Page 54Component models

Page 55Component models

CORBA ORB architectureCORBA ORB architecture Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation,

which is known as a Servant. Servant -- This is an implementation programming language entity that defines the operations that support a

CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.

Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.

Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.

ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.

CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.

Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.

Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

Page 56Component models

CORBA Component ModelCORBA Component Model

A Framework for Server Applications

Built on the Portable Object Adaptor

Provides interfaces for CORBA Services

transactions

security

events

persistence

Uses Callbacks for instance management

Empty container for user-defined frameworks

Page 57Component models

CORBA Component ModelCORBA Component Model

A component interface is made of ports divided into:

Facets - for interaction with clients

Receptacles – references o external code

Event sources

Event sinks

Component interface

AttributeFacet

Event source

Event sink

Ports

Receptacle Segment

Component implementation

Page 58Component models

Defined Container FrameworksDefined Container Frameworks

ComponentComponentComponentComponent

Con

tain

erORB/POA

Transaction Security Persistence Events

Callback InterfacesCallback Interfaces

Internal InterfacesInternal Interfaces

ExternalExternalInterfacesInterfaces

Page 59Component models

Real-Time CORBAReal-Time CORBA

See RT-CORBA page 18…

Page 60Component models

Portable End-to-End PrioritiesPortable End-to-End Priorities

• Problem: How can we map global priorities onto heterogeneous native OS host thread priorities consistently end-to-end?

• Solution: Use Standard RT CORBA priority mapping interfaces

Page 61Component models

Obtaining Portable ORB End-system PrioritiesObtaining Portable ORB End-system Priorities

ORB ENDSYSTEM A

32767

0

RT

CO

RB

A::P

riority

255

0

0

31

Native P

riority

Native P

riority

ORB ENDSYSTEM B

OS-independent design supports heterogeneous real-time platforms

CORBA priorities are “globally” unique values that range from 0 to 32767

Users can map CORBA priorities onto native OS priorities in custom ways

No silver bullet, but rather an ``enabling technique'‘

i.e., can’t magically turn a general-purpose OS into a real-time OS!

Page 62Component models

Preserving Priorities End-to-End

• Problem: How can we ensure requests don’t run at the wrong priority on the server?• e.g., this can cause major problems if edge_alarm() operations are processed too late!!!

• Solution: Use RT CORBA priority model policies

Page 63Component models

Preserving Priorities End-to-EndPreserving Priorities End-to-End

RT CORBA priority model policiesSERVER_DECLARED

Server handles requests at the priority declared when object was created

CLIENT_PROPAGATEDRequest is executed at the priority requested by client

Priority is encoded as part of client request

ServerClient

1. Server Priority is pre-set

2. Priority is exported in IOR

3. Priority is NOT propagated by invocation

Middle-tierServer

Client

ServiceContext

priority = 100QNX

priority = 16

LynxOSpriority = 128

ServiceContext

priority = 100

Server Solarispriority = 136

SERVER_DECLARED

CLIENT_PROPAGATED

Page 64Component models

Problems that RT-CORBA solvesProblems that RT-CORBA solves

• Problem: How can RT-CORBA client application change the priority of operations?

• Problem: How to ensure that certain operations always run at a fixed priority?

• Problem: How can we prevent bursts or long-running requests from exhausting maximum number of static & dynamic threads in the lane?

• Problem: How can we support real-time applications that need more buffering than is provided by the OS I/O subsystem

• Problem: An ORB & application may need to use the same type of mutex to avoid priority inversions

e.g., using priority ceiling or priority inheritance protocols

Page 65Component models

Problems that RT-CORBA solvesProblems that RT-CORBA solves

• Problem: How can we minimize priority inversions, so that high-priority operations are not queued behind low-priority operations?

• Problem: How can we handle the fact that CORBA one-way operation semantics aren’t precise enough for real-time applications?

Problem: How can we simultaneously

Prevent clients from blocking while long-duration requests complete &

Allow many requests to be issued concurrently

Page 66Component models

Concluding Remarks RT-CORBAConcluding Remarks RT-CORBART CORBA 1.0 is a major step forward for QoS-enabled middlewaree.g., it introduces important capabilities to

manage key ORB end-system/network resources

We expect that these new capabilities will increase interest in--and applicability of--CORBA for distributed real-time & embedded systems

RT CORBA 1.0 doesn’t solve all real-time development problems, however

It lacks important features:Standard priority mapping managerDynamic scheduling

– Addressed in RT CORBA 2.0

Portions of spec are under-specifiedThus, developers must be familiar with the implementation

decisions made by their RT ORB

• Our work on TAO has had the following impact:•Advanced middleware for distributed real-time & embedded systems by implementing RT CORBA in an open-source ORB

•Provide feedback to users & OMG•Provide affordable access to RT CORBA

StandardCOTS

R&D

UserNeeds

R&D

Page 67Component models

minimumCORBA minimumCORBA

minimumCORBA defines a profile (or subset) of CORBA, whereas CORBAservices, CORBAsecurity etc. define optional extensions to the CORBA specification.

Page 68Component models

.NET.NET

Page 69Component models

What is .NET?What is .NET?

NET is a platform that enables:

Software as services, especially over the web

Distributed computing

Componentization

Enterprise services

Page 70Component models

.NET Platform .NET Platform

Operating Systems

Common Language Runtime

Base Class Library

ADO.NET and XML

ASP.NET Windows Forms

Common Language Specification

VB C++ C# JScript …V

isual S

tud

io.N

ET

Page 71Component models

.NET Framework Components.NET Framework Components

Common Language Runtime (CLR)

Common type system for all languages

Runtime environment

Class libraries (.NET Framework)

Base class libraries, ADO.NET and XML

Windows Forms for, Win32 applications

Web application platform ASP.NET

Interactive pages

Web services that are SOAP enabled

Page 72Component models

.NET Component Model - .NET Component Model - ImplementationImplementation

A component (assembly) is made of modules, which are traditional executable files (DLL).

Modules cannot be assemblies, thus the .NET model is not hierarchical.

Component interface

Attribute

Method

Event source

Ports Component implementation

Modules

Page 73Component models

FrameworkFramework

.NET relies on the traditional programming approach : the framework is seen as the language run-time support.

MISL – Microsoft Intermediate language (similar to Java Byte code)

Common Runtime Language (similar to Java Virtual Machine)

Transaction control relies on MTS.

Page 74Component models

LifecycleLifecycle

Assemblies (and their modules) are local to an application, and thus different DLLs with same name can run simultaneously.

Each assembly has a versioning information about itself and about the assemblies it depends on.

Version control is delegated to the dynamic loader, which selects the “right” version.

Significantly improve the application packaging and deployment.

Page 75Component models

Other component modelsOther component models

OSGI Component Model

KOALA component model

IEC 61131-3 standard languages (functional blocks)

Real-time components

Page 76Component models

CC

C2

C1

C3

ms

A Koala ComponentA Koala Component

A module

A switchInterfaces

Subcomponent