CBSE Concepts – Short review “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only

CBSE Concepts – Short review

Provides interfaceRequires interface

ComponentDefines the servicesfrom the component’senvironment that ituses

Defines the servicesthat are providedby the componentto other components

“A software component is a unit of composition with contractually specified interfaces

and explicit context dependencies only. A software component can be deployed

independently and is subject to composition by third-parties.” (Szyperski)

CBSE Concepts – Short reviewModeling components with UML: component diagrams, components, provided and required interfaces, ports, connectors

Page 22Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software

Engineering

RelationshipsRelationships BetweenBetween ConceptsConcepts

Interface that satisfies contracts

Component implementation

Component model

Independent deployment

Component-typeSpecific interface

Coordination Services (transactions, persistence..)

ComponentFramework

CBSE Concepts – Short review

CBSE concepts – Short review

Component Component Component

Component platform (component framework)

Operating System

Middleware

Hardware

Platform Services: allow components written according to the model to communicate; locating, linking, replacing components

Horizontal Services: application-independent services used by different components. Concurrency, security, transaction management, Resource management

CBSE – Lectures 4+5

• Component models: Case study: OpenCom – OpenCOM is a leightweight and reflective component model

– Developed by The Next Generation Middleware group at Lancaster University

• http://www.comp.lancs.ac.uk/computing/research/mpg/reflection/software.htm

– Used as a development and distribution environment for many research systems.

• Adaptive middleware: OpenORB

http://www.comp.lancs.ac.uk/computing/research/mpg/reflection/software.htm

OpenCom• Versions:

– OpenCOM v1: built on top of Microsoft COM and has been successfully applied to constructing re-configurable middleware platforms.

• The main limitation is its inability to construct systems for a heterogeneous environment

• High memory footprint• Component model is In-process

– OpenCom: independent of Microsoft COM• Small memory footprint, also usable for mobile and embedded devices• OpenCOM v1 implementation in C

– http://sourceforge.net/projects/opencomc/ • OpenCOM v1 implementation in Java

– http://sourceforge.net/projects/gridkit/ OpenCOMJv1.4.zip

– OpenCOM v2 (also independent of COM)• Components can be in different address spaces

http://sourceforge.net/projects/opencomc/



http://opencomc.sourceforge.net/

http://sourceforge.net/projects/gridkit/



Basic concepts in OpenCOM• The fundamental concepts in OpenCOM are: interfaces, receptacles and

connections. – For example, if a component requires a service S, it would declare a receptacle of type S

which would be connected at run-time to an external interface instance of type S (which would be provided by some other component).

• A binding is a run-time association between a single interface and a single receptacle.

– Interfaces may participate in multiple bindings, whereas each receptacle may only participate in a single binding at a time.

– Like component deployment, the creation of bindings is inherently third-party in nature. That is, bindings can be created by any component, not only by the ‘first-party’ components whose interface or receptacle is actually participating in the binding

• OpenCOM is a lightweight and efficient in-process component model– In OpenCOM v1 all components that build a system must be in the same address space

OpenCOM Runtime• OpenCOM deploys a standard runtime substrate per address space • Functions of the OpenCOM runtime substrate (kernel):

– manages the creation and deletion of components– acts upon requests to connect/disconnect components– maintains a system graph of the components currently in use

• The explicit maintenance of dynamic dependencies between components provides the support for introspection and reconfiguration of component configurations.

• The reflective interfaces of OpenCOM follow three of the meta-models proposed by OpenORB i.e. the Interface meta-model (IMetaInterface), the Architecture meta-model (IMetaArchitecture) and the Behaviour meta-model (IMetaInterception).

• Implementation:– V1: uses the core features of Microsoft COM to underpin its implementation;

these include the binary level interoperability standard, Microsoft's IDL, COM's globally unique identifiers and the IUnknown interface. The higher-level features of COM, including distribution, persistence, transactions and security are not used.

– OpenCom: does not rely on COM, is very lightweight

http://www.comp.lancs.ac.uk/computing/research/mpg/reflection/meta.php

http://www.comp.lancs.ac.uk/computing/research/mpg/reflection/meta.php

The architecture of OpenCOM

Reflection• Reflection is the capability of a system to reason about and act upon itself• A reflective system provides (at least) two linked interfaces to its clients:

– a base-level interface to the system’s functionality similar to the interface of other such systems

– a meta-level interface that reveals aspects of how the base-level interface is implemented

• Why reflection:– Suport for introspection

• The ability to inspect the structure and behaviour of the system – dynamic monitoring, debugging

– Suport for adaptation by intercession• Runtime reconfiguration

• OpenCOM uses 3 orthogonal reflective meta-models• These allow both structural reflection and behavioral reflection

– Structural reflection is the representation of (static) structure of the system– Behavioural reflection is the representation of ongoing activity

Structural reflection in OpenCOM

• The interface meta-model (IMetaInterface – reflective interface of every OpenCOM component)

– Supports introspection on the external representation of a component

• Dynamically discover interfaces/receptacles of a component

• Dynamically invoke discovered interfaces

• capability similar to introspection facilities in the Java reflection API

• Introspection only (no adaptation): programmer cannot modify interfaces (add new method) or access implementations

• The architecture meta-model (IMetaArchitecture – reflective interface of the OpenCOM kernel)

– Supports introspection and adaptation of the underlying software architecture

• Software architecture = component graph

Behavioural reflection in OpenCOM

• The interception meta model (IMetaInterception – reflective interface of the kernel)

– Supports the interception of pre- and post- methods on a given interface

– Lightweight means of adding new behaviour

– Does not require the reconfiguration of the existing component

architecture

OpenCOM components

• Every OpenCOM component implements the following standard interfaces:

