1. Component Models and Technology Component-based Software Engineering
Ivica Crnkovic
Component models
Page 1

2. Overview Introduction ACME Architectural Description Language
Java Bean Component Model
COM, DCOM, MTS and COM+
CORBA Component Model (CCM)
.NET Component Model
OSGI Component Model
Component models
Page 2

3. Architecture Definition Languages
ADLs primarily address the issues related to the early phases of software engineering:
Design
Analysis
They identify a number of concepts, such as:
Architecture, configurations, connectors, bindings, properties, hierarchical models, style, static analysis and behavior.
Component models
Page 3

4. ACME Architectural Description Language
Components and Ports
Connectors and Roles
Systems and Attachments
Representations and Bindings
Properties, Constraints, Types and Styles
Component models
Page 4

5. Components and Ports Components
Represent the computational elements and data stores of a system.
Ports
Are the points of interaction between a component and its environment.
Component
Port
Component models
Page 5

6. Connectors and Roles Connectors
Represent interactions between components such as method calls or an SQL connection between a client and a database server.
The interface of a connector is defined as a set of roles
Connector
Role
Component models
Page 6

7. Systems and Attachments
The structure of a system is specified by a set of components, a set of connectors, and a set of attachments.
Attachment
Links a component port to a connector role.
Attachement
Component models
Page 7

8. Representations and Bindings
Component
Connector
Port
Role
Attachement
Binding
Component models
Page 8

9. Component Interactions
Iteractions with
traditional software entities
Traditional software entities
Interactions with
other components
Interactions with
other components
Components
Component Infrastructure
Interactions with
component infrastructure
Component models
Page 9

10. Java Bean Component Model
Component models
Page 10

11. Key Features
"A Java Bean is a reusable software component that can be manipulated visually in a builder tool”.
The Java Bean was designed for the construction of graphical user interface (GUI).
Explicitly tailored to interact in two different contexts:
At composition time, within the builder tool.
At execution time, with the runtime environment.
Any Java class that adheres to certain conventions regarding property and event interface definitions can be a JavaBean.
Beans are Java classes that can be manipulated in a visual builder tool and composed into applications.
Component models
Page 11

12. Interface of a Component
This model defines four types of port:
methods,
properties,
event sources (generate an event)
event sinks called listeners (they receive event)
Property
Read-only property ro
Method
Write-only property wo
Event source
Unicast event source 1
Event sink (listener)
Bounded property
Vetoable property v
Ports
Component models
Page 12

13. Implementation of a Component
Most bean components are implemented by a simple Java object by naming convention
Object
Method
A simple implementation
Component models
Page 13

14. Components Assembly
Assembly is one of the key features of Java Bean though no not specific solution is provided.
Composition tools (Bean Box)
No composition language
Different ways of assembling components are supplied.
Heterogeneous assembly
Component-based assembly
Component models
Page 14

15. Packaging and Deployment
Java Beans define a model for packaging components into archives.
Includes the definition of dependency relationships between the package items.
Each package item can be marked "Design Only", so that they can be removed in a final application.
Component models
Page 15

16. Enterprise JavaBeans EJB Server EJB Container EJB client Enterprise
Architecture for distributed applications
Framework for creating middleware
EJB Server
EJB Container
EJB
client
Enterprise
bean
Clients accesses JBs via containers
Component models
Page 16

17. EJB Servers Analogous to CORBA ORB
Naming and directory interface (JNDI)
Client finds EJB via JNDI
JTS
Java Transaction Services
Component models
Page 17

18. COM/DCOM
Component models
Page 18

19. Interfaces and Assembly
A COM interface is seen as a C++ virtual class and takes the form of a list of data and function declarations without associated code.
All interfaces are descendants of the IUnknown interface.
Interface
Component interface
Component implementation
Component models
Page 19

20. Implementation COM defines a binary standard for interfaces
Language independent implementation of the interfaces
Interfaces are defined in Interface Definition Language (IDL)
An interface has an GUID as an identifier
IUnknown
IDispatch
Component models
Page 20

21. Composition Two type of explicit composition Delegation Aggregation
For aggregation source code is needed
Component models
Page 21

22. CORBA Component Model (CCM)
Component models
Page 22

