Components Models and ComponentBased Architectures

1
Components Models andComponent-Based
Architectures

• Jean-Marie Favre Univ. of Grenoble Jacky
  Estublier CNRS Grenoble

2
Issues related with software composition
3
Issues related with software composition

• Software complexity and size is ever increasing
• Millions lines of code
• Code from many different parties, legacy
  software, component-of-the-shelves
• Complex and fuzzy software architectures
• Software evolution and adaptation
• Issues
• How to compose software  from components ?
• How to share and reuse components ?
• Idea
• Removing connections from source code
• Opportunities
• Reuse work on software architecture and new
  techniques

4
Traditional software applications

• Unclear structure
• Dependencies buried deeply into source code
• Almost impossible to replace a component
• Almost impossible to reconfigure the application
• Recompilation issues
• Issue to managed shared code
• Evolution in techniques for
• connecting software units
• customizing software units

traditional software application
5
Evolution in connecting software units (1/2)

• Absolute addressing
• Goto 76302
• Static linking
• Separate compilation, do not require source code
• Enable software production by different teams
• Linking information are removed
• Do not support reconfiguration at runtime
• Issues in sharing code

6
Evolution in connecting software units (2/2)

• Dynamic linking
• Software units are bound at load time or during
  execution
• Binary objects contain (meta)-information about
  software units
• Minimal support for introspection
• Global name space per application (classpath,
  path)
• Dynamic lookup
• Provided by middleware infrastructure
• Client request a query, not just a symbol
• (Meta-)information is attached to each software
  unit

7
Parametrizing software units

• Compile time parametrisation
• E.g. constant definitions
• Require access to source code
• Recompilation gt  ripple effect 
• Load time parametrisation
• Environment variables (e.g. unix), configuration
  and resources files
• Using these mecanisms is tricky
• No support to check the consistency of a
  configuration
• Almost every software product is based on this
  kind of techniques

8
Explicit software architectures

• Components
• clearly defined boundaries
• customizable properties
• Connections
• explicit and modifiable
• outside of source code
• Enable
• component substitution
• application reconfiguration
• ... even at run-time
• distributed applications

9
Issues related with non-functional aspects
10
Issues related with non functional aspects

• Any large application involve (or will involve)
  non-functional aspects
• Distributed computing
• Persistence of data in various forms
• Transaction management and support for
  concurrency
• Security, reliability, availability ...
• Issues
• Dealing with these aspects is tricky
• Specific skills are required
• Idea
• Remove non functional code from source code
• Opportunity
• Reuse services provide by software
  infrastructures (e.g. middleware)

11
At the beginning compilers
Executable
Compilation
Programming Environnement
Operating System
12
Then came dynamic link editors
Executable
Programming Environnement
Operating System
13
Progress

• Some properties have been added to the program
• Better memory management
• Less compilation dependencies
• Module Substitution before or during execution
• Without any need to mention it in the source
  code.
• Thus
• More administration freeness
• Better adaptability
• Better efficiency
• .
• Enabling Technology
• Introspection.
• Execution support.

14
Distribution
Stub
Programming Environnement
Operating System
15
Programminglanguages
16
Architecture Descriptions Languages
Design approach
Descriptionof softwarearchitecture
Behaviorspecification
Analysis
EJB
CORBA2
MTS
ORB
PITL approach A language for each facet
Security,
Distribution
Transaction
DCOM
COM
COM
CCM
JavaBeans
Improvecomponent independence
Programminglanguages
Ease component implementation
Composition
Sun JVM
Language approach Extend the language with new
constructs
MS CLR
Virtual Machine
17
Evolution of software infrastructures
Time

• The level of abstraction is rising
• Reuse services provided by software
  infrastructure
• Remove non-functional code from software
  applications

18
Modern software infrastructure

• Modern middleware (e.g. Corba) provides many
  services
• Memory (life-cyle) management
• Naming / trading services
• Persistence services
• Distribution services
• Migration services
• Security services
• Transaction services
• Multi-language services
• ...