– ILifeCycle provides operations called startup and shutdown that are called when a component is created or destroyed.

– IConnections(optional – previously called IReceptacles) offers methods to modify the interfaces connected to a component's receptacles. These are only called by the OpenCOM runtime component. A component without receptacles does not implement this interface.

– IMetaInterface supports inspection of the types of interfaces and receptacles declared by the component. The meta information to support these operations is stored in the type library of each component.

– IUnknown is equivalent to the interface with the same name in Microsoft COM. It is used to get the reference to the requested interface on that component instance

• Additionally, a component may implement also a number of custom interfaces and require a number of custom receptacles

OpenCOM runtime kernel• A singleton in the address space of the system• Reflective interfaces:

– IMetaArchitecture– IMetaInterception

• Interface for the kernel API: IOpenCOM– createInstance– deleteInstance– Disconnect– Connect– getComponentName– getComponentPIUnknown– getComponentCLSID– isContained

OpenCom composite components

• Composite components: a structuring mechanisms to develop complex component-based applications

• OpenCOM provides no kernel-level support for creating composite components

• Composites can be created by the user according to a general model

• Composite components are called in the OpenCOM terminology “ComponentFrameworks” !

• In OpenCom, a component framework (CF) is a tightly coupled set of components that

– cooperates to address some focused area of concern;– provides a well-defined extension protocol that accepts additional “plug-

in” components that modify or extend the CF’s behavior;– constrains how these plug-ins may be organized.

OpenCom composite components

Actually called ICFMetaInterfaceIn the OpenComJ API

OpenCOM composite components

• The design of this component framework model is based upon the concept of composite components and promotes the following key properties:

– A component framework in OpenCOM is a composite OpenCOM component• Therefore, component frameworks in OpenCOM are implemented as OpenCOM

components; that is, they implement the same base interfaces (IMetaInterface, ILifeCycle and IConnections), custom service interfaces and receptacles.

– A component framework provides an additional meta-interface ICFMetaArchitecture (ICFMetaInterface in the OpenComJ API) for inspection and dynamic adaptation of the local architecture of the composite component.

• To be subject to introspection and dynamic reconfiguration, each component framework maintains a local graph of its internal structure. To reduce data duplication, this is simply a view of the information held in the OpenCOM system graph. Therefore, each CF maintains a list of Component Identifiers that point to their corresponding position in the system graph.

– The integrity of each component framework is maintained in the face of dynamic change, using developer specified architectural rules plugged into the component framework.

• Each component framework provides a receptacle named IAccept into which developers can plug their own checking implementation. this consists of a single operation that takes as parameters the local graph of the component framework and the list of interfaces that expose the structure’s functionality. When executed it returns a Boolean value to indicate if the structure is valid; if true, the component framework continues its operation. Otherwise, if false, the component framework rolls back to the previous known good configuration (stored prior to the change) and generates a message to indicate a failed reconfiguration.

OpenCOM v2

• OpenCOMv2: to support systems that span multiple deployment environments, and can be used to develop platforms that combine multiple target domains.

• Adds Platform Extensions: augment the basic programming model with new optional abstractions and services

– Capsules, Caplets, Loaders and Binders

OpenCOM v2

• Adds capsules, caplets, loaders and binders

• Capsules are containing entities into which components are loaded, instantiated and composed. Each capsule defines a name space for its contained component instances (hereafter, we refer to component instances simply as ‘components’), and offers the OpenCom kernel API

• Capsules are “component containers” that may encompass multiple address spaces and are managed by one single kernel. They provide a namespace in which all components and interfaces are individually identified by a unique identifier. Each capsule is associated with one specific OpenCom kernel that is responsible for deploying components in that particular capsule. Usually, an entire system will reside in one capsule. The notion of capsule helps reason about cases where multiple kernels must interact (for legacy or compatibility reasons, for instance).

Caplets-Loaders-Binders• Caplets are OpenCom’s representation of a “locus of deployment”. Conceptually,

caplets allow the kernel to support different technologies in the underlying deploying environment. They also provide an isolation mechanism between components which are mutually distrustful or have different privileges. For example, if a system requires deployment of both C++ and Java components, this can be achieved by creating separate caplets for each technology domain.

• Note that caplets and capsules differ in that caplets are explicitly created, unlike the capsule associated with each kernel. In this respect, a capsule should be regarded a logical component containers that may encompass several address spaces and hardware domains and may therefore contain several caplets.

• Loaders encapsulate the complexity of loading components in a heterogeneous environment. Each loader supports a specific loading mechanisms, thus allowing a wide range of component styles to be managed by the same kernel.

• Binders are OpenCom components designed to provide a wide range of ‘binding mechanisms’. Using binders, developers are free to implement any binding mechanism that might be required in the underlying deployment environment. For example, they may implement a binder that creates connections between Java components or a binder that connects components written in Assembly language

• When the kernel starts, it only contains a single caplet, the primary caplet. At this point the caplet coincides with the enclosing capsule. Additional caplets termed extension caplets may then be progressively added to the system through the extensions framework to support new styles of components.

Caplets-Loaders-BindersThe kernel is only capable of deploying primary-style components.From an implementation point of view, caplets, loaders and binders are primary-style components and are deployed by the kernel. They provide a bridge to a new deployment environment

References• OpenCOM page:


• [OpenCOMv1] Clarke, M., Blair, G. S., Coulson, G., and Parlavantzas, N. 2001. An Efficient Component Model for the Construction of Adaptive Middleware. In Proceedings of the IFIP/ACM international Conference on Distributed Systems Platforms Heidelberg (November 12 - 16, 2001). R. Guerraoui, Ed. Lecture Notes In Computer Science, vol. 2218. Springer-Verlag, London, 160-178.

