Transcript 04-chapter-Component-Models-ADL-extended

Component Models and Technology
Component-based Software Engineering
Ivica Crnkovic
[email protected]
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
Interactions
with
other
components
Interactions
with
other
components
Traditional
software
entities
Components
Component
Infrastructure
Interactions with
component infrastructure
Component models
Page 9
Terms in Components-based technologies
Interface that satisfies contracts
Component-type
Specific interface
Component
implementation
Independent
deployment
Component
model
Coordination Services (transactions, persistence..)
Component models
Component
Framework
Page 10
Java Bean Component Model
Component models
Page 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.
 Properties of a compiled bean can be obtained by
introspection mechanism
Component models
Page 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
ro
Read-only property
Method
wo
Write-only property
Event source
1
Unicast event source
Event sink (listener)
Bounded property
v Vetoable property
Ports
Component models
Page 13
Implementation of a Component
 Most bean components are implemented by a simple
Java object by naming convention
Object
Method
Properties
public void set<Property_name> (PropertyType value)
public PropertyType get<Property_name> ()
A simple implementation
Events
public viod add<ListenerType> (<ListenerType> listener);
public viod remove<ListenerType> (<ListenerType> listener);
public class Y implements <Y>Listener {
public viod <YoccuranceName> (<YObjectType> evt);
}
Component models
Page 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.
Component-based assembly
Component models
Heterogeneous assembly
Page 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 16
An example
 Example of a Cannibal bean, e.g as a part of a computer
game
 The Example contains:

A simple bean with a simple property and a boolean
bound property

A simple test class for the bean

A class which do an introspection on the bean (similar to
what a builder tool will do) showing the bean’s services,
properties and events
Component models
Page 17
import java.beans.*;
//for PropertyChangeListener
class Cannibal {
private String name;
//r simple property
private boolean saved; //rw bound boolean property
//change listeners list
private PropertyChangeSupport change;
public Cannibal() {
this("Eddy Merx", false);
}
public Cannibal(String n, boolean s) {
name=n;
saved=s;
change=new PropertyChangeSupport(this);
}
public String getName() {//property name, get method
return name;
}
public boolean isSaved() {//property saved, isXxx method, bound
return saved;
}
Component models
Page 18
//property saved, set method
public void setSaved(boolean s) {
boolean old=saved;
saved=s;
change.firePropertyChange(
"saved", new Boolean(old), new Boolean(s)
);
}
//bean services
//…
// Property Change Listener Support Methods
public synchronized void addPropertyChangeListener(
PropertyChangeListener listener) {
change.addPropertyChangeListener(listener);
}
public synchronized void removePropertyChangeListener(
PropertyChangeListener listener) {
change.removePropertyChangeListener(listener);
}
}
Component models
Page 19
public class Foo implements PropertyChangeListener {
private Cannibal can;
public static void main(String[] args) {
new Foo();
}
public Foo() {
can=new Cannibal(); // create a Cannibal
// add self to the Cannibal's listener list
can.addPropertyChangeListener(this);
// change the cannibal to saved
can.setSaved(true); // fires property change event
}
public void propertyChange(PropertyChangeEvent event) {
if (event.getPropertyName().equals("saved") ) {
System.out.println(
"The cannibal "+can.getName()+" has been converted.“
);
System.out.println("old saved status was: "+event.getOldValue());
System.out.println("new saved status is: "+event.getNewValue());
}
}
}
Component models
Page 20
Output from execution of Foo
The cannibal Eddy has been converted
old saved status was: false
new saved status is: true
Component models
Page 21
import java.lang.reflect.*;
public class IntrospectCannibal {
public static void main(String[] args) {
try {
// obtain class object for class Cannibal
Class classObject = Class.forName("Cannibal");
// get Constructor, Field and Method objects
Constructor[] cons=classObject.getDeclaredConstructors();
Field[] fields = classObject.getDeclaredFields();
Method[] methods = classObject.getDeclaredMethods();
System.out.println("Class Cannibal");
System.out.println("\nConstructors:\n");
for (int i=0; i<cons.length; ++i)
System.out.println(cons[i]);
System.out.println ("\nFields:\n");
for (int i=0; i<fields.length; ++i)
System.out.println(fields[i]);
System.out.println("\nMethods:\n");
for (int i=0; i<methods.length; ++i)
System.out.println(methods[i]);
}
catch(Exception e) {e.printStackTrace(System.out);}
}
}
Component models
Page 22
Output from IntrospectCannibal
Class Cannibal
Constructors:
public Cannibal(java.lang.String,boolean)
public Cannibal()
Fields:
private java.lang.String Cannibal.name
private boolean Cannibal.saved
private java.beans.PropertyChangeSupport Cannibal.change
Methods:
public java.lang.String Cannibal.getName()
public boolean Cannibal.isSaved()
public void Cannibal.setSaved(boolean)
public void Cannibal.hunt(java.lang.Object)
public synchronized void
Cannibal.addPropertyChangeListener(java.beans.PropertyChangeListener)
public synchronized void
Cannibal.removePropertyChangeListener(java.beans.PropertyChangeListener)
Component models
Page 23
Java Remote Method Invocation (Java RMI)
 RMI is an interface used over two protocols

