Component Models and Technology Component-based Software Engineering Ivica Crnkovic ivica.crnkovic@mdh.se Component models Page 1

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

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

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

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

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

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

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

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

Java Bean Component Model Component models Page 10

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

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

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

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

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

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

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

COM/DCOM Component models Page 18

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

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

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

CORBA Component Model (CCM) Component models Page 22

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., email, 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

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

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

:NET Component models Page 26

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

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

.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

.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

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

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

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

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

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

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

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

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

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