Component Models Agenda Introduction to Components

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

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 " 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 " business process objects " presentation objects " business object components

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 " presentation objects " " visual representation of the object business object component " business object, one or more presentation objects, and a process object

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 " 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 " 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 " 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 " 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 " create " find " persisted object " find by diverse criteria " passivate/activate " remove " move, copy " CORBA interface exists; responsibility of programmer to implement

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 " 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 " 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 " 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 " 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 " 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 " identify and authenticate user " authorize: provide/prevent access " audit " secure communicated data " administer

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 " Generic set of interfaces for vendors to provide access to their licensing tools

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