Java Remote Method Protocol (JRMP)

Internet Inter-ORB Protocol (IIOP)
Java
Client
CORBA
Object
Java
Object
RMI
JRMP, IIOP
Component models
Page 24
Enterprise JavaBeans
 Architecture for distributed applications (distributed
components)
 Framework for creating middleware
EJB Server
EJB Container
EJB
client
Enterprise
bean
Clients accesses JBs via
containers
Component models
Page 26
Calling an Enterprise Bean
EJB Container/Server
Client
Application
Home
Object
4. Return to client
1. Call a method
EJB
Object
3.Return result
Enterprise
Bean
2. Acquire a bean
and delegate the
call to the bean
Component models
Page 27
Creating the EJB Object
EJB Container/Server
3. Return EJB Obj. Ref.
Client
Application 1. Create EJB Obj.
Home
Object
2. Create EJB Object
EJB
Object
Enterprise
Bean
Component models
Page 28
Java Naming and Directory Interface
Client
Application
1. Retrive
home
object
2. Return
reference
JNDI
Naming
Service
Component models
Page 29
One More Time
EJB Container/Server
5. Return EJB Obj. Ref.
Client
Application 3. Create EJB Obj.
1. Retrive
home
object
9. Return to client
2. Return
6. Call
a method
reference
Home
Object
4. Create EJB Object
EJB
Object
8.Return result
Enterprise
Bean
JNDI
7. Acquire a bean
and delegate the
call to the bean
Naming
Service
Component models
Page 30
Java Application Server Technologies
Various
JSP Tools
Browser
Client
DBMS
HTTP
HTTP
Listener
RMI/IIOP
Rich
Client
Various
Java
Tools
JSP
JDBC
Applications
Servlets JDBC
DBMS
EJB
JDBC
Applications
EJB
DBMS
Windows NT, Unix,
Others
Component models
Page 31
J2EE (Java 2 Platform, enterprise edition)
 Defines an architecture for building large scale multi-tier
distributed applications

Uses standardized modular components

Provides standard services for those components

Automatically replaces many aspects of the application
programming from the developer

Thinner clients
Component models
Page 32
J2EE architecture components
 J2EE Platform Specification

Specification of the APIs to be provided

Descriptions of the support levels expected for
containers, clients, and components
 J2EE Sun’s Reference Implementation

Free implementation of the specified technologies,
sample applications, tools, and documentation
 J2EE Compatibility Test Suite

Test implementations of the platform
 J2EE Sun BluePrint

Documentation, examples, and design guidelines
Component models
Page 33
J2EE application model
 Business logic in Enterprise JavaBeans components
 Client interaction presented through different technologies

Plain Html

Java applets

Java servlets

JSP
 Components communicates transparently using different
standards

Html

XML

