JCMP: Linking Architecture with Component Building

JCMP: Linking Architecture with Component Building

Guoqing Xu, Zongyuan Yang and Haitao Huang

Software Engineering Lab, East China Normal University

SACT-01, Pusan, Nov. 30th, 2004

A previous version has been presented at poster session of ACM SIGSOFT 04 FSE-12 conference.

Outline

Introduction and Motivation Our Techniques --- Triple-C Model --- JCMPL language ---JCMP toolset Analysis

SEL, East China Normal University

Guoqing Xu, SACT-01, Pusan, Nov.30th, 2004

Problems and Motivation Two basic characteristic of components

defined in the architecture: --- Conform to the architecture Follow the three criteria identified in

[LV95] --- Support a great deal of flexibility A protocol or style is needed to

support the independent building for the composite adaptation.

These two issues are far from orthogonal although their concern is different.



Enforce the architectural conformance (current research)

Three criteria identified in [LV95] ---Decomposition

easy ---Interface conformance

easy ---Communication Integrity

hard



Enforce Communication Integrity (current research) Ask implementers to follow style

guidelines (Rapide with C2 style [Luc96]) --- not enforced automatically Unify implementation and architecture

in one language. (ArchJava [ACN02]) --- doesn’t support architecture design. Both don’t consider composite

adaptation issues. --- there exists the direct client-server

relationship between components.



Composite Adaptation (Current Research) Use Module Interconnection Languages

(MILs) to describe use relationship. --- Jiazzi or Knit Use on-demand remodularization. --- pluggable composite adapter[MSL01] They don’t describe data and control flow

between components and therefore cannot enforce communication Integrity.



Problem conclusions

Current solutions to either of two issues don’t deal with another.

How to support composite adaptation in the context of architectural constraints?



Outline

Introduction and Motivation Our Approach --- Triple-C Model --- JCMPL language --- JCMP toolset Case study and Analysis



Triple-C Model Component-Communicate-through-

Connector. It extends the three criteria in [LV95] in

two aspects: --- A concrete connector in the

implementation for each abstract connector in the architecture.

--- Concrete connectors are used as wrappers to transfer the service flow between the components.



Model Overview Provide Service Component C Request Service

implemented connector

invoke

Component A Component B

Interface: requires: //get data from // connector Implementation: … //get data from // interface …

Interface: provides: //get data from //implementation Implementation: … // Operations

Currently the connector

Specify the communication permission in the arch.

Used as wrapper or glue code to transfer the methods invocation.



Basic ideas of our approach Linking architecture with component

building (composite adaptation). The key technique is to automatically

generate the connector impl. from connector spec in the arch.

We made a JCMP system: --- an ADL: JCMPL --- a toolset: JCMP JCMP/Compiler JCMP/Match JCMP/Checker JCMP/Kernel



JCMPL Language

It uses the Java like grammar at an abstract level.

It is not only an ADL, but also an IDL. It describes only abstractions, without

any detailed type operations. Translated by JCMP/Compiler to the

implementation skeleton.



JCMPL Language (Cond.)

out inScanner Parser

//Parser.jcmpl

public PrimComponent Parser{ public port in{ RequireInterface r{ Token nextToken()throws ScanExceptions; };} }

Public PrimComponent Scanner{ public port out{ ProvideInterface req{ Token next(); }; }}

A Compiler Modelpublic AdvancedComponent

Compiler{ public port in{ RequireInterface get{ ... InputStream getInputStream() }; } public port out{ ProvideInterface err{ Integer getErrCode();... }; } Scanner scanner = new Scanner(); Parser parser = new Parser(); connect sanner.out, parser.in;}



Generated Style AdvancedComponent Compiler

Class Compiler extends AdvancedComponent( Compiler(){ Parser parser = new Parser(); Scanner scanner= new Scanner(); Connector conn =

= new Connector(parser, scanner); super. addConnector(conn); } }

Class Parser extends PrimComponent {… T nextToken(){ return getConnector ().transfer()

; } }

Class Scanner extends AdvancedCompo { ... T next(){ ... } ... }

Connector{ MethodSignature match (MethodSignature req){ /*match*/... return Scanner.next;} T transfer() { return match().invoke(); }

A concrete connector is generated.

The component only requests the services from the connector and publishes their provided services.

The connector performs the dynamic matching and transfer the invocation.



Dynamic interface matching Searching for a pair of “require-provide”

methods which match each other in semantic from two connected ports.

Based on JML Spec. of each method. The matching strategy match_jcmp/match (P , R) = (Rpre =>

Ppre) ^ ( (Ppre^ Ppost) =>Rpost ) Run P and R with test cases to watch

whether their behaviors are observably equal.



Checking conformance in impl. JCMP/Checker instruments methods with

arguments of primitive types. It uses both architecture and

implementations as input to check whether they conform to each other.

If the impl. does not conform to the arch., JCMP/Checker reports errors; otherwise, it compiles the impl. Into the bytecode files (.class).



Why it works—enforce communication integrity in impl.

All interface methods are generated as private. This enforces that all interface methods cannot be directly called.

The only way to call an interface method is through connector, which uses reflection to suppress access checking.

The connector is generated automatically from connector spec., and methods comm. In impl. is therefore enforced to conform to its spec.



Why it works—support composite adaptation Concrete connector serves as glue

codes. When a component is being built, if it

requires a service, only requesting this from the conn.

Conn. uses JCMP/Match to find the suitable method, calls the method, and finally returns the value back when the system is integrated.



Outline

Introduction and Motivation Our Techniques --- Triple-C Model --- JCMPL language ---JCMP toolset Analysis



Performance Issues

The cost in running JCMP system has two components:

--- the runtime cost of type reflection.

--- the extra cost of invocation transfer through the connector.



Experiment

Construct a linked list with a given array of integers.

construct (int[] nodes) Retrieve a node from the given

node ID after the list is constructed.

retrieve (Integer index)



Comparisons

retrieve

Construction



Analysis Summary We found out that encapsulating the

parameters of primitive types into objects took tremendous amount of time.

The cost of method invocation through connector was not obvious.

Since JCMP uses reflection, we suggest objects be used as data to be transferred, rather than primitive values.



Future Work JCMPL is only used at the design level,

without supporting the dynamic description of runtime architecture.

Architectural styles should be considered.

The performance should be optimized in the way of having some other techniques to replace the Java reflection.

Conclusions

To link architecture with component building, we made:

Triple-C model JCMP toolset --- an ADL JCMPL --- JCMP system

Thank you

JCMP: Linking Architecture with Component Building

Documents

Transcript of JCMP: Linking Architecture with Component Building