19
Example of services distribution
20
Other examples of services (1/2)

• Multi-language interoperability
• Two components ...
• ... implemented in two different languages
• Security
• Does component A have the rights to call B ?
• Security policy, domains, ...

Language 1
Language 1
21
Other example of services (2/2)

• Persistence and life-cycle management
• Does the component have a state ?
• Is this state persistent among sessions ?
• Should the component be duplicated to improve
  performance ?
• Manage operations like
• creation
• destruction
• retrieval
• activation
• passivation
• Extend traditional object-oriented life cycle
• Deal with various persistent stores (local or
  remote)

22
Summary

• New organisational issues
• many actors with differents skills
• different organisations collaborating
• from development, to assembly, deployment and
  execution
• Build on advances in software architecture
• how to remove connections from source code ?
• how to simplify the customization of each
  component ?
• Build on improved software infrastructures and
  middleware
• how to remove non functional code from source
  code ?
• adding and customizing services in a transparent
  way at deployment time

23
Component definitions
24
Component definitions (1)

•  A component is a non trivial, nearly
  independent, and replaceable part of a system
  that fulfills a clear function in the context of
  a well-defined architecture. A component conforms
  to and provides the physical realization of a set
  of interfaces. 
• Philippe Krutchen, Rational Software

25
Component definitions (2)

•  A runtime software component is a dynamically
  bindable package of one or more programs managed
  as a unit and accessed through documented
  interfaces that can be discovered at runtime
• Gartner Group

26
Component definitions (3)

•  A software component is a unit of composition
  with contractually specified interfaces and
  explicit context dependencies only. A software
  component can be deployed independenty and is
  subject to third-party composition
• Clemens Szyperski, Component Software

27
Component definitions (4)

•  A business component represents the software
  implementation of an  autonomous  business
  concept or business process. It consists of the
  software artifacts necessary to express,
  implement and deploy the concepts as a reusable
  element of a larger business system
• Wojtek Kozaczynski, SSA

28
Component definitions (5)

• "A Java Bean is a reusable software component
  that can be manipulated visually in a builder
  tool. ... First a bean must be capable of running
  inside a builder tool. Second, each bean must be
  usable at run-time within the generated
  application.
• Java Bean Specification, Sun Microsystem

29
Component definitions (6)

• A software component is a software element that
  conforms to a component model and can be
  independently deployed and composed without
  modification according to a composition standard
• G. Heineman, W. T. Council,  Component-based
  Software Engineering Addison Wesley, 2001

30
Component definitions (7)

• Components
• are reusable units
• have clear and explicit boundary and dependencies
  
• can be customized
• can be assembled
• are units of distribution
• are units of substitution
• are units of deployment
• have certified properties
• Software Engineering Institute

31
Component technology in practice
32
Current component technologies

• In-house component technologies
• e.g. Dassault Systèmes  Object Modeler 
• Ericsson, ..
• Standard component technologies
• Microsoft COM / DCOM / COM / .NET/C
• Sun JavaBeans, Entreprise Java Beans (EJB)
• OMG Component Model (CCM)
• OSGI
• ...
• From internal use to external use

33
Difficult to study and compare

• Different applications domains
• DS OM cad/cam
• JavaBeans graphical user interface
• EJB, .NET, .CCM internet-based applications,
  client-server
• OSGI set top boxes, small devices, ...
• Industrial solutions to solve day to day
  industrial problems
• Technical solutions, No clear concepts
• Complex (to very complex) technologies
• Incremental evolution

34
Elements of a component technology

• A component model
• defines the essential concepts and their
  relationships
• An implementation model
• provides implementation techniques to implement
  components
• coding standard
• A set of tools
• code generator(s), assembler tool(s), deployment
  tool(s), wizards, ...
• A (set) of component infrastructure (s)
• runtime infrastructure / assembly time
  infrastructure
• interpreter code libraries (APIs) /
  virtual machine
• Documentation
• standard specifications, APIs description,
  tutorial, ...

35
Component model