RMI
Component models
Page 34
The J2EE architecture
(Pic. Sun Microsystem, http://java.sun.com/j2ee/overview3.html)
Component models
Page 35
COM/DCOM
Component models
Page 36
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 37
A Simple COM Object
 A COM interfaces can have methods and properties

Language independent – binary standard
 All Access is through the interface

Supports multiple interfaces

Each interface has a GUID
Component models
Page 38
IUnkown
 All COM objects must implement IUnknown

AddRef

Release

QueryInterface
IUnknown
Component models
Page 39
IUnknown
 Contains only three methods

HRESULT QueryInterface(GUID iid, void **iptr);

ULONG AddRef();

ULONG Release();
 QueryInterface is used for Interface Navigation
 AddRef and Release is used for reference counting

A form of collaborative carbage collection
Component models
Page 40
IDL Example
interface ISpellCheck : IUnknown
{
HRESULT check([in] BSTR *word, [out] bool *correct);
};
interface ICustomSpellCheck : IUnknown
{
HRESULT add([in] BSTR *word);
HRESULT remove([in] BSTR *word);
};
library SpellCheckerLib
{
coclass SpellChecker
{
[default] interface ISpellCheck;
interface ICustomSpellCheck;
};
};
Component models
Page 41
Creating a local object
Client
Application
4. Invoke methods
Object
Server
1. CoCreateInstance
3. Return pointer
to interface
2. Locate server object
COM Library
CLSID_X
Path to server X
CLSID_Y
Path to server Y
Registry
Component models
Page 44
Creating a remote object
Client
Application
4. Invoke methods
Object
Server
1. CoCreateInstance
COM Library
CLSID_X
Idt.mdh.se
CLSID_Y
D:\Y.exe
3. Return pointer
to interface
2. Locate server object
CLSID_X
C:\X.exe
...
...
Registry
Registry
mrtc.mdh.se
Idt.mdh.se
Component models
Page 46
Microsoft Application Server Technologies
Visual
InterDev
Browser
Client
DBMS
HTTP
IIS
ASP
ADO
Applications
DBMS
COM
ADO
Applications
MTS
DCOM
Rich
Client
VB
VC++
VJ++
DBMS
Windows NT
Component models
Page 47
CORBA
and
Component Model (CCM)
Component models
Page 48
CORBA
 Common Object Request Broker Architecture
 Standard for writing distributed object systems
 Language independent
 Not controlled by one company
 Optional value added services
Component models
Page 49
OMA Overview
OMA–Object Management Architecture
CORBAapps
CORBAdomains
CORBAfacilities
CORBA (Common Object Request Broker Architecture)
Transactions
Event
Security
Naming
CORBAservices
Component models
Page 50
Component models
Page 51
Remote invocation
Component models
Page 52
CORBA 3.0
 Internet Integration

Firewall Specification

Interoperable Name Service
 Quality of Service Control

Asynchronous Messaging and Quality of Service Control

Minimum, Fault-Tolerant, and Real-Time CORBA
 The CORBAcomponent architecture

Components

Scripting
Component models
Page 53
Component models
Page 54
CORBA ORB architecture









Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation,
which is known as a Servant.
Servant -- This is an implementation programming language entity that defines the operations that support a
CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.
Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of
a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object,
i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests
to target object implementations. The ORB simplifies distributed programming by decoupling the client from the
details of the method invocations. This makes client requests appear to be local procedure calls. When a client
invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if
necessary, delivering the request to the object, and returning any response to the caller.
ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more
processes or a set of libraries). To decouple applications from implementation details, the CORBA specification
defines an abstract interface for an ORB. This interface provides various helper functions such as converting object
references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation
interface described below.
CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and
server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target
programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for
inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler
optimizations.
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request
mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without
requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII
also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway
(send-only) calls.
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an
ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the
object it is implementing. The client making the request has no idea whether the implementation is using the typespecific IDL skeletons or is using the dynamic skeletons.
Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More
importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized
to provide support for certain object implementation styles (such as OODB object adapters for persistence and
library object adapters for non-remote objects).
Component models
Page 55
CORBA Component Model
 A Framework for Server Applications
 Built on the Portable Object Adaptor
 Provides interfaces for CORBA Services

transactions

security

events

persistence
 Uses Callbacks for instance management
 Empty container for user-defined frameworks
Component models
Page 56
CORBA Component Model
 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 57
Defined Container Frameworks
External
Interfaces
Component
Container
Callback Interfaces
Internal Interfaces
ORB/POA
Transaction
Security
Persistence
Component models
Events
Page 58
Real-Time CORBA
 See RT-CORBA page 18…
