1 / 44

Component Models

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

Donna
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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?

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

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

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

  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 • can’t associate anything else with name • see Trader Service

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

  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 don’t 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 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

  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. <gasp!>

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

  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 • we’ll 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

More Related