• [OpenCOMv2] Coulson, G., Blair, G., Grace, P., Taiani, F., Joolia, A., Lee, K., Ueyama, J., and Sivaharan, T. 2008. A generic component model for building systems software. ACM Trans. Comput. Syst. 26, 1 (Feb. 2008), 1-42. DOI=http://doi.acm.org/10.1145/1328671.1328672

• Note: these articles present the general concepts of OpenCOM. They are NOT an accurate description/documentation of the current API !

– [OpenCOMv1] includes some details that are outdated

– [OpenCOMv2] discusses the API in a simplified form for presentation purposes


OpenComJ

• OpenCOM v1 implementation in Java

• Available at:

– http://sourceforge.net/projects/gridkit/– To use OpenCOM you need to download:

• opencomjv1.4.zip

• Documents > OpenCOMJHandbook.pdf




http://sourceforge.net/projects/gridkit/files/OpenCOM/OpenCOMJv1.4/opencomjv1.4.zip/download

http://sourceforge.net/projects/gridkit/files/Documents/OpenCOMv1.3.5%20Docs/OpenCOMJHandbook.pdf/download

The OpenCom Java component specification

• Each component is made up from a set of Java classes.

• One class from this set defines the component type; we refer to this as the foundation OpenCOMJ class. For example, a component of type A includes a foundation class named A.

• The foundation class must implement a set of OpenCOM specific interfaces:– IMetaInterface

– ILifeCycle

– IUnknown

• The component must be third party deployable; hence each component must be available within a JAR; a single JAR can contain one or more OpenCOMJ components.

• Each OpenCOMJ component lists one or more provides interfaces. Each interface must be an OpenCOM interface, which inherits the IUnknown interface.

– This is opposed to a Java interface (although Java interfaces can still be used in component implementation classes they cannot be used to connect components together, or be queried by IUnknown).

• An OpenCOMJ component optionally lists a set of required interfaces. This consists as a set of receptacles (that must inherit from the OCM_Receptacle class). Each receptacle is a publicly accessible field of the foundation class.

• Apart from receptacles, no java field must be publicly accessible from classes external to the component classes.

• A composite component or component framework must implement the ICFMetaInterface interface, and define a single receptacle of type IAccept.

Developing a basic OpenCOM component

Example:

AdderIAdd

Component Adder provides Interface IAdd


Step 1. Define your provides interfaces

package Samples.AdderComponent;import OpenCOM.*;public interface IAdd extends IUnknown{ /** * Add two integers together. * @param x Operand X. * @param y Operand Y. * @return The added values. */ public int add(int x, int y);}

To create an OpenCOMJ interface you create a Java interface class thatextends the IUnknown interface from OpenCOM.


Step 2. Create the foundation class

package Samples.AdderComponent;import OpenCOM.*;public class Adder extends OpenCOMComponent implements IAdd,IUnknown, IMetaInterface, ILifeCycle {

/** Creates a new instance of Adder */public Adder (IUnknown pRuntime) {

super(pRuntime);}

...}

1. create a new Java class with the same name as the type of component you wish to create

2. The foundation class extends the OpenCOMComponent abstract class.

3. The foundation class constructor must have the following syntax: classname(IUnknown)

4. The foundation class must implement three interfaces: IUnknown, IMetaInterface, and ILifeCycle


Step 3. Implementing ILifeCycle in the foundation class

// ILifeCycle Interface Implementationpublic boolean shutdown() {

System.out.println(“Stopping Component”);return true;

}public boolean startup(Object pIOCM) {

System.out.println(“Starting Component”);return true;

}

Of the three standard interfaces, you only need to write operation implementations for ILifeCycle, as the others are implemented within the abstract class.This is because you place the application specific code you want to execute when the component is started (not constructed), and when it is stopped. Hence, you can create components that are executable over time


Step 4. Implementing the provides interface in the foundation class

/*** Add two integers together.* @param a Operand X.* @param b Operand Y.* @return The added values.*/public int add(int a, int b) {

return a+b;}

Developing an OpenCOM component with receptacles

Example

CalculatorICalculatorIAdd

Component Calculator provides Interface ICalculator and requires Interface IAdd


Step 1. Defining the receptacle interface

Samples.AdderComponent.IAdd

For each component interface you require to bind to another component, you must implement the corresponding OpenCOM interface class. Although this will typically already have been implemented in creating the provides interface


Step 2. Adding the IConnections interface to the component implementation