Component models
Page 59
Portable End-to-End Priorities
• Problem: How can we map global priorities onto
heterogeneous native OS host thread priorities
consistently end-to-end?
• Solution: Use Standard RT CORBA priority
mapping interfaces
Component models
Page 60
Obtaining Portable ORB End-system Priorities
255
0
ORB ENDSYSTEM A
32767
design supports
heterogeneous real-time platforms
CORBA priorities
are “globally” unique
values that range from 0 to 32767
Native Priority
RTCORBA::Priority
Native Priority
OS-independent
Users
can map CORBA priorities onto
native OS priorities in custom ways
No
silver bullet, but rather an ``enabling
technique'‘
0
0
i.e., can’t magically turn a general-purpose OS into a realtime OS!
31
ORB ENDSYSTEM B
Component models
Page 61
Preserving Priorities End-to-End
• Problem: How can we ensure requests don’t run
at the wrong priority on the server?
• e.g., this can cause major problems if
edge_alarm() operations are processed too
late!!!
• Solution: Use RT CORBA priority model policies
Component models
Page 62
Preserving Priorities End-to-End
RT CORBA priority model
policies
SERVER_DECLARED
SERVER_DECLARED
1. Server Priority
is pre-set
Server handles requests at the
priority declared when object was
created
CLIENT_PROPAGATED
Request is executed at the priority
requested by client
Priority is encoded as part of client
request
2. Priority is
exported in IOR
Client
3. Priority is NOT
propagated by
invocation
Server
CLIENT_PROPAGATED
Service
Context
priority = 100
QNX
Client
priority
= 16
Component models
Service
Context
priority = 100
LynxOS
Middle-tier
priority
Server
= 128
Server
Solaris
priority
= 136
Page 63
Problems that RT-CORBA solves
• Problem: How can RT-CORBA client application change the
priority of operations?
• Problem: How to ensure that certain operations always run
at a fixed priority?
• Problem: How can we prevent bursts or long-running
requests from exhausting maximum number of static &
dynamic threads in the lane?
• Problem: How can we support real-time applications that
need more buffering than is provided by the OS I/O
subsystem
• Problem: An ORB & application may need to use the same
type of mutex to avoid priority inversions

e.g., using priority ceiling or priority inheritance protocols
Component models
Page 64
Problems that RT-CORBA solves
• Problem: How can we minimize priority inversions, so that
high-priority operations are not queued behind low-priority
operations?
• Problem: How can we handle the fact that CORBA one-way
operation semantics aren’t precise enough for real-time
applications?
 Problem: How can we simultaneously

Prevent clients from blocking while long-duration
requests complete &

Allow many requests to be issued concurrently
Component models
Page 65
Concluding Remarks RT-CORBA
RT CORBA 1.0 is a major step forward
for QoS-enabled middleware
e.g., it introduces important capabilities to
manage key ORB end-system/network
resources
We expect that these new capabilities
will increase interest in--and applicability
of--CORBA for distributed real-time &
embedded systems
• Our work on TAO has had the following
impact:
• Advanced middleware for distributed
real-time & embedded systems by
implementing RT CORBA in an opensource ORB
• Provide feedback to users & OMG
• Provide affordable access to RT
CORBA
RT CORBA 1.0 doesn’t solve all realtime development problems, however
It
lacks important features:
Standard priority mapping manager
Dynamic scheduling
R&D
– Addressed in RT CORBA 2.0
Portions
User
Needs
of spec are under-specified
Thus, developers must be familiar with the implementation
decisions made by their RT ORB
Standard
COTS
R&D
Component models
Page 66
minimumCORBA
 minimumCORBA defines a profile (or subset) of CORBA,
whereas CORBAservices, CORBAsecurity etc. define
optional extensions to the CORBA specification.
Component models
Page 67
.NET
Component models
Page 68
What is .NET?
 NET is a platform that enables:

Software as services, especially over the web

Distributed computing

Componentization

Enterprise services
Component models
Page 69
.NET Platform
VB
C++
C#
JScript
…
ASP.NET
Windows Forms
ADO.NET and XML
Base Class Library
Common Language Runtime
Visual Studio.NET
Common Language Specification
Operating Systems
Component models
Page 70
.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 71
.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
Component interface
Ports
Component models
Modules
Component implementation
Page 72
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 73
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 74
Other component models
 OSGI Component Model
 KOALA component model
 IEC 61131-3 standard languages (functional blocks)
 Real-time components
Component models
Page 75
A Koala Component
Subcomponent
Interfaces
A switch
CC
C1
s
C2
m
C3
A module
Component models
Page 76