Component Models

Agenda

Introduction to Components Object/Component Services Component Examples Component Models

DCOM & MTS CORBA Enterprise Javabeans

Introduction to Components

Component Software, Clemens Szyperski, Addison Wesley, 1998

Raising Components, J. Williams, Application Development Trends, Sept. 200

Component Based Development Using Componentised Software, www.cbdiforum.com, Nov. 1999

Problem failure to deliver quality software at right time inhibits business prepackaged applications not satisfactory due to:

integration problems inflexibility difficulty in upgrading cost

Characteristics of Desirable Solution

must be adaptable to business and technology changes

must be easily and rapidly upgradeable must be piecewise replaceable must be customizable to business requirements must support integration of other packages

Components Are A (The) Solution

components collaborate at semantic level to do task

Issues: What is a component? Why aren’t objects a solution? How do components that have no previous knowledge of

each other collaborate? How can components help in improving quality? How can components help in improving delivery times?

Analogies for Components

hardware components,ICs doesn't reflect true nature of SW

deliver blueprint/plan of product, not final product computers instantiate software; measures must be taken to

prevent copies

must distinguish between software and its instances, plans and a building, etc.

Analogies for Components:Confusing Abstraction & Instances plans can be:

parameterized applied recursively scaled instantiated any number of times delivered; instances created from its parameterization

instances can't

Analogies for Components:Math

math characterization isolation of aspects, their orthogonal treatment, their static

capturing

fails to capture engineering and marketing aspects

functional & non-functional, interacting whole reuse, time to market, quality, viability

Components

parts meant to be assembled into a larger part implications

components come in various sizes components meet at an interface components are units of sale

But… components provide services rather than a physical

manifestation -- more like a catalog entry describing characteristics than a particular piece of hardware

components are not the same as software objects

Objects vs. Components

Object Component

unit of instantiationunit of independent deployment

unit of composition

unique id no id

has state (can be persistent) no persistent state

encapsulates state and behavior does not

instantiated from class might consist of one or more classes

can depend on other classes viainheritance

can depend on other components (controlled, explicitdependencies)

constructor is used to initialize at runtime

can be parameterized to configure it at deployment

Businesses and Components

business services as components makes them reusable, replaceable and upgradeable services approach matches business operation supports drive toward web black box components

lessen dependencies and can be certified component reuse more productive than code reuse larger chunk size is better fit for work assignment well-defined and stable interfaces ease integration can buy or outsource at higher level than code

Business Objects Instant CORBA, R. Orfali, D. Harkey, J. Edwards, Wiley & Sons, 1997

"self-contained deliverable that has a user interface, state, and knows how to cooperate with other separately developed business objects"

application-independent concepts that represent real-world concerns, recognizable by an end user

application provides an environment to execute business objects must have dynamic binding and well-defined interfaces to be

implemented independently must recognize events in its environment, change attributes, and

interact with other business objects variation of MVC pattern

Business Objects/Components

business objects business process objects presentation objects business object components

Business Objects/Components Described

business objects encapsulate storage, metadata, concurrency, business rules

for an entity, and how object reacts to changes in view or model

business process objects business logic at enterprise level for long-lived processes defines how object reacts to environmental changes, such

as from a business transaction or a message from another business object

Business Objects/Components Described

presentation objects visual representation of the object

business object component business object, one or more presentation objects, and a

process object

Characteristics of Components

identifiable for recognition and reference traceable throughout development to allow replacement replaceable by components with same services accessible only through interfaces to avoid implementation

dependencies interfaces are immutable to allow replacement interfaces are accurately documented

Optional Characteristics of Components

hidden physical implementation independent of implementation of other components encapsulation of implementation independent of language, tool or platform runtime assembly and upgrading services are generic well-defined means of extending object-oriented behind interface

Why Objects Failed to Solve Application Development Problems

Objects have internal dependencies (inheritance) what happens to object instance’s inherited methods when superclass

changes? Name space collisions were common No standards were available to interface objects Don’t really want object instances, want classes "A map is not the territory it represents, but if correct, it has a

similar structure to the territory, which accounts for its usefulness” - Alfred Korzybski, father of general semantics

No notion of independence or late composition Object technologies ignore aspects of economies, markets,

technical consequences

Object/Component Services

Why? problem: change, adaptation, unforeseen contexts on server

side solution: flexibility by replaceable modules, enabled by

separation of concerns

Basic issues remove communication dependencies: use proxies locate objects by name: use brokers hide details, enable reusability and reconfiguration but: slower performance, more points of failure

Object/Component Services

More basic issues create objects: use factories find factories: use directories not enough room for all objects: use passivation/activation services not always available: use asynchronous messaging reduce dependencies on infrastructure: use containers maintain long-term state: use stable storage to persist coordinate among multiple entities: use transactions etc.

Object/Component Services

From: CORBA Fundamentals and Programming, J. Siegel, Wiley & Sons, 1996

CORBAservices life cycle, naming, persistence, event notification* transaction*, concurrency control, relationship,