• Define essential concepts
• e.g.
• components
• event sources
• receptacles
• facets
• ...
• ... and their relationships ...
• a component  implements  one or more interface,
  ...
• component composition rules ...
• protocol of interaction with the infrastructure,
  with the tools, ...
• ... all this at a conceptual level.

Property
Method
Event source
Event sink (listener)
Bounded property
36
Component model vs. component language

• All component technology defines new concepts
• ... but usually no new language
• (CCM and .NET/C are exceptions)
• Defined in terms of underlying implementation
  patterns
• No separation between important concepts and
  technical details
• Sometimes defined only through obscure APIs and
  few samples ( how to ?)
• No stable definition
• Issues in
• implementing components
• using components
• understanding and maintaining component-based
  software

37
Conceptual level vs. Implementation level

• No direct mapping
• A single concept -gt many implementation entities

• different implementation strategies
• implementation spread in many different artefacts
  (e.g. source code, XML files, raw files, ...)
• use of low level mecanisms (e.g. macro directives)

38
Exemple
Concept vs. Implementation

• A java bean property

impl. level
generated code
conceptual level
39
Different points of comparison

• Interface of a component
• external view of a component (clients view)
• Composition of components
• how component are assembled together ?
  (assemblers view)
• Implementation of a component
• how component are implemented ? (implementers
  view)
• Life cycle
• Life Cycle
• Infrastructure and services
• interaction beetween components and
  infrastructures

40
Graphical Conventions (1/2)
41
Graphical Conventions (2/2)
Traditional software entities
Components
Component Infrastructure
42
Example
Infrastructure
43
Microsoft COM, DCOM, COM
44
Objectives

• Origin composite document
• Improve independence between software units
• Interoperability between programming languages
• Extensibility of components
• DCOM extends COM with distribution
• MTS extends DCOM with persistency and transaction
  support (COM)

45
Features

• Specific to Windows platforms
• Targets C and VB languages
• Binary interoperability
• Relies on the Interface concept (A C virtual
  class)
• Relies on a simple protocol
• A special interface IUnknown.
• Query Interface
• AddRef, FreeRef, IsA
• Factory

46
D/COM/
47
D/COM/

• Interface
•  Interface  (set of methods, e.g. virtual class
  C).
• Provided but not required.
• Assembly.
• programming, wizard tools for distribution
• Implementation
• Multi-object components, containment or
  aggregation.
• Life Cycle
• Implementation and execution.
• Infrastructure
• Simple protocol interpreter
• DCOM COM RPC.
• MTS transactions, persistence .

48
Microsoft .NET / C
49
Objectives

• Basis for a new generation of Microsoft operating
  systems
• Based on components and web services
• Ease the development of internet-based
  applications
• Take the best of Java platform and improve some
  aspects
• Fix the many issues of D/COM/ and Windows

50
Features

• Does not rely on COM anymore
• .NET is a complex infrastructure with many layers
  and techniques
• Microsoft technologies (e.g. ASP)
• Web techniques SOAP, XML, HTTP, SMTP, ...
• The infrastructure provides services for web
  applications
• e.g. web forms, persistence, distribution,
  security
• Language interoperability
• Deployment improvement to avoid the Windows
   DLL hell 
• Development through many wizards...

51
Run-time infrastructure

• Very similar to Java platform
• MSIL (MS Intermediate Language)
• byte code
• CLR (Common Language Run time)
• virtual machine
• Improvement
• security
• version management, ...
• Mixture of  supported  and  non supported 
  code
• Supported MSIL, executed by the CLR.
• Not supported native code.

52
Multi-language support

• Supported Languages
• MS C, C, Visual Basic, JScript.
• Others Eiffel, APL, CAML, Cobol, Pascal,
  Python, Scheme , Java, ...
• Are C, Fortran, Eiffel ... become equivalent
  language ?
• Of course not!
• Restrictions due to CLR
• e.g. multiple inheritance prohibited in C
  (templates, types, ....)
• additional annotations
• syntactic sugar to ease the .NET adoption by
  programmers
• C is a concrete syntax

53
C language