public class Calculator extends OpenCOMComponent implementsICalculator, IConnections, ILifeCycle, IUnknown,IMetaInterface {

When there are receptacles to be connected a component must implement the OpenCOM IConnections interface in addition to the other core OpenCOM interfaces.Hence, we add it to the implements list of the foundation class


Step 3. Creating the receptaclesimport OpenCOM.*;import java.util.*;// Interfacesimport Samples.AdderComponent.IAdd;

public class Calculator extends OpenCOMComponent implementsICalculator, IConnections, ILifeCycle, IUnknown, IMetaInterface {/*** Requires Interface of type IAdd.*/public OCM_SingleReceptacle<IAdd> m_PSR_IAdd;/** Creates a new instance of Calculator */public Calculator(IUnknown binder) {super(binder);// Initiate the receptaclesm_PSR_IAdd = new OCM_SingleReceptacle<IAdd>(IAdd.class);}}

To define your receptacles in the foundation class you list the receptacles as public fields of the foundation class.Then construct the receptacles within the component constructor


Step 4. Implementing the IConnections interface// IConnections Interface

public boolean connect(IUnknown pSink, String riid, long ConnID) { if(riid.toString().equalsIgnoreCase("Samples.AdderComponent.IAdd")){ return m_PSR_IAdd.connectToRecp(pSinkIntf, riid, provConnID); } return false;}

public boolean disconnect(String riid, long connID) { if(riid.toString().equalsIgnoreCase("Samples.AdderComponent.IAdd")){ return m_PSR_IAdd.disconnectFromRecp(connID); } return false;}

The IConnections interface must be implemented following a consistent syntax to ensure that your components are connected correctly For each of the receptacles check if the riid parameter matches the type of thereceptacle; if it does, either call connectToRecp on the receptacle or disconnectFromRecp


Step 5. Invoking a Receptacle //Interface ICalculator implementation/*** Add two integers together.* @param a Operand X.* @param b Operand Y.* @return The added values.*/Public add (int a, int b) {/** Standard single receptacle invocation.*/return m_PSR_IAdd.m_pIntf.add(a, b);}

In order to use another component’s provided functionality, you invoke a connected receptacle. To do this you call the method name from the interface on the receptacle.m_pIntf field of your receptacle. For example, here we wish to calladd on the adder component, therefore we call the add operation preceded by m_PSR_IAdd.m_pIntf.

The add operation of the ICalculator interface has

nothing to do with the add operation of the

IAdd interface !

Creating Systems with OpenCOM components

Example


Adder

OpenCOM

IOpenCOM


1.Creating the Runtime Kernel

// Create the OpenCOM runtime & Get the IOpenCOM interface referenceOpenCOM runtime = new OpenCOM();IOpenCOM pIOC=(IOpenCOM) runtime.QueryInterface("OpenCOM.IOpenCOM");

To use OpenCOM you must create an instance of the kernel in the local jvm address space.The second line displays an important programming procedure in OpenCOMJ known as QueryInterface. Every component (and the runtime) has an IUnknown interface with a single operation: QueryInterface. This operation allows you to get a reference to the interface you wish to invoke operations on. Here, we want to use the core IOpenCOM interface therefore,we query from the runtime the interface type: “OpenCOM.IOpenCOM” and this returns a java reference, or null if the interface isn’t available on this element


2.Creating a new Component Instance

// Create the Adder componentIUnknown pAdderIUnk = (IUnknown) pIOCM.createInstance

(“Samples.AdderComponent.Adder”, “Adder”);ILifeCycle pILife = (ILifeCycle)

pAdderIUnk.QueryInterface(“OpenCOM.ILifeCycle”);pILife.startup(pIOCM);

To create a new component you use the createInstance operation on the previous IOpenCOM interface reference. Note, you are returned an IUnknown reference of the Component (or null); this uniquely identifies the component in the address space and can be used to find further interfaces.If the component needs to begin executing you call the startup operation on the ILifeCycle interface. When this is done is dependent on the component. If there is no execution then you don’t need to call it. You may also want to wait until the component is fully connected. To startup you perform QueryInterface on the new component reference and then invoke startup. The parameter of startup can be any object, so you can pass any specific information to a component at this point in time. The example passes the runtime reference as a parameter for illustrative purposes only.


3.Connecting two components

long ConnID1 = pIOCM.connect(pCalcIUnk, pAdderIUnk,"Samples.AdderComponent.IAdd");

Components with required interfaces need to be connected, otherwise their operations will fail when called. In our example, the calculator component must be connected to the adder component on the IAdd interface. Therefore, after first creating an instance of each of the two components we connect them together using the connect operation from IOpenCOM.

Connect has following parameters:Param1: The reference of the component with the receptacle to connectParam 2: The reference of the component with the interface to connect.Param 3: The class type of the interface to connectReturn: A positive long reference uniquely identifying the connection. Every connection gets a unique reference (that is valid for the lifetime of the kernel operation). –1 is returned if the connection failed.


4.Disconnecting two components

pIOCM.disconnect(ConnID1);

To disconnect two components you invoke the disconnect operation from IOpenCOM; you pass the previously stored reference number of the connection as a parameter.


4.Deleting a component

pIOCM.deleteInstance(pAdderIUnk);

To delete a previously created component instance you use the deleteInstance operation from the IOpenCOM interface. This will safely shutdown and disconnect the component (if you haven’t already done it) and remove the instance from the meta-level information. However, because the component is implemented in Java it may not be removed from memory immediately

Performing reflective operations

Example


Adder

OpenCOM

IOpenCOM

IMetaArchitecture

IMetaInterception

IMetaInterface IMetaInterface


1.Architecture meta model operations• The architecture meta-model allows you to discover the architecture of

components in terms of what components are connected to another.

• For this there are two operations that are available from the IMetaArchitecture interface that is provided by the OpenCOM runtime:

– enumConnsToIntf examines a particular interface of a component and then describes who is connected to that interface.

– enumConnsFromRecp examines a particular receptacle and then describes

– These operations give us a vector of connection identifiers.

– Next, we can use each long identifier from the list, calling getConnectionInfo() from the IOpenCOM interface to find out the information about this connection


1.Architecture meta model operations - Example

IMetaArchitecture pIMetaArch = (IMetaArchitecture) runtime.QueryInterface("OpenCOM.IMetaArchitecture");Vector<Long> list = new Vector<Long>();int NoConns = pIMetaArch.enumConnsToIntf(pAdderIUnk, "Samples.AdderComponent.IAdd", list);for(int index=0; index<NoConns; index++){

OCM_ConnInfo_t TempConnInfo =pIOCM.getConnectionInfo(list.get(index).longValue());

System.out.println("Component "+TempConnInfo.sinkComponentName + " is connected to " +TempConnInfo.sourceComponentName + " on interface " +TempConnInfo.interfaceType);

}


2.Interface meta model operations• this meta model differs in that you interact with the components via

their IMetaInterface rather than the run-time kernel to get information.

• The Interface meta model allows you to:– inspect the interfaces and receptacles available on components

• enumIntfs and enumRecps

– add and inspect meta-data that has been attached to interface elements (i.e. instances of a receptacle or interface).

• you can add information in the form of a name-value pair to either an individual interface element or a receptacle element of a component

• setAttributeValue and GetAttributeValue


2.Interface meta model operations - Example

IMetaInterface pMeta = (IMetaInterface)pAdderIUnk.QueryInterface("OpenCOM.IMetaInterface");Vector<Class> ppIntf = new Vector<Class>();int length = pMeta.enumIntfs( ppIntf);System.out.println("The number of Interfaces on Adder component is"+length);for (int y=0; y<length; y++){

Class temp = ppIntf.elementAt(y);System.out.println(temp.toString());

}

IMetaInterface pMeta = (IMetaInterface)pAdderIUnk.QueryInterface("OpenCOM.IMetaInterface");pMeta.SetAttributeValue("Samples.AdderComponent.IAdd", "Interface",

"Variation", "int", new Integer(8));


3.The Interception meta model• The interception meta model is an important feature of OpenCOMJ,

as it allows you to add new behaviour to a running system dynamically. It does this by allowing you to add pre- and post- interceptors to any interface of an OpenCOM component.

• 2 phases:– write a new interceptor

– add interceptor to an interface instance.


3. Interceptions meta model operations – Example: write a new pre interceptor

Public class PreAndPostMethods {…public int Pre0(String method, Object[] args){// Take 8 off the first integer parameter// to correct the additionInteger int1 = (Integer) args[1];int val = int1.intValue()-8;args[1] = new Integer(val);return 0;}…} An interceptor is a Java method that follows a particular syntax that allows it to be

used in the interception meta model. The String “method” parameter contains the name of the method that is being ‘actually’ called on the interface. Typically you can use this to determine which behaviour to use e.g. block all operations of a particular method name, or perform behaviour on one method type, and alternative behaviour on another method. The “Object[] args” parameter contains the list of parameters of theoperations for the real method call.


3. Interceptions meta model operations – Example : add pre interceptor

// Query the IMetaInterception interface from the runtime kernelIMetaInterception pIMeta = (IMetaInterception)

runtime.QueryInterface("OpenCOM.IMetaInterception");

//Use IMetaInterception to Get the Delegator for the required interface. We//call GetDelegator() passing the component reference and the interface type//which pinpoints the correct interface and returns the IDelegator interface//to allow you to manipulate the delegatorIDelegator pIAdderDel = pIMeta.GetDelegator(pAdderIUnk,

"Samples.AdderComponent.IAdd");

// Instantiate an object that hosts the interceptor methodPreAndPostMethods Interceptors = new PreAndPostMethods(pIOCM);

//Call AddPreMethod/AddPostMethod on the IDelegator interface. You//always pass the object where the interceptor is hosted and the name of the//interceptorpIAdderDel.addPreMethod(Interceptors, "Pre0");


3. Interceptions meta model operations – Operations available on the Delegator interface

AddPreMethod(Object, String) adds pre methodsDelPreMethod(String) Remove the named pre-interceptorAddPostMethod(Object, String) Same procedure as AddPreMethod but this adds post methodsDelPostMethod(String) Remove the named post-interceptorViewPreMethods(String[]) Fills the string list parameter with the names ofpre methods attached to this interface delegator.ViewPostMethods(String[]) Fills the string list parameter with the names ofpost methods attached to this interface delegator.

OpenCOM Implementation detail

Uses the Java dynamic proxy mechanism

Delegator

Proxy pattern

Classical Proxy Implementation vs Dynamic Proxy

A Classical Proxy Implementation requires the Programmer to write the code of the Proxy class for every Original Interface and compile it.A dynamic proxy class is a class that implements a list of interfaces specified at runtime when the class is created

Java dynamic proxy

• A dynamic proxy class is a class that implements a list of interfaces specified at runtime such that a method invocation through one of the interfaces on an instance of the class will be encoded and dispatched to another object through a uniform interface.

• Thus, a dynamic proxy class can be used to create a type-safe proxy object for a list of interfaces without requiring pre-generation of the proxy class, such as with compile-time tools.

• Method invocations on an instance of a dynamic proxy class are dispatched to a single method in the instance's invocation handler, and they are encoded with a java.lang.reflect.Method object identifying the method that was invoked and an array of type Object containing the arguments.

• This process allows implementations to "intercept" method calls and reroute them or add functionality dynamically. The dynamic proxy can act as a Decorator pattern, where the proxy wraps invocations with additional functionality => it is the case with OpenCOM Delegator

Java dynamic proxyTo read more about java dynamic proxy:

• Sun: http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html

• IBM technical library: http://www.ibm.com/developerworks/java/library/j-jtp08305.html

• Java Reflection in Action: http://www.webreference.com/internet/reflection/

http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html

http://www.ibm.com/developerworks/java/library/j-jtp08305.html

http://www.webreference.com/internet/reflection/



Proxy object – an instanceof the dynamic proxy class created automatically at runtime

The service of the original Object is called by Reflection

Creating a dynamic proxy in Java

To create a proxy for some interface Foo:

InvocationHandler handler = new MyInvocationHandler(...);

Class proxyClass = Proxy.getProxyClass( Foo.class.getClassLoader(), new Class[] { Foo.class });

Foo f = (Foo) proxyClass. getConstructor(new Class[] { InvocationHandler.class }). newInstance(new Object[] { handler });

A dynamic proxy class (simply referred to as a proxy class below) is a class that implements a list of interfaces specified at runtime when the class is created, with behavior as described below. A proxy interface is such an interface that is implemented by a proxy class. A proxy instance is an instance of a proxy class.

The unqualified name of a proxy class is unspecified. The space of class names that begin with the string "$Proxy" should be, however, reserved for proxy classes. A proxy class extends java.lang.reflect.Proxy. A proxy class implements exactly the interfaces specified at its creation, in the same order.

Creating a dynamic proxy in Java

A shorter way to create a proxy instance for Foo: InvocationHandler handler = new MyInvocationHandler(...);

Foo f = (Foo) Proxy.newProxyInstance(Foo.class.getClassLoader(), new Class[] { Foo.class }, handler);

Used in OpenCOM.Delegator:

/**

The dynamic proxy creation operation - takes the original component and wraps the dynamic invocation handler around it. (Delegator implements InvocationHandler)

*/

public static Object newInstance(Object obj) {

Object ParentObject= java.lang.reflect.Proxy.newProxyInstance(

obj.getClass().getClassLoader(),

obj.getClass().getInterfaces(),

(java.lang.reflect.InvocationHandler) ThisObject);

return ParentObject;

}

Example: OpenCOM Delegates and Dynamic Proxies

// Create the Adder component// this creates the original Adder object, the Delegator and the Proxy// returns the created proxy instance – the returned object is of type $Proxy0IUnknown pAdderIUnk = (IUnknown) pIOCM.createInstance

(“Samples.AdderComponent.Adder”, “Adder”);

// Insert here code that adds Pre0 interceptor to Iadd of Adder// … see slide before// The interceptor method is stored in the Delegator

// Get the Add Interface// actually gets the ProxyIAdd pIAdd = (IAdd) pAdderIUnk.QueryInterface("Samples.AdderComponent.IAdd");

//Use the Adder component// actually uses the Proxy, that uses the Delegator as InvocationHandlerpIAdd.add(2,3);

OpenCOM Delegates Sequence diagram for example

pIAdd:$Proxy0 :Delegator :Adder

main gets pIAdd:$Proxy0by QueryInterface

Alternative Receptacles • IReceptacles: Interface implemented by receptacles. Provides operations to

manipulate the receptacles themselves: connect and disconnect them, add meta-data to them

• OCM_Receptacle: abstract class

• OCM_SingleReceptacle

– By default, simple receptacles have following limitations:

– Only one interface can be connected to a receptacle

– A component cannot have several receptacles of the same type– You can add several receptacles of the same type, but the problem is that you cannot

differentiate them when creating a connection (or you have to do a bit of hacking around)

• Alternative receptacles:– OCM_MultiReceptacleParallel

– OCM_MultiReceptacle

– OCM_ReceptacleDynamicContext

Alternative Receptacles

1.Parallel Receptacle OCM_MultiReceptacleParallel

Calculator

IOutput

Adder AdderAdder

Multiple components all implementing the same interface type can be connected to this receptacle. The example shows 3 adder components that are connected to the calculator receptacle of type IOutput. When the receptacle is invoked, each connection executes in a separate thread. Important: there are no return values; hence only void methods are appropriate.


1.Parallel Receptacle - Example

// changes in the foundation class (CalculatorParallel)

// define the receptacle as a public field of the componentpublic OCM_MultiReceptacleParallel<IOutput> m_PSR_IOutput;

//initialise it within the constructorm_PSR_IOutput = new OCM_MultiReceptacleParallel <IOutput>(IOutput.class);

// invoke operation on receptacle – in parallel !m_PSR_IOutput.m_pIntf.DisplayMessage(message);

// changes in the test program

// Create the Adders for(int i=0; i<10; i++){ pAdderIUnk = (IUnknown)

pIOCM.createInstance("Samples.AdderComponent.Adder", "Adder "+i); long ConnID3 = runtime.connect(pCalcIUnk, pAdderIUnk,

"Samples.AdderComponent.IOutput"); }


1.Parallel Receptacle – How it is implemented

public class OCM_MultiReceptacleParallel<InterfaceType> extends OCM_Receptacle implements IReceptacle{

/** Type of Receptacle */public InterfaceType m_pIntf;

/** List of interface pointers this receptacle is connected to. */ private Vector<Object> interfaceList; /** List of connIDS for each connection of this receptacle. */ private Vector<Long> connIDS; private int numberOfConnections;

…

}


1.Parallel Receptacle – How it is implemented (cont)


public boolean connectToRecp(IUnknown pIUnkSink, String riid, longprovConnID) {// Get the reference to the component hosting the interfacetry{InterfaceType pIntfRef = (InterfaceType) pIUnkSink.QueryInterface(riid);interfaceList.add(pIntfRef);}catch(ClassCastException e){

return false;}

// Add info to the receptacle object storesconnIDS.add(new Long( provConnID));numberOfConnections++;return true;}

}


1.Parallel Receptacle – How it is implemented (cont)


public boolean disconnectFromRecp(long connID) {// Traverse the data looking for the required connection IDfor(int i = 0; i < numberOfConnections ; i++) { Long vecConnID = connIDS.elementAt(i); if(vecConnID.longValue() == connID) { // remove information about that connection numberOfConnections--; interfaceList.remove(i); connIDS.remove(i); } if(numberOfConnections ==0) { m_pIntf = null; return true; } return true; }return false;}}


2. Sequential Receptacle - OCM_MultiReceptacle

Calculator

IDisplay

Adder AdderAdder

A sequential receptacle allows the programmer to choose any of the connections at atime and then call them. For example, they can select each one in term and theninvoke an operation on it. Hence, you could keep trying until one returned the resultyou required.


// changes in the foundation class (CalculatorSequential)

// define the receptacle as a public field of the component public OCM_MultiReceptacle<IOutput> m_PSR_IOutput;

//initialise it within the constructorm_PSR_IOutput = new OCM_MultiReceptacle <IOutput>(IOutput.class);

// invoke operation on receptaclefor(int i=0; i<m_PSR_IOutput.interfaceList.size(); i++){ m_PSR_IOutput.interfaceList.get(i).DisplayMessage(message);

}

2. Sequential Receptacle - Example


3. Context Receptacle - OCM_MultiReceptacleDynamicContex

Calculator

IDisplay

Adder AdderAdder

Allows you to select a single connection from the set ofmultiple connections based upon a stated context parameter. Note, only one operation is called, and this is from the first connection that matches the context.


3.Context Receptacle - Example

// changes in the foundation class (CalculatorDynamicContext)

public OCM_MultiReceptacleDynamicContext<IOutput> m_PSR_IOutput;

public String display(String msg) {String returnStr = message.concat(":: From Calculator");// Create a context rule - our request for interface invokeContextRule context[] = new ContextRule[1];context[0]=new ContextRule("Owner", "Paul Grace");// Find out which interface has such a context matchint index = m_PSR_IOutput.getContext(context);//Invoke the indexed interface that matches.if(index>=0) m_PSR_IOutput.interfaceList.get(index).DisplayMessage(msg);return returnStr;

}

Component Frameworks (Composites)

• In OpenCom, a component framework (CF) is a tightly coupled set of components that– cooperates to address some focused area of concern;

– provides a well-defined extension protocol that accepts additional “plug-in” components that modify or extend the CF’s behavior; and

– constrains how these plug-ins may be organized.


Calculator

ICalculatorIAdd

Adder

ICFMetaInterface

IMetaInterface ILifeCycle IConnections

IAccept


1.Creating a new Component Framework

public class CalculatorFramework extends CFMetaInterface implementsICFMetaInterface, IConnections, IMetaInterface, IUnknown,ILifeCycle{/** Creates a new instance of CalculatorFramework */public CalculatorFramework(IUnknown pRuntime) {

super(pRuntime);}public Object QueryInterface(String InterfaceName) {// Test if its an exposed interface

return QueryInterface(InterfaceName, this);}

A framework must implement ICFMetaInterface – this provides the core and reflective functionality of the framework. A framework must inherit CFMetaInterface.A framework must implement the QueryInterface class. You can/should implement a component that implements IAccept that is then connected to this framework. All changes are then validated by this component.


2. Reflection operations on CF• Every component framework is subject to the same reflective operations as a

standard OpenCOM component

– The runtime IMetaArchitecture interface provides dynamic inspection of the external structure of a CF (i.e. what it is connected to)

– The local IMetaInterface interface lists the interfaces and receptacles available from the CF

• However, no OpenCOM interface supports inspection or dynamic adaptation of the internal structure of a component framework. Therefore, every CF implements its own additional metainterface, named the ICFMetaInterface interface that consists of methods for

– Introspection• get_internal_components, get_Bound_Components, get_Internal_bindings

– reconfiguration • insert_component, remove_component, Replace_component, local_bind,

break_local_bind, Expose_interface, unexpose_interface, Expose_receptacle, unexpose_receptacle, Replace_configuration, init_arch_transaction, commit_arch_transaction, Rollback_arch_transaction

Component Frameworks - Example

//Step1: instantiate the CF like any other component

IUnknown pCFIUnk = (IUnknown) pIOCM.createInstance("Samples.CalculatorFramework.CalculatorFramework", "Framework");

ILifeCycle pILife = (ILifeCycle) pCFIUnk.QueryInterface("OpenCOM.ILifeCycle");pILife.startup(pIOCM);

//Step2: Create the checking component for the frameworkIUnknown pAcceptIUnk = (IUnknown) pIOCM.createInstance

("Samples.AcceptComponent.Accept", "Accept");pILife=(ILifeCycle)pAcceptIUnk.QueryInterface("OpenCOM.ILifeCycle");pILife.startup(pIOCM);// Connect the checking component to the frameworklong cID = pIOCM.connect(pCFIUnk, pAcceptIUnk, "OpenCOM.IAccept");

//Step3: get the reference to the ICFMetaInterfaceICFMetaInterface pCF = (ICFMetaInterface)

pCFIUnk.QueryInterface("OpenCOM.ICFMetaInterface");

Component Frameworks – Example cont

// Step 4 – begin a reconfiguration – initiate a transaction, this tells the // framework to set itself in a quiescent statepCF.init_arch_transaction();

// Step 5 = create the internal configurationIUnknown pAdd = pCF.create_component("Samples.AdderComponent.Adder", "Adder");IUnknown pCal = pCF.create_component("Samples.CalculatorComponent.Calculator", "Calculator");// Connect the local componentslong connid = pCF.local_bind(pCal, pAdd, "Samples.AdderComponent.IAdd");

// Step 6 – Expose an interfacepCF.expose_interface("Samples.CalculatorComponent.ICalculator", pCal);

// Step 7 – Finish reconfigurationboolean success = pCF.commit_arch_transaction();

//Step 8 – Using the Framework as a standard componentpICalc = (ICalculator) pCFIUnk.QueryInterface(

"Samples.CalculatorComponent.ICalculator");// test the AddSystem.out.println("The value of 18+19 = "+ pICalc.add(18,19));

Component Frameworks – Example checking component

public class Accept extends OpenCOMComponent implements IUnknown, IAccept, IMetaInterface, ILifeCycle, IConnections { /** * Require use of both the meta architecture and meta interface MOPs */ public OCM_SingleReceptacle<IMetaArchitecture> m_PSR_IMetaArchitecture; public OCM_SingleReceptacle<IMetaInterface> m_PSR_IMetaInterface; // IAccept Interface implementation -- Programmatic check /** * This method performs validation checks on CF graphs. * @param graph A Vector containing the internal graph of the composite * @param Intfs A Vector describing the list of interfaces exposed * @param cComps An integer representing the number of components in the graph * @param cIntfs An integer describing the number of exposed interfaces * @return A boolean indicating a valid or invalid configuration **/ public boolean isValid(Vector<IUnknown> graph, Vector<CFMetaInterface.ExposedInterface> Intfs, int cComps, int cIntfs) { /* * Hand coded check on the validity of the calculator framework. * In this case we want 2 components - with the calculator's receptacle * connected. */

The IDebug interface// Get the debug interface

IDebug pIDebug = (IDebug) runtime.QueryInterface("OpenCOM.IDebug");

//dump component configuration to console

pIDebug.dump();

// graphical repesentation of component configuration

pIDebug.visualise();

Uses of OpenCOM (1)• OpenORB: middleware

– Configurable: adapt to needs of different application domains

– Dynamically reconfigurable: to meet the needs of the changing environment

• Built on OpenCOM (the C implementation)

– a given middleware instance is constructed as a set of OpenCOM component frameworks (=composed OpenCOM components)

– Inside each component framework, a configuration manager applies application domain speciffic policies

Example of OpenCOM: OpenORB

G.Blair et al, The Design and Implementation of Open ORB 2, in IEEE DS, 2001

G.Blair et al, Reflection, Self-Awareness and Self-Healing in OpenORB, in ACM WOSS, 2002

Uses of OpenCOM (2)

• Netkit: Programmable Networking Environments on Network Processors

G. Coulson et al, A GENERIC COMPONENT MODEL FOR BUILDING SYSTEMS SOFTWARE, in ACM Trans. Comput. Syst. 26, 1 (Feb. 2008)

Summary

• Why use OpenCOM (or another similar component technology) ?– – – –

Dynamic reconfiguration• Dynamic reconfiguration refers to the ability to change the functionality of

an application at runtime. It is needed in:

– non-stop systems (e.g. business-critical systems) so that an application can be upgraded while it is running.

– adaptive systems which change their behaviour in response to changes in their environment

• reconfiguration in general is a series of ‘add’, ‘replace’, ‘remove’ and ‘connect’ steps.

• OpenCOM components are deployed in a runtime environment which provides API functionality for creating,deleting, connecting, and disconnecting components. Therefore the basis of dynamic reconfiguration is already provided in OpenCOM components - but without any inherent support for safe reconfiguration!

• OpenCOM component frameworks add some safety mechanisms for the dynamic reconfiguration of their internal structure - init_arch_transaction()

Issues in Dynamic reconfiguration• System protection:

Assume that we want to replace a component. Disconnecting the component at an

arbitrary time may cause problems to the application and the platform:

– What if the component we just removed was about to call another component?

– What if another component is about to call the component we just removed?

– If the system does not cater for situations like the above, we might cause the entire application to crash.

• State transfer: The state of a component is a set of data. If the component does not rely on

any data, we

can characterize it as stateless.

– By simply removing the old component and inserting the new one, we will possibly loose any state the old component had. This in turn might cause the entire application to loose its state.

• In OpenCOM, system protection is implemented only for the reconfiguration of component frameworks !

• OpenCOM component framework transactions handle only the issue of System protection, NOT (application-specific) state transfer !

OpenCOM implementation detail

The CF locking mechanism

• each component framework provides a readers/writers lock to access the local CF graph:– Each service call through any of the interfaces other than

ICFMetaInterface accesses the lock as a reader (there can be n readers using the lock at any time).

– Any call to change the configuration of the CF (through ICFMetaInterface), accesses the lock as a writer (a single writer can access the lock when there are no readers).

• The locks are in CFMetaInterface• Locks are accessed in a pre-interceptor attached to all interfaces of a

CF• Locks are released in a post-interceptor attached to all interfaces of a

CF


Interceptors implement the CF locking mechanism

public class CFInterceptors { /** * The reference to the interface of this object's corresponding component * framework. Used to invoke the access lock methods. **/ private ICFMetaInterface pMeta ; /** * Creates a new instance of CFInterceptors and sets the reference to the * CF's API. */ public CFInterceptors(ICFMetaInterface ThisComponentFramework) { pMeta = (ICFMetaInterface) ThisComponentFramework; } public synchronized int Pre0(String method, Object[] args){ … } public synchronized Object Post0(String method, Object result, Object[] args, Exception e){ … } }



/** * Pre0 is inserted onto every exposed interface of the component * framework automatically. * Every operation invoked on the interface * forces the readers count to be incremented. If we are the first reader * we also get the write lock to prevent write access */ public synchronized int Pre0(String method, Object[] args){ // access 1 means we want the readers count sempahore

pMeta.access_CF_graph_lock(1); // Got it, now update the readers counter

int rc = pMeta.update_readers_count(1); // We are the first reader so we must acquire the CF lock sempahore if (rc==1){ // access 0 means we want the CF lock semaphore pMeta.access_CF_graph_lock(0);

} // We've finished with the readers count, release the readers semaphore

pMeta.release_CF_graph_lock(1);return 0;

}



/** * Post0 is inserted onto every exposed interface of the component * framework automatically. * It is executed after every operation of the intercepted interface. * It first decrements the readers count as we've finished read access. * The write lock is released if we are the last reader.*/ public synchronized Object Post0(String method, Object result, Object[]

args, Exception e){ // access 1 means we want the readers count sempahore pMeta.access_CF_graph_lock(1); // Got it, now update the readers counter

int rc = pMeta.update_readers_count(-1); // We are the last reader so we must release the CF lock sempahore if (rc==0){ pMeta.release_CF_graph_lock(0);

} // We've finished with the readers count, release the readers semaphore

pMeta.release_CF_graph_lock(1);return result;}