Page 1Component models
Component Models and TechnologyComponent Models and Technology
Component-based Software EngineeringComponent-based Software Engineering Ivica CrnkovicIvica Crnkovic
Page 2Component models
OverviewOverview
Introduction
ACME Architectural Description Language
Java Bean Component Model
COM, DCOM, MTS and COM+
CORBA Component Model (CCM)
.NET Component Model
OSGI Component Model
Page 3Component models
Architecture Definition LanguagesArchitecture 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.
Page 4Component models
ACME Architectural Description LanguageACME Architectural Description Language
Components and Ports
Connectors and Roles
Systems and Attachments
Representations and Bindings
Properties, Constraints, Types and Styles
Page 5Component models
Components and PortsComponents 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.
ComponentPort
Page 6Component models
Connectors and RolesConnectors 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
Page 7Component models
Systems and AttachmentsSystems 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
Page 8Component models
Representations and BindingsRepresentations and Bindings
Connector
Component
PortRole
AttachementBinding
Page 9Component models
Component InteractionsComponent Interactions
Iteractions withtraditional software entities
Interactions withother
components
Interactions withother
components
Interactions withcomponent infrastructure
Components
Traditional software entities
Component Infrastructure
Page 10Component models
Terms in Components-based technologiesTerms in Components-based technologies
Interface that satisfies contracts
Component implementation
Component model
Independent deployment
Component-typeSpecific interface
Coordination Services (transactions, persistence..)
ComponentFramework
Page 11Component models
Java Bean Component ModelJava Bean Component Model
Page 12Component models
Key FeaturesKey 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
Page 13Component models
Interface of a ComponentInterface of a Component
This model defines four types of port:
methods,
properties,
event sources (generate an event)
event sinks called listeners (they receive event)
Read-only property
Write-only property
Property
Method
Event source
Event sink (listener)
Bounded property
v Vetoable property
ro
wo
1 Unicast event source
Ports
Page 14Component models
Implementation of a ComponentImplementation of a Component
Most bean components are implemented by a simple Java object by naming convention
Object
Method
A simple implementation
Propertiespublic void set<Property_name> (PropertyType value)public PropertyType get<Property_name> ()
Eventspublic viod add<ListenerType> (<ListenerType> listener);public viod remove<ListenerType> (<ListenerType> listener);public class Y implements <Y>Listener { public viod <YoccuranceName> (<YObjectType> evt);}
Page 15Component models
Components AssemblyComponents 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 Heterogeneous assembly
Page 16Component models
Packaging and DeploymentPackaging 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.
Page 17Component models
An exampleAn 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
Page 18Component models
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; }
Page 19Component models
//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); }}
Page 20Component models
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()); } }}
Page 21Component models
Output from execution of Output from execution of FooFoo
The cannibal Eddy has been converted old saved status was: false new saved status is: true
Page 22Component models
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);} }}
Page 23Component models
Output from IntrospectCannibalOutput from IntrospectCannibal
Class CannibalConstructors:
public Cannibal(java.lang.String,boolean)public Cannibal()
Fields:private java.lang.String Cannibal.nameprivate boolean Cannibal.savedprivate 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)
Page 24Component models
Java Remote Method Invocation (Java RMI)Java Remote Method Invocation (Java RMI)
RMI is an interface used over two protocols
Java Remote Method Protocol (JRMP)
Internet Inter-ORB Protocol (IIOP)
JavaClientJavaClient
CORBAObject
CORBAObject
JavaObjectJava
Object
RMIRMI
JRMP, IIOPJRMP, IIOP
Page 26Component models
Enterprise JavaBeansEnterprise JavaBeans
Architecture for distributed applications (distributed components)
Framework for creating middleware
EJB Server
EJB Container
Enterprisebean
EJBclient
Clients accesses JBs via containers
Page 27Component models
Calling an Enterprise BeanCalling an Enterprise Bean
HomeObjectHomeObject
EJB Container/Server
Client Application
Client Application
1. Call a method
EnterpriseBean
EnterpriseBean
EJBObjectEJB
Object
2. Acquire a bean and delegate thecall to the bean
2. Acquire a bean and delegate thecall to the bean
3.Return result
4. Return to client
Page 28Component models
Creating the EJB ObjectCreating the EJB Object
HomeObjectHomeObject
EJB Container/Server
Client Application
Client Application 1. Create EJB Obj.
EnterpriseBean
EnterpriseBean
EJBObjectEJB
Object
2. Create EJB Object
3. Return EJB Obj. Ref.
Page 29Component models
1. Retrivehomeobject
2. Return reference
JNDI
Java Naming and Directory InterfaceJava Naming and Directory Interface
Client Application
Client Application
NamingServiceNamingService
Page 30Component models
1. Retrivehomeobject
2. Return reference
JNDI
One More TimeOne More Time
HomeObjectHomeObject
EJB Container/Server
Client Application
Client Application 3. Create EJB Obj.
EnterpriseBean
EnterpriseBean
EJBObjectEJB
Object
4. Create EJB Object
5. Return EJB Obj. Ref.
NamingServiceNamingService
6. Call a method
7. Acquire a bean and delegate thecall to the bean
7. Acquire a bean and delegate thecall to the bean
8.Return result
9. Return to client
Page 31Component models
Java Application Server TechnologiesJava Application Server Technologies
EJBApplications
EJBApplications
EJB
HTTPListener
HTTPListener
Windows NT, Unix,Others
DBMSDBMS
DBMSDBMS
DBMSDBMS
JSPApplications
JSPApplications
BrowserClient
BrowserClient
RichClient Rich
Client
HTTP
RMI/IIOP
VariousJavaTools
VariousJavaTools
VariousJSP ToolsVarious
JSP Tools
ServletsServlets
JDBCJDBC
JDBCJDBC
JDBCJDBC
Page 32Component models
J2EE (Java 2 Platform, enterprise edition)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
Page 33Component models
J2EE architecture componentsJ2EE 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
Page 34Component models
J2EE application modelJ2EE 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
Page 35Component models
The J2EE architectureThe J2EE architecture
(Pic. Sun Microsystem, http://java.sun.com/j2ee/overview3.html)
Page 36Component models
COM/DCOM
Page 37Component models
Interfaces and AssemblyInterfaces 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.
Component interface
Interface
Component implementation
Page 38Component models
A Simple COM ObjectA 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
Page 39Component models
IUnkownIUnkown
All COM objects must implement IUnknown
AddRef
Release
QueryInterface IUnknown
Page 40Component models
IUnknownIUnknown
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
Page 41Component models
IDL ExampleIDL Example
interface ISpellCheck : IUnknowninterface ISpellCheck : IUnknown{
HRESULT check([in] BSTR *word, [out] bool *correct[in] BSTR *word, [out] bool *correct);}; interface ICustomSpellCheck : IUnknowninterface ICustomSpellCheck : IUnknown{
HRESULT add([in] BSTR *word[in] BSTR *word);HRESULT remove([in] BSTR *word[in] BSTR *word);
}; library SpellCheckerLiblibrary SpellCheckerLib{
coclass SpellCheckercoclass SpellChecker{
[[default] interface ISpellCheck;default] interface ISpellCheck;interface ICustomSpellCheck;interface ICustomSpellCheck;
};};
Page 44Component models
Creating a local objectCreating a local object
ObjectObject
Server
Client Application
Client Application
COM LibraryCOM Library
1. CoCreateInstance
3. Return pointer to interface
4. Invoke methods
2. Locate server object
CLSID_X
CLSID_Y Path to server Y
Path to server X
Registry
Page 46Component models
Creating a remote objectCreating a remote object
ObjectObject
Server
Client Application
Client Application
COM LibraryCOM Library
1. CoCreateInstance
2. Locate server object
3. Return pointer to interface
4. Invoke methods
CLSID_X
... ...
C:\X.exe
Registry
CLSID_X
CLSID_Y D:\Y.exe
Idt.mdh.se
Registry
Idt.mdh.semrtc.mdh.se
Page 47Component models
Microsoft Application Server TechnologiesMicrosoft Application Server Technologies
COMApplications
COMApplications
MTS
IISIIS
Windows NT
DBMSDBMS
DBMSDBMS
DBMSDBMS
ASPApplications
ASPApplications
ADOADO
ADOADO
BrowserClient
BrowserClient
RichClient Rich
Client
HTTP
DCOM
VBVC++VJ++
VBVC++VJ++
VisualInterDevVisual
InterDev
Page 48Component models
CORBA CORBA
andand
Component Model (CCM)Component Model (CCM)
Page 49Component models
CORBACORBA
Common Object Request Broker Architecture
Standard for writing distributed object systems
Language independent
Not controlled by one company
Optional value added services
Page 50Component models
CORBA (Common Object Request Broker Architecture)
CORBAapps CORBAdomains CORBAfacilities
CORBAservices
OMA OverviewOMA Overview
TransactionsTransactions EventEvent SecuritySecurity NamingNaming
OMA–Object Management Architecture
Page 51Component models
Page 52Component models
Remote invocationRemote invocation
Page 53Component models
CORBA 3.0CORBA 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
Page 54Component models
Page 55Component models
CORBA ORB architectureCORBA 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 type-specific 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).
Page 56Component models
CORBA Component ModelCORBA 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
Page 57Component models
CORBA Component ModelCORBA 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
Component interface
AttributeFacet
Event source
Event sink
Ports
Receptacle Segment
Component implementation
Page 58Component models
Defined Container FrameworksDefined Container Frameworks
ComponentComponentComponentComponent
Con
tain
erORB/POA
Transaction Security Persistence Events
Callback InterfacesCallback Interfaces
Internal InterfacesInternal Interfaces
ExternalExternalInterfacesInterfaces
Page 59Component models
Real-Time CORBAReal-Time CORBA
See RT-CORBA page 18…
Page 60Component models
Portable End-to-End PrioritiesPortable 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
Page 61Component models
Obtaining Portable ORB End-system PrioritiesObtaining Portable ORB End-system Priorities
ORB ENDSYSTEM A
32767
0
RT
CO
RB
A::P
riority
255
0
0
31
Native P
riority
Native P
riority
ORB ENDSYSTEM B
OS-independent design supports heterogeneous real-time platforms
CORBA priorities are “globally” unique values that range from 0 to 32767
Users can map CORBA priorities onto native OS priorities in custom ways
No silver bullet, but rather an ``enabling technique'‘
i.e., can’t magically turn a general-purpose OS into a real-time OS!
Page 62Component models
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
Page 63Component models
Preserving Priorities End-to-EndPreserving Priorities End-to-End
RT CORBA priority model policiesSERVER_DECLARED
Server handles requests at the priority declared when object was created
CLIENT_PROPAGATEDRequest is executed at the priority requested by client
Priority is encoded as part of client request
ServerClient
1. Server Priority is pre-set
2. Priority is exported in IOR
3. Priority is NOT propagated by invocation
Middle-tierServer
Client
ServiceContext
priority = 100QNX
priority = 16
LynxOSpriority = 128
ServiceContext
priority = 100
Server Solarispriority = 136
SERVER_DECLARED
CLIENT_PROPAGATED
Page 64Component models
Problems that RT-CORBA solvesProblems 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
Page 65Component models
Problems that RT-CORBA solvesProblems 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
Page 66Component models
Concluding Remarks RT-CORBAConcluding Remarks RT-CORBART CORBA 1.0 is a major step forward for QoS-enabled middlewaree.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
RT CORBA 1.0 doesn’t solve all real-time development problems, however
It lacks important features:Standard priority mapping managerDynamic scheduling
– Addressed in RT CORBA 2.0
Portions of spec are under-specifiedThus, developers must be familiar with the implementation
decisions made by their RT ORB
• Our work on TAO has had the following impact:•Advanced middleware for distributed real-time & embedded systems by implementing RT CORBA in an open-source ORB
•Provide feedback to users & OMG•Provide affordable access to RT CORBA
StandardCOTS
R&D
UserNeeds
R&D
Page 67Component models
minimumCORBA minimumCORBA
minimumCORBA defines a profile (or subset) of CORBA, whereas CORBAservices, CORBAsecurity etc. define optional extensions to the CORBA specification.
Page 68Component models
.NET.NET
Page 69Component models
What is .NET?What is .NET?
NET is a platform that enables:
Software as services, especially over the web
Distributed computing
Componentization
Enterprise services
Page 70Component models
.NET Platform .NET Platform
Operating Systems
Common Language Runtime
Base Class Library
ADO.NET and XML
ASP.NET Windows Forms
Common Language Specification
VB C++ C# JScript …V
isual S
tud
io.N
ET
Page 71Component models
.NET Framework Components.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
Page 72Component models
.NET Component Model - .NET Component Model - ImplementationImplementation
A component (assembly) is made of modules, which are traditional executable files (DLL).
Modules cannot be assemblies, thus the .NET model is not hierarchical.
Component interface
Attribute
Method
Event source
Ports Component implementation
Modules
Page 73Component models
FrameworkFramework
.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.
Page 74Component models
LifecycleLifecycle
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.
Page 75Component models
Other component modelsOther component models
OSGI Component Model
KOALA component model
IEC 61131-3 standard languages (functional blocks)
Real-time components
Page 76Component models
CC
C2
C1
C3
ms
A Koala ComponentA Koala Component
A module
A switchInterfaces
Subcomponent
Top Related