•  The first component-oriented language of the
  C/C generation 
• Very similar to Java JavaBeans !
• Garbage collector
• Class and single inheritance interface and
  multiple inheritance
• Include JavaBeans concepts
• property, indexed property
• events
• Arbitrary annotations (attributes) to attach meta
  information
• e.g. xml documentation ( javadoc)
• non functional properties (e.g. WebMethod)
• extensible (developer can define new types of
  attributes)

54
 Assembly 

• Component with clearly identified boundary
• provided features
• required features
• arbitrary meta information
• precise version control

55
(No Transcript)
56
Deployment Windows  DLL hell 

• Windows issues
• DLLs are shared (by the system and all the
  applications!)
• The last one that changes a DLL impacts
  everybody...
• Can be tricky (Control X downloaded by the net
  ...).
• No log, no protection ...
• Windows requires a single version of an
  application and DLL
• Windows do not version interfaces (immutable)
• Require developers to produce  fully backward
  compatible  software
• Require users to reboot their machines

57
Deployment Issues

• More problems
• The  Registery  is modified when an application
  is installed
• Serious issues to desinstall, duplicate, and
  update applications
• Distributed applications must have consistent
  registries on all machines
• Reconfiguration during runtime is almost
  impossible
• Applications are neither  self-described  nor
   self-contained 

58
.NET solutions

•  self-described  applications via the use of
   assemblies 
• No registry (simplifies install/desinstall)
• Explicit management of versions
• Record the  last known good  Reinstall a
  stable install in case of problem.
•  side-by-side  Allow multiple versions of the
  same application to run on the same machine.
• Caller can specify the required version
• By default an application is isolated from the
  others

Major Minor Build Revision
Incompatible Compatible (QFE )
59
.Net / C

• Interface
• Generated by the compiler gt allows
  introspection.
• Assembly
• The manifest contains the assembly Assembly
  descriptor.
• Realization
• An  assembly  is a set of  modules .
• Life cycle.
• Development, deployment, execution
• Infrastructure
• CLR, service for web applications

60
OMG Corba Component Model (CCM)
61
Objectives

•  A server-side component model for building and
  deploying CORBA applications 
• An architecture for defining server components
  and their interactions
• A packaging technology for deploying binary,
  multi-languages, executables
• A container framework for injecting security,
  transactions, events, and persistence
• A CORBA container for Sun Enterprise Java Beans
  (EJB)

62
Features

• Extension of Corba 2, part of Corba 3
  specification
• Modern component technology
• Not yet fully implemented
• Many features and languages
• Abstract Component Model extensions to IDL and
  the object model
• Component Implementation Framework Component
  Implementation Definition Language (CIDL)
• Component Container Programming Model
• Component Metadata Model (MOF extensions)
• Open standard
• Multi-language, multi-plateform

63
Concepts

• CORBA Concepts
• Objects
• Types
• Modules
• Attributes
• Operations
• Requests
• Exceptions
• Subtypes

• CCM CORBA
• Component
• Ports
• Features
• Facets
• Receptacles
• Events
• Home
• Configurations
• Containers
• Composition
• Transaction
• Persistence

64
Languages to describe components

• IDL interface description language
• Language to describe interface of a components
• Client s view, external view
• Ports
• Home type
• ...
• CIDL component implementation description
  language
• describes implementation of components
• maps abstract level to implementation one
• realization choice for non functional aspects
  (e.g. transaction, ...)
• links Segments with real binary artifacts

65
Packaging

• Component Package
• Group all implementations of a component with its
  IDL and properties
• Dependencies and requirements for each
  implementation,
• User s binary code and generated binary code

66
(No Transcript)
67
(No Transcript)
68
(No Transcript)
69
(No Transcript)
70
(No Transcript)
71
Home

• Associated with 1 component type.
• Managed component instance lifecycle.
• Contains and manages the components instances
• Keys for instances identification
• Equivalent to constructor/destructor in
  object-oriented languages

C1 C2 C1
72
Component Categories

