Скачать презентацию Component Models Agenda Introduction to Components Скачать презентацию Component Models Agenda Introduction to Components


  • Количество слайдов: 44

Component Models Component Models

Agenda Agenda " 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, 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 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: " " applied recursively " scaled " instantiated any number of times " " parameterized 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

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

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 Described 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 " 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 Services 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 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 how objects are related to each other roles 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 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 objects not under your control " " for purchased objects 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.

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 components are sufficiently abstract to mean something to deploying client 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 " " contract between consumer and supplier " " link between business requirement and implementation fundamental architectural decision no standard for describing a service " " signature only tells how to communicate with 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 Models Component Models " explicit support for components, e. g. : " " location transparency " " interface definitions dynamic assembly model defines " " component interfaces " " architecture of components interaction with component execution environment we’ll deal with server-side component models

DCOM & MTS 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 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 Enterprise Javabeans " a standard server-side component model " adaptable to existing products, e. g. : " " " transaction processing monitors " " naming servers DBMSes wanted flexible integration and solid support for mission-critical app development defuse fear of locking into a vendor

Enterprise Javabeans: Enterprise Javabeans: " a standard server-side component model " adaptable to existing products, e. g. : " " " transaction processing monitors " " naming servers DBMSes wanted flexible integration and solid support for mission-critical app development defuse fear of locking into a vendor