component models l.
Skip this Video
Loading SlideShow in 5 Seconds..
Component Models PowerPoint Presentation
Download Presentation
Component Models

Loading in 2 Seconds...

play fullscreen
1 / 44

Component Models - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Component Models

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • Introduction to Components
  • Object/Component Services
  • Component Examples
  • Component Models
    • DCOM & MTS
    • CORBA
    • Enterprise Javabeans
introduction to components
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,, 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
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 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
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
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
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
  • 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
businesses and components
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
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/Components
  • business objects
  • business process objects
  • presentation objects
  • business object components
business objects components described
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 described15
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
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
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
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
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 services20
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 services21
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
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
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
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
Concurrency Control Service
  • Designed for use with Transaction Service
  • General lock management model
  • Five levels of locking granularity to control overhead
relationship service
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
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
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
Security Service
  • identify and authenticate user
  • authorize: provide/prevent access
  • audit
  • secure communicated data
  • administer
query service
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
Licensing Service
  • Generic set of interfaces for vendors to provide access to their licensing tools
property service
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
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
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
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
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
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
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
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 models40
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
  • 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
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 javabeans44
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