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