• Usage Container Primary Comp
• Model API Type Key Category
• Stateless Session No Service
• Conversa. Session No Session
• Durable Entity No Process
• Durable Entity Yes Entity

73
Containers (1/2)

• Containers are wrappers that encapsulate the
  component and interact with the platform to
  provide non-functional services transparently (or
  not)
• A service can be  container-managed  or
   component-managed 

container
74
Containers (2/2)

• Parametrization of containers at different levels
  in the life cycle
• Generation of containers

75
Example transaction service

• Transactional context
•  Required  Any method call starts a
  transaction
•  Requires new  A method call starts a new
  transaction
•  Mandatory   Must be called inside a
  transaction.
•  Never   Must not be part of a transaction
• ...
• Component managed
• no support
• Container managed
• The container binds persistent attributes to the
  persistency service.
• Generate code for storing and retrieving values
  in transparent way.

76
Packaging Assembly Archive
IDL Interface Description Language .ccd
Composition descriptor .cfp Properties
File .csd Component Descriptor .ZIP_ Component
Package Home_Prop Home properties
File Comp_Home Comp properties File .cad
Assembly Descriptor .aar Assembly Archive
Home_ prop
.aar
Comp_ prop
Comp_ prop
.ZIP_C1
Home_ prop
.ZIP_C2
.csd
IDL
.cfp
CIDL
.ccd
.ccd
CIDL
System generated User provided
.cfp
.cad
.cfp
77
CCM

• Interface
• Ports Facets, receptacles, event source and
  sink. (IDL)
• Assemblies.
• Receptacle gt Facet. Event Source gt event sink.
  (XML)
• Implementation
• Set of executable  Segments  (no hierarchy).
• Implementation language (CIDL)
• Life cycle.
• Design, development, deployment, execution
• Infrastructure
• Run-time infrastructure, containers (from EJB),
  persistence, transaction, ...

78
SUMMARY
79
Summary

• Interfaces of components
• ADLs arbitrary ports, description of the
  behavior, ...
• COM, OM interfaces
• JavaBean. method, property, event source,
  attributes
• .Net method, property, event, attributes
• CCM facet, receptacle, event source, event
  sink, home
• Composition of components
• ADLs connectors, assembly (mostly static)
• EJB, COM, OM, Programming
• JavaBean Programming, assembly, XML description
• CCM Assembly, XML description.
• OSGI dynamic discovery and connection.

80
Summary

• Implementation of components.
• ADLs. hierarchical descriptions
• COM, OM. flat structure one or more objects,
  multi language
• JavaBean. a single java object objects for
  other services
• CCM. one or more segments, multi language
• Lifecycle
• ADLs. design and analysis
• COM, OM. implementation, execution
• JavaBean. assembly
• CCM. specification, implemenation, assembly,
  deployment, execution

81
Summary

• Infrastructure and non functional aspect
• ADLs Not addressed.
• COM, OM component life cycle
• JavaBean assembly time infrastructure
  (builder), customization service
• EJB, CCM containers..
• .Net distribution, transaction, security,
  versioning, web forms, ...

82
Conclusion

• Components technology an industrial success.
• Efficient, functional, pragmatic.
• Support the whole component-based life cycle
• Integrate non functional aspects
• ---
• No hierarchical model.
• Poorly documented
• Very limited formalisms.
• No design formalism.
• No analysis tool.
• ADLs .. The opposite!
• Unifying the approaches

83
Conclusion
 CBSE is a coherent engineering practice, but
we still havent fully identified just what it
is.  W. Kozaczynski, G. Booch
84
Programminglanguages
85
Improve design and analysis
Architecture Descriptions Languages
Descriptionof softwarearchitecture
Behaviorspecification
Analysis
Support non functionalaspects
EJB
CORBA2
MTS
ORB
Security,
Distribution
Transaction
DCOM
COM
Ease software composition and evolution
COM
CCM
JavaBeans
Improvecomponent independence
Programminglanguages
Ease component implementation
Composition
Sun JVM
Ease component-based software development
MS CLR
Virtual Machine