23. OMA Overview OMA–Object Management Architecture CORBAapps CORBAdomains
CORBAfacilities
CORBA (Common Object Request Broker Architecture)
This is the Object Management Architecture. It is not read top-down or bottom-up, but rather inside-out:
The most important component is the Object Request Broker (ORB). This is responsible for providing access to clients and servers to discover objects (applications), discover their interfaces, make requests and receive responses.
Everything else in the architecture is an object, communicating with other objects via the ORB. We categorize objects into three groups based on one criterion: when the standardization process will get to them:
Object Services are the low-level services that must be available on all platforms in a distributed system (e.g., lifecycle);
Common Facilities are the commonly-found services in particular distributed systems (e.g., , print queueing);
Application Objects are the high-level applications themselves (e.g., spreadsheets, word processors, programmable controllers).
Transactions
Event
Security
Naming
CORBAservices
Component models
Page 23

24. Interface and Assembly
A component interface is made of ports divided into:
Facets - for interaction with clients
Receptacles – references o external code
Event sources
Event sinks
Attribute
Facet
Receptacle
Segment
Event source
Event sink
Component interface
Ports
Component implementation
Component models
Page 24

25. Framework : The Container Approach
Framework – a set of containers. Containers contains components and provides a set of standard services (security, events, persistence, life-cycle support)
container
CCM run-time infrastrucure
Component models
Page 25

26. :NET
Component models
Page 26

27. What is .NET? NET is a platform that enables:
Software as services, especially over the web
Distributed computing
Componentization
Enterprise services
Component models
Page 27

28. Common Language Specification Common Language Runtime
.NET Platform VB
C++ C#
JScript …
Visual Studio.NET
Common Language Specification
ASP.NET
Windows Forms
ADO.NET and XML
Base Class Library
Common Language Runtime
Operating Systems
Component models
Page 28

29. .NET Framework Components
Common Language Runtime (CLR)
Common type system for all languages
Runtime environment
Class libraries (.NET Framework)
Base class libraries, ADO.NET and XML
Windows Forms for, Win32 applications
Web application platform ASP.NET
Interactive pages
Web services that are SOAP enabled
Component models
Page 29

30. .NET Component Model - Implementation
A component (assembly) is made of modules, which are traditional executable files (DLL).
Modules cannot be assemblies, thus the .NET model is not hierarchical.
Attribute
Method
Event source
Modules
Component interface
Ports
Component implementation
Component models
Page 30

31. Framework
.NET relies on the traditional programming approach : the framework is seen as the language run-time support.
MISL – Microsoft Intermediate language (similar to Java Byte code)
Common Runtime Language (similar to Java Virtual Machine)
Transaction control relies on MTS.
Component models
Page 31

32. Lifecycle
Assemblies (and their modules) are local to an application, and thus different DLLs with same name can run simultaneously.
Each assembly has a versioning information about itself and about the assemblies it depends on.
Version control is delegated to the dynamic loader, which selects the “right” version.
Significantly improve the application packaging and deployment.
Component models
Page 32

33. Other component models
OSGI Component Model
KOALA component model
IEC standard languages (functional blocks)
Real-time components
Component models
Page 33

34. A Koala Component Subcomponent Interfaces A switch A module CC C1 C2
Component models
Page 34

35. OSGI Component Model Components Interface of a Bundle Component
Assembly of Bundle Components
Implementation of a Bundle Component
Component models
Page 35

36. Components
A bundle use three kinds of ports to express its interactions with
Traditional technology
Other components
The run-time environment
Bundles may listen to events published by the framework such as the insertion of a new component in a system.
Component models
Page 36

37. Interface of a Bundle Component
Package export
static
Package import
Service interface
dynamic
Service use
Ports
Interface of a bundle component
Component models
Page 37

38. Assembly of Bundle Components
A system is an evolving set of bundle components.
A bundle component publishes a service interface
It can attach to it a set of properties describing its characteristics.
A component requires an interface for its use,
It will select one via a query expression based on these properties.
This flexibility also has its counterpart
There is no guarantee than the service will continue to be available
Component models
Page 38

39. Implementation of a Bundle Component
JAR archive containing: 
Service components
Java packages
Other resources files
Package
Resource
Service component
Activator
Component models
Page 39