externalization security, time query, licensing, property trader, collections, startup

Object Life Cycle Service

create find

persisted object find by diverse criteria

passivate/activate remove move, copy

CORBA interface exists; responsibility of programmer to implement

Naming Service

Primary services bind name to object lookup object bound to name and return reference

allows hierarchy of names can’t associate anything else with name

see Trader Service

Persistent Object Service

Transient objects common allow for garbage collection

from client’s view, object instance always there datastore: e.g., flat files, relational or OO DBMS ways to control persistence

connection: state is maintained by infrastructure store/restore: state is maintained by programmer

Concurrency Control Service

Designed for use with Transaction Service General lock management model Five levels of locking granularity to control

overhead

Relationship Service how objects are related to each other roles

e.g., employment relationship: employer and employee multiple roles per object allowed

nodes collection point for all roles an object has traversal of all nodes exactly once useful for operations like move and copy when

role and node objects serve as proxies allows objects that don’t include relationships to have them allows tracing and traversing independent of objects

Relationship Characterizations Type

e.g., ownership type relates person and car

Role Degree

number of required roles e.g., 3 for book checkout: library, book, patron

Cardinality maximum number of relationships involving role e.g., employer has many employee relationships

Semantics: attributes and operations of relationship e.g., due date attribute for book checkout

Externalization Service

Recording and playing back an object’s state as a stream

like what in Java? like what other service?

But not dynamically stored

externalize/internalize: like life cycle move/copy, but:

no way to specify destination internalization possible without network connection to existing

object internalization may be delayed for long periods of time, if at all

Security Service

identify and authenticate user authorize: provide/prevent access audit secure communicated data administer

Query Service

provides single source for querying all objects standard query language standard interfaces to query evaluators (which

abstract access to object/DBMS/etc.) standard collections of objects query evaluators to implement standard interface

Licensing Service

Generic set of interfaces for vendors to provide access to their licensing tools

Property Service

Provides ability to add/delete and get/set external attributes (name/value pairs) with an object

for purchased objects for objects not under your control for attributes not normally associated with the object

Could also be done with Relationship Service

Trader Service

a.k.a. directory (as in phone yellow pages) service

discovery of services vs. request for a service server objects

register what services they offer register other properties, such as cost of service, hours of

operation, etc.

clients may specify desired properties such as location, implementation language, etc. <gasp!>

Component Examples

operating system applications

coarse grained components in OS environment interoperable by files or pipes

relational DB engines TPMs Visual BASIC plug-ins for browsers and graphics apps

Component Examples:Characteristics

all have rich infrastructure all are substantial enough: too difficult or not

cost-effective to hand develop none are really good with arbitrary composition

Component Features

components are sufficiently abstract to mean something to deploying client

e.g., VB: visual representation, displayable & editable properties, meaning closely associated with appearance

component construction requires lot of training and qualifications

component assembly: composition and integration for more widespread use

objects not usually set up for arbitrary composition, configuration and integration -- difficult to sell

Component Issues

Interface link between business requirement and implementation contract between consumer and supplier fundamental architectural decision

no standard for describing a service signature only tells how to communicate with component

componentisation implementation of a set of concepts applied to application

life cycle with emphasis on separation, evolution, and services-based reuse

Component Granularity

units of release -- a meaningful, related collection implementation-specific components

lowest level of abstraction (e.g., class libraries) business components

meaningful services focused on a particular business concept component frameworks

collection of items reusable as group, but not a complete application

prebuilt assembly of components, with glue logic and extendability application components

complete application can be wrapped with interfaces to appear as a component

Component Drawbacks

licensing policies may hinder reuse -- pay for each copy in a failover/recovery situation

fundamental differences in component architectures EJB application server incompatibilities vendor-specific enhancements

lack of desire to interoperate keeping track of components to maximize reuse component repositories lack of trust in functionality or reliability of components lack of methodology for building components and

component-based systems

Component Models

explicit support for components, e.g.: interface definitions location transparency dynamic assembly

model defines architecture of components component interfaces interaction with component execution environment

we’ll deal with server-side component models

DCOM & MTS

DCOM: distributed component service MTS

Microsoft Transaction Server server-side component model

transaction management, concurrency, resource management, etc. property sheets change how business objects interact with

services

proprietary platform stateless components only

high performance but limited flexibility

CORBA

The non-proprietary distributed object service ORBs

language, platform, OS, communication independence but, developer had to code to complex, low-level API

CORBAcomponent Model (CCM) Enterprise Javabeans with language independence

Enterprise Javabeans

a standard server-side component model adaptable to existing products, e.g.:

naming servers transaction processing monitors DBMSes

wanted flexible integration and solid support for mission-critical app development

defuse fear of locking into a vendor

Enterprise Javabeans:

a standard server-side component model adaptable to existing products, e.g.:

naming servers transaction processing monitors DBMSes

wanted flexible integration and solid support for mission-critical app development

defuse fear of locking into a vendor