Component Models

1
Component Models
2
Agenda

• Introduction to Components
• Object/Component Services
• Component Examples
• Component Models
• DCOM MTS
• CORBA
• Enterprise Javabeans

3
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

4
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

5
Components Are A (The) Solution

• components collaborate at semantic level to do
  task
• Issues
• What is a component?
• Why arent 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?

6
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.

7
Analogies for ComponentsConfusing Abstraction
Instances

• plans can be
• parameterized
• applied recursively
• scaled
• instantiated any number of times
• delivered instances created from its
  parameterization
• instances can't

8
Analogies for ComponentsMath

• 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

9
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

10
Objects vs. Components
11
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

12
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

13
Business Objects/Components

• business objects
• business process objects
• presentation objects
• business object components

14
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

15
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

16
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

17
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

18
Why Objects Failed to Solve Application
Development Problems

• Objects have internal dependencies (inheritance)
• what happens to object instances inherited
  methods when superclass changes?
• Name space collisions were common
• No standards were available to interface objects
• Dont 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

19
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

20
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.

21
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

22
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

23
Naming Service

• Primary services
• bind name to object
• lookup object bound to name and return reference
• allows hierarchy of names
• cant associate anything else with name
• see Trader Service

24
Persistent Object Service

• Transient objects
• common
• allow for garbage collection
• from clients 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

25
Concurrency Control Service

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

26
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 dont include relationships
  to have them
• allows tracing and traversing independent of
  objects

27
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

28
Externalization Service

• Recording and playing back an objects 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

29
Security Service

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

30
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

31
Licensing Service

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

32
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

33
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. ltgasp!gt

34
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

35
Component ExamplesCharacteristics

• all have rich infrastructure
• all are substantial enough too difficult or not
  cost-effective to hand develop
• none are really good with arbitrary composition

36
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

37
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

38
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

39
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

40
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
• well deal with server-side component models

41
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

42
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

43
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

44
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