Top Banner
Aspect-Oriented Middleware by Dapeng Gao A thesis submitted in conformity with the requirements for the degree of Master of Applied Science Graduate Department of Electrical and Computer Engineering University of Toronto Copyright c 2006 by Dapeng Gao
106

Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Apr 27, 2018

Download

Documents

builien
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Aspect-Oriented Middleware

by

Dapeng Gao

A thesis submitted in conformity with the requirementsfor the degree of Master of Applied Science

Graduate Department of Electrical and Computer EngineeringUniversity of Toronto

Copyright c© 2006 by Dapeng Gao

Page 2: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Abstract

Aspect-Oriented Middleware

Dapeng Gao

Master of Applied Science

Graduate Department of Electrical and Computer Engineering

University of Toronto

2006

This thesis proposes a new paradigm, Modelware, for reducing the complexity of mid-

dleware design and implementation. The Modelareware approach distinguishes between

the core architecture design and the crosscutting architectural elements. The crosscut-

ting elements are scattered around the entire middleware code base, can not be easily

encapsulated through the traditional software decompostion model. Aspect-Oriented

Programming (AOP) allows the different abstraction models to be superimposed on top

of one another. By utilizing this capability of AOP, the Modelware approach success-

fully encapsulates the crosscutting features to coherent modules that matches the design

specifications of these features. Both the core and aspect-oriented design in Modelware

utilize the Model Driven Architecture methodologies to further reduce the complexity

of middleware implementation. The Modelware Customization Framework, proposed in

this thesis, ensures that the aspect-oriented features can be correctly composed together.

To evaluate Modelware methodologies, two middleware systems, CORBA and JMS, are

implemented in Modelware, as case studies.

ii

Page 3: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Acknowledgements

First of all, I would like to thank my supervisor, Professor Hans-

Arno Jacobsen, for his guidance on my research and his kindly

help. He brings me to the world of scientific research.

I also would like to thank my fellow graduate students in the

Middleware System Research Group for their kindly support.

Especially, I would like to thank Charles Zhang, with whom I

worked on so many projects.

Last but not least, I would like to thank my parents for their con-

stant support.

iii

Page 4: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Contents

List of Tables vii

List of Figures viii

1 Introduction 1

2 Background 4

2.1 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Aspect-Oriented Programming (AOP) . . . . . . . . . . . . . . . . . . . 5

2.3 Horizontal decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Model Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Related Work 9

4 Modelware Concept 13

4.1 Modelware Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Middleware Base View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Models of Invariant Concepts . . . . . . . . . . . . . . . . . . . . 17

4.2.2 Simplicity and Invariance . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Middleware Aspect Views . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Transformation in Modelware . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Realization: PIM to PSM transformations . . . . . . . . . . . . . 21

iv

Page 5: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

4.4.2 Projection: Transformation of aspect views . . . . . . . . . . . . . 23

4.5 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5.1 Common Object Request Broker Architecture (CORBA) . . . . . 26

4.5.2 Java Messaging Service (JMS) . . . . . . . . . . . . . . . . . . . . 28

4.6 Aspect View Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6.1 Thread-level concurrency . . . . . . . . . . . . . . . . . . . . . . . 31

4.6.2 Data type view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.6.3 Code Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.6.4 Service Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6.5 Portable Interceptor . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6.6 Collocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.6.7 Thread Specific Storage . . . . . . . . . . . . . . . . . . . . . . . 44

4.6.8 Portable Interceptor Thread Specific Storage . . . . . . . . . . . . 45

4.6.9 Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.6.10 Reactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7 Aspect view implementation guideline . . . . . . . . . . . . . . . . . . . . 51

4.7.1 Design from scratch . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7.2 Implement from refactoring . . . . . . . . . . . . . . . . . . . . . 55

5 Modelware Customization Framework (MCF) 57

5.1 MCF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Dependencies, convolution descriptions and constraints . . . . . . . . . . 59

5.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.2 Feature dependency specification . . . . . . . . . . . . . . . . . . 61

5.3 Functionality acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Explicit acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.2 Rule-based inference . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

v

Page 6: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

5.4 Feature cost function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.5 Target synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5.1 Structural schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5.2 Implmentation selection . . . . . . . . . . . . . . . . . . . . . . . 70

6 Evaluation 72

6.1 Modelware CORBA (MORB) . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.1 Runtime characteristics . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.2 Support Middleware Evolution in Time . . . . . . . . . . . . . . . 74

6.1.3 Support Middleware Evolution in Space . . . . . . . . . . . . . . 76

6.2 Modelware Java Message Service (MJMS) . . . . . . . . . . . . . . . . . 79

6.2.1 Runtime characteristics . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.2 Support Middleware Evolution in Time . . . . . . . . . . . . . . . 81

6.2.3 Support Middleware Evolution in Space . . . . . . . . . . . . . . 83

6.3 Modelware Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.4 Modelware Customization . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.4.1 Static properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.4.2 Runtime properties . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7 Conclusion and future work 92

Bibliography 94

vi

Page 7: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

List of Tables

4.1 Base view interpretation encapsulated in aspect views . . . . . . . . . . . 20

6.1 Improvements of using Java New I/O in Modelware . . . . . . . . . . . . 76

6.2 Reusability study of Modelware CORBA in supporting different application platforms 78

6.3 Performance improvements in Publish/Subscribe model . . . . . . . . . . 80

6.4 Reusability study of Modelware JMS in supporting different application platforms 84

6.5 The percentage of reused Modelware implementation on three Java platforms. 85

6.6 Feature Selection and Sythesis in Modelware CORBA . . . . . . . . . . . 88

6.7 Static Comparisons of Modelware ORBs . . . . . . . . . . . . . . . . . . 90

6.8 Runtime Properties of synthesized ORBs . . . . . . . . . . . . . . . . . . 91

vii

Page 8: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

List of Figures

2.1 An aspect-oriented program written in Aspectj . . . . . . . . . . . . . . . 7

4.1 Base view and aspect views . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Transform-time API dependency in Modelware . . . . . . . . . . . . . . . 21

4.3 Transformation of the thread-level concurrency view . . . . . . . . . . . . 24

4.4 CORBA remote invocation . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5 Object Request Broker structure . . . . . . . . . . . . . . . . . . . . . . 27

4.6 Java Messaging Service system . . . . . . . . . . . . . . . . . . . . . . . . 28

4.7 JMS overall design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.8 The UML diagram of basic JMS message handling design . . . . . . . . . 30

4.9 Synchronously receive a message from message queue . . . . . . . . . . . 31

4.10 Asynchronously receive messages from message queue . . . . . . . . . . . 32

4.11 Roles in concurrency view . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.12 The code set view of middleware systems . . . . . . . . . . . . . . . . . . 36

4.13 The interception points on both client and server side . . . . . . . . . . . 40

4.14 Thread context and request context management . . . . . . . . . . . . . 46

4.15 Adaptation aspects connect aspect libraries with base view . . . . . . . . 53

5.1 Modelware Customization Framework stages . . . . . . . . . . . . . . . . 58

5.2 Dependency rules specified in logic notation . . . . . . . . . . . . . . . . 61

5.3 Feature Dependency Specification DTD . . . . . . . . . . . . . . . . . . . 62

viii

Page 9: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

5.4 XML document of feature dependency in Figure 5.2 . . . . . . . . . . . . 63

5.5 Execution of the inference algorithm on the rules in Figure 5.2 . . . . . . 67

5.6 The truth table used by the evaluate function in Algorithm 1 . . . . . . . 67

5.7 The structural schema of Modelware Customization Framework . . . . . 70

6.1 Benchmark comparison of Modelware CORBA to ORBacus . . . . . . . . 73

6.2 Benchmark performance comparison between MJMS and OpenJms . . . 79

6.3 Performance improvements with collocation support . . . . . . . . . . . . 81

6.4 The code size (LOC) and bytecode size of Modelware CORBA and JMS. 85

6.5 Feature dependency specifications in Modelware CORBA . . . . . . . . . 87

6.6 Performance of synthesized ORBs with different request payload . . . . . 90

ix

Page 10: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 1

Introduction

Today’s enterprise computing systems become increasingly complex. They are built on

top of heterogeneous hardware and operating systems, and communicate through var-

ious network conditions. To simplify the software development on such large systems,

middleware systems, such as .Net, J2EE and CORBA, are widely adapted. The middle-

ware tries to hide the underlying system complexity, but the middleware itself becomes

overwhelmingly complex, because the middleware need to handle large number of re-

quirements imposed by the underlying distributed systems.

The architecture of the middleware is designed to support many application domains,

but for most time, only a small subset of the features are actually used. The redundant

functionality causes the performance problems and maintenance problems for middleware

systems. We believe that middleware should be built in a way that it just fits into its

application domain. To achieve this goal, the scattered middleware features must be well

modulized into pluggable units.

Aspect-oriented technologies (AOP) [19] provide a solution for modulizing scattered

software logic. Based on AOP, we develop a set of methodologies to guide the architecture

1

Page 11: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 1. Introduction 2

design of middleware. This design approach dramatically increases the pluggability of

middleware features. Then, these features become candidates for customization. The

previous complex middleware system can be now customized to fit into different user

domains. Since all the customized versions are based on the same core architecture, the

maintenance problem is reduced. This thesis makes the following contributions to the

aspect-oriented middleware design and customization:

1. We present Modelware, a model-driven approach, to separate middleware architec-

tural concerns into multiple ”viewpoints”: an ”intrinsic view” implementing com-

mon middleware functionalities through simple and coherent modules, and ”aspect

views” providing abstractions for non-localized system features.

2. We present an reference implementation of generic middleware architecture by using

Modelware approach. We implement the ”intrinsic view” and ”aspect views” into

reusable middleware library components. We show how these library modules can

simplify the real world middleware design and implementation.

3. We develop a framework to automatically customize the middleware features based

on ”aspect views”. We present the architecture of the framework, and algorithms

and implementation conventions that facilitate the automatic customization.

4. To show that the Modelware reference implemenation can be used to implement

non trivial middleware systems, we present two case studies: Modelware Common

Object Request Broker Architecture (CORBA) and Modelware Java Messaging

Service (JMS). We build these two middleware systems by using Modelware refer-

ence implementation. We quantitatively compare our implementations of the two

systems with popular open source implementations.

The results of this thesis has been partially published in [32] and [31]. In [31], we

present the Modelware paradigm and part of its implementation. In [32], we show how

Page 12: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 1. Introduction 3

to apply the customization techniques to large middleware systems.

The rest of this thesis is organized as the following. Chapter 2 presents a brief

overview of middleware and aspect-oriented technologies to help to better understand

the methodologies discussed in this thesis. Chapter 3 discusses the related approaches to

Modelware. Chapter 4 presents the core concepts of Modelware and its reference imple-

mentations. Chapter 5 discusses the Modelware customization framework architecture

and its underlying algorithms. In Chapter 6, we show the evaluation of our Modelware

CORBA and JMS. The conclusion and future works are outlined in Chapter 7.

Page 13: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 2

Background

2.1 Middleware

We define middleware as a set of services that facilitate the development and the de-

ployment of distributed systems in a heterogeneous networking environment. The design

requirements for middleware are still very complex because they cover two orthogonal

middleware characteristics, identity coupling and temporal coupling, among applications

requesting services (clients) and ones providing computing services (servers). Identity

coupling characterizes how much clients and servers know about each other, and tem-

poral coupling characterizes the degree of synchrony of the message exchange between

them. Traditional RPC-based middleware, such as DCOM 1, CORBA 2, and Java RMI 3,

exhibits strong identity and temporal coupling. Clients and servers of publish/subscribe

middleware, on the other hand, do not know about each others’ identities and do not

synchronize when communicating either.

1Distributed Component Model. http://www.microsoft.com/com/default.mspx2Common Object Request Broker Architecture. URL: www.omg.org3Java RMI. http://java.sun.com/products/jdk/rmi/

4

Page 14: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 2. Background 5

The purpose of middleware such as CORBA, .NET Remoting 4, and Web Services 5 is

to provide uniform and native representations of remote services for distributed applica-

tions to avoid dealing with the high degree of heterogeneity in hardware platforms, oper-

ating systems, communication protocols, programming languages, application semantics,

and many others. In addition, middleware systems also define high-level domain inde-

pendent services to facilitate the business logic development of distributed applications.

For example, middleware vendors commonly bundle services, such as transaction sup-

port, security, and naming, with the final middleware products. Traditional middleware

architectures are often criticized as monolithic or coarse-grained. This high degree of

inflexibility has called for newer paradigms to build versatile middleware architectures

which aptly adapt to ever changing external execution environments as well as require-

ments of features desired by the user applications of middleware.

2.2 Aspect-Oriented Programming (AOP)

Aspects modularize crosscutting concerns, coding concerns that are not localized within

modular boundaries. For example, consider the problem of implementing a set of security

policies for a large software system. By its nature, the security policies must be imple-

mented across many system units. There are no easy ways to encapsulate the security

policies in a single program unit. Then, this implementation will cause big problems for

software maintenance, because once the security policies change, many system modules

need to be updated. Aspect-oriented programming (AOP) allows the developer to cleanly

encapsulate these crosscutting concerns in separate modules [19]. In AOP, conceptually,

a program consists of two modules: a component module and an aspect module. The

component module is implemented in traditional programming languages. The aspect

4Microsoft .NET Remoting. URL: http://msdn.microsoft.com/library/en-us/dndotnet/html/hawkremoting.asp

5W3C Web Services Activity URL: http://www.w3.org/2002/ws/

Page 15: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 2. Background 6

module is implemented in an aspect-oriented programming language, and encapsulates

crosscutting concerns. An aspect weaver takes the component module and aspect module

to produce the final woven program. This weaving process can be carried on in compile

time, load time and execution time.

Aspect-oriented languages, such as AspectJ 6, define a set of new language constructs

to support two kinds of crosscutting: dynamic crosscutting and static crosscutting. The

definition of dynamic crosscutting is based on the concept of join points that denote

well-defined points in the execution of a program. A pointcut refers to a collection of

join points and parameters associated with these join points. A method-like construct,

referred to as an advice, is used to define aspect code executed before, after or in place of

a join point. Static crosscutting affects the static structure of a program, such as classes,

interfaces, and the type hierarchy. Inter-type declarations are used to introduce new

fields and methods into classes or interfaces, as well as new entities into existing type

hierarchies through the declare parents construct. An aspect module includes pointcuts,

the associated advices, inter-type declarations, and declare parents constructs.

Figure 2.1 illustrates a simple aspect-oriented program in AspectJ. The component

module consists of class Work and interface Security; the aspect module contains an

aspect class SecurityAspect. In the final woven program, the first before advice will be

executed before the body of Method doWork is executed; the second before advice will

be executed before the call to Method, doWork. Line 2-4 of the aspect module are static

crosscutting. At Line 2, the class Work is made to be the implementation of the interface

Security; at Line 3, an attribute counter has been added to the class Work; at Line 4,

an attribute isChecked has been added to the interface Security. In Aspectj, the weaving

process is carried on the bytecode.

6AspectJ. http://www.eclipse.org//aspectj

Page 16: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 2. Background 7

1. public class Work{2. public void doWork(){3. ...4. }5. public static void main(...)6. {7. Work w = new Work(...);8. w.doWork();9. }10. }11. public interface Security{12. ...13. }

1. aspect SecurityAspect{2. declare parents: Work implements Security;3. private int Work.counter;4. private boolean Security.isChecked;5.6. before():7. execution(public void Work.doWork()){8. ...9. }10. before(): call(public void Work.doWork()){11. ...12. }13. }

Weaving

Weaving

Component Module Aspect Module

Figure 2.1: An aspect-oriented program written in Aspectj

2.3 Horizontal decomposition

Horizontal decomposition(HD) is a set of principles Charles Zhang and Hans-Arno Ja-

cobsen have proposed in [33] to guide the aspect oriented design and implementation of

complex systems such as middleware. HD principles play the fundamental role in achiev-

ing a very high degree of modularity and enabling the Modelware paradigm because

they effectively address the feature convolution problem prevalent in legacy middleware

architectures. The term ”convolution” is used to denote large-scale N-by-N interactions

among orthogonal features in vertical architectures, those built using hierarchical mod-

ules [13]. We perceive that the implementation of an aspect consists of both its functional

implementation and its possible interactions with every other aspect. HD promotes a two

dimensional architecture in which the vertical architecture implements a minimum set of

essential functionality of the application, and the horizontal architecture captures cross-

cutting concerns including both functional and non-functional features [22]. The hori-

zontal features are decoupled from each other and each can be independently ”woven”

into the vertical architecture. We term this fashion of architecture ”super-impositional

Page 17: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 2. Background 8

architecture” [33].

2.4 Model Driven Development

Generally speaking, model-driven development refers to a software development process

that based on models of the software synthesized code. The Model Driven Architecture

process (MDA) is one prominent example of a model-driven development approach. MDA

advocates developing complex systems through multiple and hierarchical viewpoints. The

”Platform Independent Viewpoint” and the associated ”Platform Independent Model”

does not specify the details necessary for running the system on a particular platform,

which makes it suitable for abstracting the essential functionalities of a system across

a number of middleware platforms. By combining the specifications of the PIM with

the details of how to use a particular type of platform, a ”Platform Specific Model” is

established. A set of mapping rules relate a PIM to its PSM that lays out the details

with respect to a given middleware platform.

Page 18: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 3

Related Work

Related work can be classified into four categories: model-driven software development

approaches; aspect-oriented approach on middleware systems; different strategies on mid-

dleware customization; general software system customization techniques. We discuss

these approaches below, and indicate how our Modelware design and customization ap-

proach is different from these approaches.

Model Driven Development: The challenge of Model Driven Architecture (MDA)

approach is how mappings from ”Platform Independent Model” to ”Platform Specific

Model” can be effectively realized. The approach suggested in this thesis is one possi-

ble realization for automating the mapping between different views and models. Other

approaches aiming at realizing a model-driven approach are [6, 26]. CoSMIC [26] de-

fines a set of domain-specific tools for composing and deploying distributed real-time

and embedded middleware-based applications. Bonnet et al. [6] describe a model-driven

software process for the automated configuration and personalization of smart card soft-

ware. Both approaches do not employ aspect-oriented techniques, which is central to our

approach.

9

Page 19: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 3. Related Work 10

Aspect-oriented Programming: In the context of middleware, we refer to aspect-

oriented programming approaches as existing software platforms that expose hooks for

applications using these platforms to adapt, alter, modify, or extend the normal execution

flow of a service requested. In that sense, the CORBA interceptor mechanisms, although

not explicitly positioned as an aspect-oriented approach, belongs to this category. Other

recent examples, explicitly positioning themselves as aspect-oriented approaches, are the

JBoss AOP approach [8] and the Spring AOP approach [3]. The key difference to our

work is that these approaches expose a number of hooks for enabling the use of the

middleware in an aspect-oriented style. However, our main objective is to build aspect-

oriented middleware through the use of aspect-oriented programming techniques, with

the goal of increasing the modularity of the resulting middleware, to improve the concern

separation in the middleware implementation, and to ultimately enable an automated

model-driven approach. AspectJ2EE [11] is a new aspect-oriented language, specifically

targeted at the generalized implementation of J2EE application servers and applications.

It is a programming language that could form the basis for an approach like ours. Some

work has been done on designing reusable aspects. Clarke andWalker [10] suggest the use

of compositional patterns to better decouple the implementation of crosscutting concerns

from the base classes of a system. Soares et al. [28] show how the use of abstract aspects

effects the re-usability of aspects refactored from a health-care management system. Both

approaches are very different from the role-based approach of designing aspect-oriented

libraries presented in this work.

Customizable Middleware: The FACET [16] project experiments with the con-

cept of feature subsetting in middleware through the aspect oriented implementation of

a CORBA event channel. FACET divides the functionality of the even channel into

the ”base” and ”features” where the ”base” implements the fundamental functionality

of FACET and ”features” are added into the ”base” via AspectJ. A large number of

Page 20: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 3. Related Work 11

configuration possibilities exist in FACET, and feature dependency graphs are used to

limit valid configurations. In terms of implementation techniques, we share some com-

mon design elements, such as the core-based design (base view in our work), the use

of feature dependencies. However, Modelware Customization Framework (MCF) uses a

rule-based feature dependency specification defined in three-valued logic equations. In

MCF, through dependency specifications, we make very explicit both the relationships

among base view and features as well as the relationships among features. This serves

the foundation for automatic inference and synthesis. We also investigate reusability of

aspects and effects of aspects on the middleware evolution, which are not addressed in

FACET.

The MicroQoSCorba project [21] 1 targets resource-constrained environments and

provides both a fine-grained architecture and CASE tools to make automatic adjust-

ments according to the variations in both user applications and platforms. Similar to

our approach in CORBA case study, MicroQoSCorba also uses IDL compilers to collect

required middleware features and to direct the building process to select relevant imple-

mentations. The feature dependencies and the inference stage are not explicitly addressed

in MicroQosCorba. Most importantly, Modelware provides a higher degree of modularity

using AOP and scales in two dimensions. We have similar approaches to MicroQoSCorba

of making key middleware elements lightweight. However, contrary to MicroQoSCorba,

our ”customization” is not at the cost of losing the original full functionality, benefiting

from the aspect oriented approach. As we have illustrated, the configuration domains

of Modelware are not limited to embedded systems and also include other application

domains.

Product Lines and Generative Programming: GenVoca [4] advocates the syn-

1MicroQoSCORBA. URL: http://microqoscorba.eecs.

Page 21: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 3. Related Work 12

thesis of a family of complex systems from incrementally adding features to simple ones

using step-wise-refinement (SWR). The AHEAD tool suite allows algebraic specifications

of the SWR relationships among features and carries out the automatic synthesis. Gen-

Voca embodies a rich yet comprehensive methodology for programming specification and

program generation. Comparatively, our research has two slightly different focal points:

we focus on the higher degree modularization in large and complex software systems such

as middleware through the effective use of aspects; we focus on improving module-level

resusability and the ability to adapt in face of functionality evolution and diversification.

Colyer and Clement [12] demonstrated how aspect-oriented refactoring can be used to

support commercial middleware product families. The focus of their work is to evaluate

the suitability of AOP in supporting very large software projects through capturing

crosscutting features in aspects and weaving them into other product family members as

new features. They provide valuable experiences and insights which benefit us in scaling

MCF to support even larger size middleware implementations.

Page 22: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4

Modelware Concept

4.1 Modelware Overview

The middleware platforms are mainly used to interconnect the system components of

distributed systems. Therefore, the primary requirement for middleware platforms is to

provide a communication mechanism, and the abstraction on top of the communication

mechanism to simplify the construction of distributed systems [20]. Middleware sys-

tems should be generic across applications and industries, they should run on multiple

platforms, they should be distributed, and they should support standard interfaces and

protocols [5]. These properties of middleware impose the extra requirements on middle-

ware implementation in addition to the communication concern.

Conventionally, middleware systems are implemented by taking account of all the

requirements together. The architecture, designed in this way, is incapable of adequately

dealing with ”change” in time (functional evolution) and space (functional diversifica-

tion), because of the high concern density for each architectural element. To simplify

the design of the middleware architecture, the requirements of a middleware system

should be categorized as intrinsic and extrinsic properites. Borrowing the terms from

13

Page 23: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 14

subject-oriented programming [1], we use the term ”intrinsic” to characterize middleware

architectural elements that are essential, invariant, and repeatedly used despite the varia-

tions of the application domains. These common abstractions are typically pattern-based

designs, such as proxy, forwarder-receiver [9], and acceptor [25]. Contrarily, we use the

term ”extrinsic” to denote elements that are vulnerable to refinements or can become

optional when the application domains change. A simple example of an extrinsic prop-

erty is thread-level concurrency, including patterns such as leader/follower [25], which

can become redundant when threading policies are controlled by user applications or if

the underlying platform, such as Java Card 1, does not support threads at all.

Many ”extrinsic” properties are crosscutting in nature, i.e., not localized within mod-

ular boundaries. For example, the persistence support is to provide some facilities to

store the application data at various processing stages into the secondary storage media,

and retrieve the data from such media, so that the important system information is not

lost during the system failure or shutdown. Normally, such persistence support is de-

signed and implemented across the whole system architecture. This crosscutting nature

makes the architectural design more complicated, and decreases the reusability of the

architecture. The root cause is that the traditional implementation technology cannot

adequately separate the crosscuting ”extrinsic” properties from the ”intrinsic” proper-

ties. Aspect-Oriented Programming (AOP) is a promising technology to modularize the

crosscutting features. AOP languages use a join point model as a common frame of ref-

erence so that the execution of a program’s aspect and non-aspect code can be properly

coordinated [2]. This join point model can be used to compose the ”extrinsic” properties

with the ”intrinsic” properties for the middleware construction. The advice mechanism

of AOP encapsulates the scattered middleware logic; the pointcut mechanism maps this

logic to the join points in the implementation of the ”intrinsic” properties.

1Java Card. http://java.sun.com/products/javacard/index.jsp

Page 24: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 15

By applying AOP to the middleware construction, we propose a new architectural

paradigm, Modelware, which embodies the multi-viewpoints [23] approach. We cap-

ture intrinsic properties, or common abstractions, in a base view consisting of a set

of coherent components free of crosscutting concerns. The components in base view

are designed and implemented in conventional programming paradigms, such as Object-

Oriented programming and procedural programming, and these components can perform

actual computation. We use role-based aspect views and aspect libraries to capture ”ex-

trinsic properties”, i.e., domain variations. we adopt the Model Driven Architecture

(MDA) 2 in the base view as the vehicle for the mapping abstractions to implementa-

tions. The benefit of this design is that the components of the base view modules are

simple and more coherent, so they are more tolerant to variations of application con-

texts. By employing the AOP class-directional approach, i.e., the aspect knows about

the class but not vice-versa [18], the ”extrinsic” properties become pluggable features

of middleware architecture and implementation. Concrete middleware instances can be

produced by the realization process: selecting the implementations of the abstractions in

the base view, and the projection process: creating ontological relationships between the

elements in aspect views and those in the base view. Before details of the models are

discussed, we want to rephrase a few MDA nomenclatures in the context of Modelware.

Our definition of the Platform Independent Model (PIM) refers to abstract concepts in

the base view. We define the Platform Specific Model (PSM) as the refined models of

these concepts for specific functional requirements or deployment platforms. For aspect

views, we introduce role models as abstractions for the behavior of aspects.

As illustrated in Figure 4.1, each aspect view contains its own set of role models. An

aspect view interacts with base view models via roles in a non-localized manner.

2MDA. http://www.omg.org/mda

Page 25: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 16

Hierarchical base view

Aspect view 1

Aspect view 2

Role A

Role CRole B

Role 1

Role 3Role 2

Figure 4.1: Base view and aspect views

Section 4.2 and 4.6 explain the base view and aspect views in the context of mid-

dleware construction. We also provide a set of reference models for the base view and

reference implementations for aspect views to concretize the Modelware methodologies.

Although Modelware is proposed to reduce the complexity of the middleware construc-

tion, it is applicable to all the complex software systems that need to support many

features and adapt to various application contexts.

4.2 Middleware Base View

Modelware is an approach to architect and build new middleware platforms. By applying

the Modelware methodologies, we can reduce the concern complexity in both the ”intrin-

sic” and ”extrinsic” properties. Another important benefit, provided by Modelware, is

that due to the simple and coherent designs, the reusability of the middleware architec-

tural elements and their implementation, i.e. the ”intrinsic” properties, is dramatically

increased. It has long been recognized in literatures [9, 25, 30], that design patterns play

essential roles in middleware architectures. In their specific problem contexts, design

patterns exhibit invariance in both space and time. In this section, we describe a set of

Page 26: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 17

such ”invariant concepts” including patterns as well as a number of design choices which

we believe to represent common and essential functionalities of middleware. We capture

and implement these ”invariant concepts” in the base view, so that they can be re-used

in different middleware contexts.

4.2.1 Models of Invariant Concepts

The primary responsibility of the ”invariant concepts” in the base view is to support

the transparent interpretation and transportation of RPC (Remote Procedure Calls)

operations. We enumerate a few essential elements and describe their semantics with

respect to how they interpret the application requests made through RPC:

1. Proxies (stub and skeleton): Stubs and skeletons are entities masking the middle-

ware substrate as native programming facilities of the user application. Proxies see

the application requests as regular method invocations.

2. Connection facilities (acceptor and connector): Acceptors and connectors ”decouple

the connection and initialization of peer services ... from the processing these peer

services perform after they are connected and initialized” [25]. Connection facilities

see the application requests as a sequence of bytes sent to or received from network

hosts.

3. Protocols (initiator and responder): Protocol initiators and responders (also called

forwarder-receiver [9]) leverage connection facilities and implement a particular

sequence of message exchange between clients and servers. Protocols see the ap-

plication requests as a set of generic messages subject to a specific temporal order

and a specific spatial structure.

4. Request sessions and service sessions: A request session and a service session rep-

resents an instance of interaction among elements of proxies and protocols in the

Page 27: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 18

client and the server side, respectively. Sessions see application requests as instances

of collaborations between proxies and protocols.

5. Buffer: Buffer is a commonly used data structure for encapsulating the application

data. Buffer represents the application requests as a bounded array of bytes and

provides interfaces to manipulate this array.

6. Messages (outgoing and incoming): Messages, including both outgoing and incom-

ing messages, represent the encoding and decoding of byte-oriented data in Buffer

with respect to type-oriented data in user applications. Messages see application

requests as typed and directional data traversing the middleware stack.

7. Servant: Servant is the internal representation in Modelware of the hosted servers.

It serves as a level of indirection between Protocols and Skeletons to facilitate man-

agement tasks. It sees application requests as invocation requests to be dispatched

to the destination services.

4.2.2 Simplicity and Invariance

There are two important goals driving our design of the base view models: simplicity and

invariance. On average, there are only around two operations associated with each entity,

and most of these operations accept a single input parameter. This kind of simplicity

is not arbitrary but derived from a small middleware core refactored out of its complex

original version. In other words, this base view is intended to capture the smallest com-

mon denominator of middleware architectural variations. An implementation of these

base view models is successfully re-used in both the construction of a CORBA-style RPC

system and a Java Message Service (JMS) system 3, as discussed in Section 4.5.

3Java Message Service (JMS). http://java.sun.com/products/jms/

Page 28: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 19

More importantly, the base view concepts are stable designs surviving evolutions and

variations in many middleware implementations. In addition to design patterns, some

concepts are specified as standards, such as request (specified as streams in CORBA) and

servant (specified as the object adaptor in CORBA). Others are widely adopted practices,

such as buffer and session 4. Being resilient to evolution is crucial to the base view in

the Modelware methodologies as it provides the foundation, i.e., architectural invariance,

for establishing and integrating aspect views. As summarized by Grady Booch 5, we

adhere to the simplicity via common abstractions and mechanisms” principle to manage

the complexity of change in middleware architectures.

4.3 Middleware Aspect Views

The aspect views represent and capture the functionalities and features that cannot be lo-

calized. In the middleware domain, such features include concurrence control, persistence

support, transaction and so on. Aspect models and views re-distribute the complexity

of middleware implementation from a single flat module hierarchy to multiple separated

and independent implementations of specialized middleware concerns. Normally, these

features cannot perform the actual computation independently, they only affect the ex-

ecution of the base view modules. In the Modelware methodologies, each aspect view

is oriented upon one or many roles specifying a specific interpretation of the Modelware

base view. These interpretations are encapsulated within the aspect view as shown in

table 4.1.

Each aspect view interacts with the base view through ”projection”: a process of

establishing an ontological relationship by mapping aspect roles to base view entities and

fulfilling the aspect contracts on them. There are two types of contracts: abstract in-

4These design elements are present in all of the three major open source Java CORBA implementa-tions, namely JacORB, ORBacus, and Sun ORB.

5Grady Booch. The Complexity of Programming Models. Keynote speech at AOSD2005.http://www.booch.com/architecture/blog/artifacts/Complexity.ppt

Page 29: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 20

Base view interpretation Description

Role attributes Additional program states of the base view

Role behaviours Additional operations that the base view concepts can perform

Role relationships The interactions among roles within the aspect view

Contracts The interfaces for transferring control between

aspect views and the base view

Table 4.1: Base view interpretation encapsulated in aspect views

terception points (or pointcut in AOP terms) and abstract operations enforced by roles.

Abstract operations link the behavior of a role to an base-view entity. Abstract point-

cuts define points of execution and associated computation contexts of the base view for

aspect views to intervene.

Different from generic roles in design patterns as well as conventional aspect ori-

ented treatments of patterns [15, 17], we make heavy use of domain-specific roles that

know about the base view abstractions such as buffer or transport. This dependency

is necessary for making a large number of middleware functionalities reusable such as

the synchronous communication model, the marshalling/ unmarshalling of data types,

and many others. We believe this dependency does not restrict the flexibility of the

architecture for two reasons:

1. due to the strong invariance of the base view, the pointcut mapping is stable because

the modular structures and the dynamic behaviours of the base view models are

unlikely to change rapidly.

2. The dependency is made upon abstract models, therefore, stay unaffected by the

platform specific implementations.

Page 30: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 21

4.4 Transformation in Modelware

The transformation process in the Modelware methodologies is a process to produce the

software instances from a set of generic models. This process consists of two independent

operations: 1. realization, mapping base view models to concrete implementations; 2.

projection, mapping aspect libraries (aspect views) to concrete implementations of the

base view. The realization operation relies on an implementation library that stores

simple and coherent implementation models. We discuss all the transformation within

the Java language framework as it provides a mature environment for supporting both

the base view and aspect views. The following sections describe the realization and the

projection processes in detail.

4.4.1 Realization: PIM to PSM transformations

OCI API ETF API

Acceptor_ interface

Acceptor_ interface

Conventional Approach Modelware Approach

Development time type dependency

OCI API ETF API

Acceptor_ interface Transformation time

type dependency

OCI Transformation

(weave) profile

ETF Transformation

(weave) profile

Acceptor_impl Acceptor_impl

Acceptor_impl

Figure 4.2: Transform-time API dependency in Modelware

The PIM to PSM mapping is to establish mappings between abstract model elements

and their concrete implementations through either sub-typing or direct substitution. Cen-

tral to this process is the Modelware implementation library which aggregates two types

of reusable components: functional implementations and public application program-

Page 31: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 22

ming interfaces (APIs). The implementation of models can be native, if it is part of the

implementation library, or foreign, if it already exists in third-party libraries. Proper

adaptation of foreign implementations might be needed to conform to the operations of

Modelware entities. For example, Modelware can leverage zero-copy buffers in the Java

NIO libraries to achieve high performance I/O. The adaptation of the foreign component

ByteBuffer to the IBuffer base view entity is simple leveraging the language facilities

and the bytecode weaving capabilities of AspectJ. Most of the native implementations

come out of a crosscutting free version of ORBacus as a result of our long term refac-

toring efforts [33]. A noteworthy characteristic of these implementations is that they are

deliberately kept minimal by supporting simple behavior. For instance, the implemen-

tation of request handling assumes no response, and the transports are non-concurrent

and incapable of handling fragmented messages. To reduce the coupling among concrete

implementations, a number of patterns can be used including factories [14] and inversion

of control (IOC) principle 6.

The Modelware implementation library also contains modules defining public appli-

cation programming interfaces. A particular set of public APIs represents a predefined

”look and feel” for accessing middleware services. For instance, there are multiple public

APIs for enabling the pluggability of network transports in CORBA such as the Exten-

sible Transport Framework (ETF), defined by the OMG, and the Open Communications

Interface (OCI), defined in ORBacus 7. Conventionally, public APIs are typically hard-

wired to implementations at the development time by a type hierarchy. In Modelware,

the base view models serve as a level of indirection between the implementations and

the public APIs, so that public APIs can be plugged in and changed at post-compilation

time. As illustrated in Figure 4.2, by separately managing the implementation and the

6Martin Fowler. Inversion of Control Containers and the Dependency Injection patternhttp://www.martinfowler.com/articles/injection.html

7ORBacus OCI http://www.orbacus.com/support/new site/manual/4.2.1/usersguide/index.html

Page 32: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 23

interface, better flexibility and reusability can be achieved by creating the appropriate

”look and feel” under external transformation directives.

4.4.2 Projection: Transformation of aspect views

The ”projection” operation consists of two steps. We first determine the correspondence

between entities in the base view and the roles in the aspect view. In the aspect li-

brary code, roles are represented by Java interfaces and instrumented with additional

operations and states through AspectJ. Leveraging AspectJ’s capability of type hierar-

chy modification, this mapping operation is straightforward and affects every concrete

implementation of the mapped base view entity. Once the mapping is established, we

need to fulfill the contracts declared by the aspect view. This is a process of locating con-

crete interception points and providing implementations of new operations for the base

view classes, as the result of ”role playing”. Since contracts are composed of abstract

programming elements, the enforcement can be accomplished by the AspectJ compiler.

To further illustrate the mapping process, we present a usage scenario of the concur-

rency aspect view. Figure 4.3 shows the Modelware implementation of the server-side

request handling. While the focus is not the exact semantics of these statements, we

want to illustrate a typical ”simplistic” Modelware implementation - it is only about

the operational logic of request processing. Many common concerns, such as iterative

processing, thread safety, and concurrency, are absent. Instead of hardwiring into code

as in conventional ways, we illustrate how we enable the ”thread-per-connection” concur-

rency support with a minimal coding effort using the Modelware threading aspect library.

Figure 4.3(B) is a code snippet showing only the core operations of the thread library.

Line A defines a contract using an abstract pointcut to capture the constructor invocation

of the ThreadWorker made by the ThreadOwner. Lines B2-B5 create a thread before

Page 33: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 24

Figure 4.3: Transformation of the thread-level concurrency view

the constructor call, assign the newly constructed ThreadWorker to the thread, start the

thread, and return the created ThreadWorker instance. The ”thread-per-connection”

concurrency model requires the server-side request handling, i.e., the operation process

(line 5 in Figure 4.3(A)), to execute in a separate thread. Therefore, the base-view class

ProtocolResponder plays the ThreadWorker role, and the base-view class ProtocolRe-

sponderFactory (line 4) plays the ThreadOwner role. Figure 5(C) shows the projection

code: line 1-2 modify the type hierarchy of the base view entities; line 3 fulfills the abstract

pointcut contract by specifying the constructor call of all subtypes of ProtocolResponder;

line 4 cancels the invocation to the to-be-made-concurrent method ”process” in the main

thread, and line 5-6 fulfills another contract by specifying the method ”process” is to be

executed concurrently. The actual functionality of our thread library is more complex in-

Page 34: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 25

cluding thread lifecycle management, state transition support, synchronization support,

and others. Our experience, also as shown in this simplified example, is that, once the

roles are mapped, the code needs to be created is simple and small in size. In addition,

since the projection code itself is an aspect module, many different projections can be

implemented to support additional concurrency models without intrusive changes to the

base view entities. In addition, in scenarios where middleware threading is not required

or cannot be used, the plain implmentations can still be used.

4.5 Case Studies

To study the effectiveness of the Modelware approach, we presents two middleware system

implementations based on the reference implementation of Modelware. They are Model-

ware CORBA (MORB) and Modelware JMS (MJMS). CORBA stands for the Common

Object Request Broker Architecture, defined by the Object Management Group (OMG).

The CORBA standard defines a distributed object model by providing a set of applica-

tion programming interfaces (API). The distributed applications can be built on top of

CORBA API by utilizing the distributed objects, and the CORBA system takes care of

the underlying communication. MORB implements the CORBA-like API in Java, and

support remote method invocation. Java Messaging Service (JMS) is a Java enterprise

messaging system that facilitates the data transmission between different enterprise ap-

plications. The JMS standard defines a set of API to allow the message clients to create,

send and receive enterprise system messages. MJMS implements the JMS API for the

message clients and a message server. The CORBA model provides a ”synchronous” op-

eration, which means the requesting application need to wait for the reply from the other

application; the JMS model provides a ”asynchronous” operation on the other hand,

because the message server separates the message-sending application and the message-

receiving application. In Section 4.6, we discuss a set of aspect view implementations,

Page 35: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 26

and show how these aspect views can be mapped into MORB and MJMS to demon-

strate how these crosscutting features can be successfully re-used under the Modelware

approach.

4.5.1 Common Object Request Broker Architecture (CORBA)

Client applicat ion/remote objectimplementation

Portable skeleton/stub

ORB specific skeleton/stub

Request marshalling layer

Transport layer

ORB

send/receive octet stream

ORB internal request messages

local method invocation

local method invocation

Network

ORB ORB

Portable stub Portable skeleton

network connection

clientapplication

object remoteimpl

Figure 4.4: CORBA remote invocation

Figure 4.4 shows how a client application can invoke the operations of an remote ob-

ject residing at a remote object server in CORBA. The client application and the remote

object talk to each other through an Object Request Broker (ORB) which resides at both

the client machine and the server machine. Typically, the client application does not di-

rectly talks to the ORB core, and its invocations go through a generated stub layer. The

remote object implementation interacts with the ORB core through a generated skeleton

layer. Figure 4.5 show the structure of the ORB. This structure is based on the design

of ORBacus 8. The ORB translates a local method to a remote request. The request

marshalling layer handles the communication independent request protocol (initiator and

responder), and the interaction between the upper layer and the lower layer (request ses-

8An industrial strength open source CORBA implementation. http://www.orbacus.com/

Page 36: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 27

sion and service session). The transport layer deals with the underlying communication

network, and utilizes acceptors and connectors components. Based on the design shown

in Figure 4.5, other CORBA services and features can be implemented.

Client applicat ion/remote objectimplementation

Portable skeleton/stub

ORB specific skeleton/stub

Request marshalling layer

Transport layer

ORB

send/receive octet stream

ORB internal request messages

local method invocation

local method invocation

Network

ORB ORB

Portable stub Portable skeleton

network connection

clientapplication

object remoteimpl

Figure 4.5: Object Request Broker structure

The key base view elements of Modelware CORBA are implemented largely by gener-

ically reusing ORBacus components such as buffer, acceptor, connector, transport, and

GIOP encoding/decoding algorithms. The following properties are implemented in aspect

views, described in Section 4.6: data types such as long and char, two way communi-

cation model, thread-level concurrency, thread safety, codeset support, service context,

portable interceptor mechanism, and Java NIO support(including reactive request han-

Page 37: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 28

dling). The base view elements, without any aspect libraries, are capable of handling

remote invocations with octet and integer data types. The reliability of message passing

is guaranteed at the network level, and the receiving side processes requests passively.

4.5.2 Java Messaging Service (JMS)

Connection factory,Connection,Session

Request marshalling layer

Transport layer

send/receiveoctet stream

Network

local invocation

Message handling layer

Request marshalling layer

Transport layer

send/receiveoctet stream

Network

local invocation

JMS client (messageproducer/consumer)

JMS message server

JMS messageserver

JMS client(Message Producer)

JMS client(Message Consumer)

network network

Figure 4.6: Java Messaging Service system

As shown in Figure 4.6, the semantic of the JMS system is that the message client

sends messages to or receives messages from the message server. The JMS API defines

two different messaging models: point-to-point and publish/subscribe. In the point-to-

point model, the clients send messages to and receive messages from the queues on the

message server; in the publish/subscribe model, the subscribers subscribe to a topic on

the server, once a publisher publishes a message to the topic, every subscriber of that

topic will receive a copy of the message. For a typical JMS application, the client creates

a Connection object, which represents an active connection to the JMS server. Due to

the communication setup, the Connection object is heavyweight JMS object, so most

applications only create one Connection object to a server. A Connection can sup-

port many Sessions. A Session is a single-threaded context for sending and receiving

messages. A client can retrieve messages synchronously and asynchronously. The syn-

chronous receiving requires the client to actively contact the server to get the messages;

in the asynchronous receiving, the server will contact the client to deliver the messages.

Figure 4.7 show the design of typical JMS server and client. This structure is based

Page 38: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 29

Connection factory,Connection,Session

Request marshalling layer

Transport layer

send/receiveoctet stream

local invocation

Message handling layer

Request marshalling layer

Transport layer

send/receiveoctet stream

local invocation

JMSclient

JMS messageserver

JMS messageserver

JMS client(Message Producer)

JMS client(Message Consumer)

network network

Network Network

Figure 4.7: JMS overall design

on the design of OpenJms 9. Both the JMS server and client have the request mar-

shalling and transport layer, which are the similar design as the ORB (see Figure 4.5).

The client side provides the implementations of Connection Factory, Connection and

Session, which are the facilities used to transmit messages with the server. The message

server includes the modules to support the point-to-point and publish/subscribe messag-

ing models. Figure 4.8 shows the UML diagram of the basic design in the messaging

handling layer of the JMS server. Each Destination object represents a message queue

or a message topic, and stores the actual instances of the messages. The MessageMan-

ager is an singleton object, deals with the requests from the message client, and has the

access to the Destination objects. The Consumer on the server is the entity, which

represents a message-receiving party on the message client. Each Consumer caches a

set of message handles that are used to retrieve the actual messages before contacting

the message client.

Figure 4.9 and Figure 4.10 are examples of sending and receiving messages on the

JMS server. The examples show the sending and receiving of the point-to-point model.

9An open source JMS implementation. http://openjms.sourceforge.net/

Page 39: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 30

Destination ConsumerMessageManager

MessageContainer

Message

MessageReferenceCache

1 0..* 1 0..*

1

1

1

1

1

0..*

MessageHandle

1

0..*

1

-reference

1

Figure 4.8: The UML diagram of basic JMS message handling design

The sending and receiving of the publish/subscribe model are similar. The execution

steps on the JMS server are labelled with sequence numbers. In Figure 4.9, Step 1-3

shows that a JMS client sends a message to the server; Step 4-9 shows that another JMS

client sends a request to the server to receive the message synchronously. In Figure 4.10,

Step 1-3 shows that a JMS client send a message to the server; Step 4-6 shows how the

server detects the waiting JMS client and sends the message to the client asynchronously.

Note that the topic destination is not shown in Figure 4.10.

Similar to the Modelware CORBA, the implementation of Modelware JMS (MJMS)

largely reuses the elements of base view and aspect views (see Section 4.6), such as con-

currency support and callback, from the the modelware library. The high-level logic, such

as message handling behaviour, largely follows the style of OpenJms. MJMS supports

Page 40: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 31

MessageManager

Request marshalling layer

Transport layer

Network

Queue

MessageContainer

1

2

3

MessageManager

Request marshalling layer

Transport layer

Network

Queue Topic

MessageContainer

1

MessageContainer

2

3

9

8

7

4

5

6

Consumer

4

6

5

MessageProducer

MessageConsumer

JMSserver

MessageProducer

MessageConsumer

JMSserver

Figure 4.9: Synchronously receive a message from message queue

both point-to-point and publish/subscribe model, and is capable to receive messages from

the message server synchronously and asynchronously.

4.6 Aspect View Implementation

Next, we present several reference aspect view implementations in the context of middle-

ware design. The projection process of aspect views is presented in Section 4.4 .

4.6.1 Thread-level concurrency

Description: Threads are common concurrency primitives popular in middleware im-

plementations for achieving efficient request handling. From the perspective of the

thread-level concurrency view (TC view for short), entities in the base view are of three

kinds: non-concurrent, thread owners, and objects carrying the logic for the concurrent

task. Currently, the TC view supports two well-studied middleware concurrency mod-

els, thread-per-connection and thread pool. The thread-per-connection model detaches

Page 41: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 32

MessageManager

Request marshalling layer

Transport layer

Network

Queue

MessageContainer

1

2

3

MessageManager

Request marshalling layer

Transport layer

Network

Queue Topic

MessageContainer

1

MessageContainer

2

3

9

8

7

4

5

6

Consumer

4

6

5

MessageProducer

MessageConsumer

JMSserver

MessageProducer

MessageConsumer

JMSserver

Figure 4.10: Asynchronously receive messages from message queue

a new thread for a new network client. The thread-pool concurrency model initializes

a fixed number of threads to execute tasks simultaneously. Threads in the thread-pool

model are reused upon the completion of the task instead of being destroyed. The be-

haviour of threads is implemented in the library and automatically applied to the objects

in the base view if these objects ”play” the prescribed roles through specific projection

transformations as illustrated in Figure 4.11. We discuss details of these transformations

in Section 4.4.2.

Type: Domain independent. The TC view does not depend on any abstractions in

the base view.

Roles and role relationships: The basic roles in the TC view are Thread Owner

and Thread Worker. The thread worker contains the program logic to be executed concur-

rently, and the thread owner is an object in which the thread worker is created. Through

projection, the thread owner role transforms the corresponding base view entities to dif-

Page 42: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 33

Figure 4.11: Roles in concurrency view

ferent types of thread containers, and the thread worker role forces the corresponding

base view object to conform to a uniform interface used by the internal threads of the

library. Each role has two sub-roles to support the afore-mentioned two concurrency

models.

Role contracts: Each thread owner role is associated with a set of abstract oper-

ations and pointcuts. For instance, threads in the TC view are associated with states,

much like Java threads. These states are often required to coordinate with the running

state of the base view objects, e.g., observing the creation, the activation, or the disposal

of the thread owners. The ”stateTranslate” operation defined by the thread owner role

forces base view objects which ”play” this role to provide concrete mappings of base view

states. Every thread owner is also associated with a set of abstract pointcuts, among

which the most fundamental ones are to denote when threads need to be created and

destroyed. In the case of the thread-pool model, an additional pointcut is used to define

the point when the new data arrive, and a sleeping thread can be awoken to consume

them.

Page 43: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 34

Mapping: The mappings of this aspect view in both MORB and MJMS are similar.

In both cases, we map the protocol responder to the thread worker role, and the proto-

col responder factory to the thread owner role. A thread is created when a responder

is initialized. Since each responder handles one network connection, then the multiple

connections are handled by multiple threads. Since in some cases, after a request, a reply

is expected at the client side. Therefore, we also map the protocol initiator to the thread

worker role and the protocol initiator factory to the thread owner role, so that the client

can create a separate thread to deal with the reply. As shown in Figure 4.11, we also

provide a thread-pool implementation of the thread owner. We utilize this implementa-

tion on the MJMS message server, so that the server maintains a pool of threads, and

each thread is re-used for the requests from different connections. This design prevents

the server performance to degrade sharply when there are large number of JMS clients

connected to the server due to the thread creation and context switch overhead.

4.6.2 Data type view

Description: Data marshalling/unmarshalling is an essential middleware functionality

responsible for translating typed information in the middleware user application into an

ordered array of bytes. The data type view is an aggregation of a number of primitive

type views, each specializing in dealing with a single middleware data type.

Type: Domain-dependent. The data type view makes use of the Buffer abstraction

in the base view.

Roles and role relationships: The data type view consists of two roles, the mar-

shaller role and the unmarshaller role. They represent entities responsible for encoding

and decoding the user application data of the middleware. No relationships are imple-

Page 44: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 35

mented between the marshaller role and the unmarshaller role as they represent two

independent directions of data conversion.

Role contracts: Both roles force the projected base view objects to implement an

interface for retrieving the underlying data, i.e., a Buffer instance.

Mapping: The mapping of this view is straight forward. In both MORB and MJMS,

the marshaller and unmarshaller roles are mapped to the message concept of the base

view by using Aspectj ”declare parents” capability.

4.6.3 Code Set

Description: Character code set defines the direct mapping between a set of characters

and their bit representation or numeric value. Example includes ASCII, ISO 8859-1,

UCS-4 (32-bit Unicode Transformation Format) and UCS-2 (16-bit Unicode Transfor-

mation Format). The middleware systems run in a large distributed environment across

many computing platforms and geographical regions. The different computing platforms

could use different character code sets. For example, if an Unix operating system uses

UCS-4 and a Windows operating system uses UCS-2, then the middleware running on

these two platforms cannot exchange textual information between each other. As shown

in Firgure 4.12, to solve this interoperability problem, OMG defines a code set conver-

sion mechanism for its CORBA specification. Based on this specification, we create this

aspect view. This mechanism assumes a underlying client/server architecture. Both the

client and the server have their own native code set, and they use a common transmis-

sion code set to communicate between each other. The code set conversion can happen

at either the client side or the server side. The choice depends on the usage scenarios.

For example, to reduce the computation load of the server, the client can use the server

code set as the transmission code set and do the conversion at the client side, then the

Page 45: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 36

server can directly interpret the textual information without conversion. To simplify the

conversion process, the OMG specification also defines an automatic code set negotiation

mechanism, so that both the client and the server can easily adapt to different code set

converters.

C l i e n t p r o c e s s S e r v e r p r o c e s s

m i d d l e w a r e m i d d l e w a r e

transmission

code set

client nativecode set

server nativecode set

Figure 4.12: The code set view of middleware systems

Type: Domain-dependent. The Code Set view uses the Buffer, Messages and Proxies

abstractions from the Modelware base view.

Roles and role relationships: the basic roles of code set view are code set seed,

conversion manager and text stream. The code set seed encapsulates the information of

the server native code set. The client knows about the server code set by extracting the

code set seed. The client compares the server code set with its own code set to decide

what converters to use or if the conversion is required. Then, the client will attach the

converters to the incoming and outgoing text stream. Later, the conversion process will

take place when the read/write operations are performed on the text streams. To inform

the server about the transmission code set, the relevant information is encoded in service

context of the requests to the server. The service context is another aspect view, which is

discussed in Section 4.6.4. The server decides what converters to use by the transmission

code set, and then attaches the converters to text streams. The conversion managers on

both the client and the server manage the entire process described above. Note that the

Page 46: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 37

code set converter is internal to this aspect view, and it is not required to be implemented

by the aspect library user.

Role contracts: The code set seed is associated with abstract operations for en-

coding and decoding code set information. The conversion manager is associated with

pointcuts for specifying where to get the native code set and the code set seed, where to

attach and extract service context, and where to apply converters to text streams. The

text stream provides abstract operations for reading/writing characters.

Mapping: In MORB, the code set seed role is mapped to the remote object ref-

erence, so that the CORBA client can extract the server code set information from the

object reference. The object stub is mapped to the conversion manager at the client side,

because any remote invocation starts with the stub; at the server side, the conversion

manager is mapped as the protocol responder, which decodes the request data from the

client. The text stream is mapped the message concept of the base view. The native code

sets at the client and server side are extracted from the user or system properties during

the ORB initialization, and then are saved in the client and server conversion manager

respectively. The code set converters, saved in the conversion manager, are attached to

the base view messages, and they are used when reading or writing text data on the

messages by overwriting the corresponding message operations with around advices.

The MJMS mapping is similar to the MORB mapping, but the conversion manager

at the JMS client is mapped to the stub of the ConnectionFactory, not any object stub.

The ConnectionFactory is created for each client-server connection in JMS design, and

other facilities for that connection will be created based on the ConnectionFactory, so

the ConnectionFactory can be easily used to manage the whole conversion process on

that connection.

Page 47: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 38

4.6.4 Service Context

Description: In some instances, the communication between middleware services re-

quires specific context information passed implicitly. For example, as described in sec-

tion 4.6.3, to negotiate the transmission code set in code set view, the service context

mechanism is used to inform the server about the transmission code set in use. The OMG

CORBA specification defines a service context passing mechanism for this purpose. By

generalizing this specification, we create this service context aspect view. Each service

context is associated with a type and a sequence of bytes encoded according to the type.

The service context types and their encoding are not defined by this mechanism, they

are left out for the user to define during the adaptation process. Aspect view adaptation

is discussed in section 4.4.2.

Type: Domain-dependent. The service context view uses the Buffer, Messages and

Request Sessions abstractions from the Modelware base view.

Roles and role relationships: the basic roles of service context view are request

starter, request receiver and request messages. The request starter defines the abstract

pointcut for attaching the registered service contexts to the outgoing request messages.

The request receiver defines the abstract pointcut for extracting service contexts from the

incoming request messages.

Role contracts: In addition to the abstract pointcuts for attaching and extract-

ing service contexts, the request starter and request receiver are also associated with the

abstract operations for obtaining incoming and outgoing request messages. The request

messages defines the abstract operations for attaching and extracting service contexts.

Mapping: In both MORB and MJMS, the request starter role is mapped to the

Page 48: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 39

request session, and the request receiver role is mapped to the protocol responder. The

request session encapsulates the interaction for a request, so the pointcuts for attaching

service contexts can be easily concretized. The protocol responder decodes the request

data, so as a request receiver, the pointcuts for extracting service contexts can be easily

specified. The request message role is mapped to the message concept of the base view.

4.6.5 Portable Interceptor

Description: middleware systems are deployed in large distributed environments, and

must adapt to variety of computing platforms. The design of middleware becomes very

complex, but still cannot cover all the unexpected usage scenarios. Therefore, there is

a need to provide an plugin mechanism for the middleware user, such that the user can

intercept the middleware processing and provide new functionalities. Under this moti-

vation, the OMG CORBA specification defines a portable interceptor mechanism. This

mechanism defines the interceptor interfaces for the middleware user to plugin new func-

tionalities and the interfaces for registering the interceptors with the middleware systems.

Based on this specification, we create this aspect view. The portable interceptor view

assumes a client/server architecture, and all the user created intercetpors are executed

on the request/reply sequences. Figure 4.13 show the interception points where the in-

terceptors are executed. The prime task of the portable interceptor view is to ensure the

interceptors are correctly executed at the interception points according to the execution

rules.

There are two categories of interceptors: the client side interceptor and the server side

interceptor. In Figure 4.13, the client side interceptors are executed at the interception

points, Send request, Receive reply and Receive exception; the server side interceptors

are executed at the interception points, Receive service contexts, Receive request, Send

reply and Send exception. For both the client side and the server side, the reply inter-

Page 49: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 40

Figure 4.13: The interception points on both client and server side

ception point is normally invoked; the exception interception point is invoked only when

exceptions happen; for each pair of reply and exception points, only one of them will be

invoked. The execution flow at each intercepion points follows a well-defined flow rule.

To visualize the rules, consider a virtual stack on both the client and the server. For

example, at the client side, for each request/reply sequence, all the interceptors executed

at Send request interception points are pushed into the client stack, and they will be

executed at the Receive reply interception points. However, if an exception happens at

the Send request interception point, all the interceptors that are not executed will not

be pushed on the stack, and the rest of interceptors on the stack will be invoked at the

Receive exception point. The execution rules at the server side are similar to the rules at

the client side. Note that the portable interceptor view depends on the service context

view at the Receive service contexts point.

Type: Domain-dependent. The portable interceptor view uses the Messages, Request

sessions and Service sessions abstractions from the base view.

Roles and role relationships: The basic roles in the portable interceptor view are

PIController, Upcall and Downcall. The Downcall role represents the different stages for

a request/reply sequence at the client. The Upcall role represents the different stages for

Page 50: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 41

a request/reply sequence at the server. Downcall and Upcall encapsulate all the informa-

tion for the interceptors to interact with the middleware system. The PIController role

at both the client and the server manages the virtual stacks and enforces the flow rules.

Role contracts: The Upcall and Downcall roles provide the abstract operations for

querying and modifying the request/reply. The PIController role provides the abstract

operations for registering interceptors, and are associated with a set of pointcuts for

specifying where the interception points are located and where to register interceptors.

The virtual stacks are internal to PIController, so they are not accessible to the user.

Mapping: In both MORB and MJMS, the request session is mapped to the Downcall

role, and the service session is mapped to the Upcall role. In MORB, the implementation

of the Object Request Broker (ORB) is mapped to the PIController for both the client

and server side, because both the client and server in CORBA own an ORB, and com-

municate between each other through the ORBs’. In MJMS, at the JMS client, since the

initiator factory is a singleton object, it is mapped to the PIController role to manage the

interceptor execution; at the JMS message server, the server implementation is mapped

to the PIController role. The interceptor execution follows a set of flow rules, and these

rules are applied to each request/reply sequence. In a multithreaded environment, the

order of the interception points can be easily altered to violate the interceptor execu-

tion rules. The library attaches a state machine to the Downcall and Upcall to check

the execution sequence at each interception point. After mapping, the state machine is

attached to each request session and service session instance automatically. The state

machine is internal to the aspect view. The initialization of the state machine happens

when the sessions are created for both MORB and MJMS. Since the Upcall and Downcall

are associated with a stack, after mapping, the stack is available to the request session

and service session, and is used at each interception point to manage the interceptor

Page 51: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 42

execution.

4.6.6 Collocation

Description: In today’s IT environments, the system must be designed to handle load

balancing and distribute processing to different machines; the system must provide re-

dundancy to facilitate the system maintenance and failure recovery. All these facilities

require that the computing services are built in a way that they can dynamically adapt to

different environments, and require less human intervention. Typically, the distributed

applications are built in a client-server architecture. Normally, the client assumes that

the server is located on a different machine, so to contact the server, the client need to

use the network communication facilities, such as socket. However, in a dynamic environ-

ment, it is possible that the server moves to the same process as the client. In this case,

the heavyweight communication connection is not needed, and local method invocations

are enough. The Collocation view provide support for this optimization.

This aspect view provides the support for the service identification to decide if the

service that the client tries to invoke is in the same process as the client. If they are in the

same process, an protocol initiator (see Section 4.2.1) proxy will be used to communicate

the server protocol responder (see Section 4.2.1) proxy, intead of real the real initiator

and responder. The client/server communication becomes local method invocation.

Type: Domain-dependent. The Collocation view uses the protocol initiator and re-

sponder, the request session and service session and the message concepts from the base

view.

Roles and role relationships: The basic roles in the collocation view are collocator

and initiator owner. Through the initiator owner, the middleware system can access

Page 52: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 43

the real initiator or its proxy. The initiator proxy has the knowledge of the responder

proxy, so the base middleware system does not need to access the responder proxy. The

collocator role provides this aspect library with the service location information, such as

host and port, so that the library can make the decision about the usage of proxies.

Role contracts: The collocator provides abstract operations to allow the library to

access the service location information. The initiator owner allows the library to set the

initiator proxy. Both roles are associated with a set of pointcuts to allow the library to

collect the service location information and attach the initiator proxy.

Mapping: In MORB, the collocator role is mapped to the implementation class of

the ORB, because the ORB class is a singleton object, and coordinates the entire re-

mote invocation process. The initiator owner role is mapped to the remote object stub,

because these stubs create the initiators. The remote service location information is

extracted from the remote object reference by using an advice. The local service loca-

tion information is available to the ORB when the service starts, and is stored in the

collocator. Before the object stub creates an initiator, the decision will be made by this

library about the use of the initiator proxy based on the remote and local service location

information stored in the collocator.

In MJMS, the collocator role is mapped to the mapping aspect class itself. Since there

is no such an entity that coordinates the entire JMS client, the singleton aspect class is

used instead. The initiator owner role is mapped to the base view entity, object stub,

as in the CORBA mapping. The remote service location information is stored in the

collocator by using an after advice when the ConnectionFactory object is created. If the

JMS server is located within the same process as the JMS client, then when the server

starts, its location information is saved in the mapping aspect object. The use of the

Page 53: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 44

initiator proxy is also decided before the object stub creates the initiator.

4.6.7 Thread Specific Storage

Description: Thread Specific Storage provides data storage associated with individual

threads and ensures that the operations that requires global data access thread-safe. This

aspect view allows the middleware services to access the information associated with the

threads in which they are running. For each thread, this view maintains an internal stack

of context states, because after certain middleware processing, it may want to restore to

the starting point. Therefore, a stack keeps track of the previous state, and correctly

restores it. This view also ensures that the thread specific states are destroyed once the

thread itself is terminated.

Type: Domain-independent. This view does not make any assumption about the

base view concepts.

Roles and role relationships: There is only one role in this view. It is the state

user. Through the state user role, the middleware system can access, modify, overwrite

and delete the thread state of the current running thread. The thread state is the thread

specific data storage, and should be detailed during the aspect view adaptation.

Role contracts: The state user role is associated with a set of abstract pointcuts

that specifies the locations where the state user will pop, push or peak the state on the

stack.

Mapping: In both MJMS and MORB, this aspect view is used to implement the

thread specific storage for the portable interceptor. The state user role is mapped to

a Current object, which is used by the portable interceptor to get access to the thread

Page 54: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 45

specific storage. Since the thread specific data for the portable interceptor is a slot table,

the mechanism for initializing the table and deciding the table size must be implemented

in the mapping. Please refer to Section 4.6.8 for the usage of the thread specific storage

in the portable interceptor.

4.6.8 Portable Interceptor Thread Specific Storage

Description: This aspect view depends on both the thread specific storage view and the

portable interceptor view. A portable interceptor is created by the middleware user, and

is executed during the middleware request/reply processing. Sometimes, the portable

interceptor may access the current running thread context at interception points. This

kind of information cannot be determined when the interceptor is created. To provide

such support, OMG CORBA specification defines a thread context access mechanism for

the portable interceptor, known as PICurrent. This mechanism assumes an underlying

client/server architecture. At the client side, the thread context is logically copied to the

request context for the interceptors; at the server side, the request context is logically

copied to the thread context. This aspect view is developed based on the OMG PICurrent

specification.

Figure 4.14 shows the context transfer flow of the overall mechanism under a typical

request/reply sequence. In Figure 4.14, the dotted line represents the control flow, and

the dotted line between the thread context and the request context means a logical copy.

The solid line represents an access to the thread or request context. The single-arrow

solid line represents readonly access; the double arrow represents read/write access. The

sequence is executed as the following:

1. The request starts and proceed to the middleware system.

2. The thread context of the current thread is logically copied to the request context.

Page 55: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 46

Sendinterception point

ReceiverequestServicecontextpoint

ReceiveRequestpoint

Receiveintercepton point

Sendinterception point

Requestcontext

Threadcontext

Client Thread Server Thread

Threadcontext

Requestcontext

Network

ServiceContext

ServiceContext

1

10 9 8

3

7

6

5

4

2

Figure 4.14: Thread context and request context management

3. At the send interception point, the interceptor has the readonly access to the request

context. At this point, the interceptor may add the information in the request

context to the request service context, but this is optional.

4. At this interception point, the server side interceptor has the read/write access to

the request context. The interceptor may extract the client-side context information

from the request service context, but this is optional.

5. The request context is logically copied to the thread context at the server side.

6. The control is transferred the server thread. The server thread may access its

thread context.

7. The reply starts.

Page 56: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 47

8. At this point, the interceptor may add the server thread/request context informa-

tion to the reply service context, but this is optional.

9. The client receives the reply, and may extract context information.

10. the control is transferred to the client thread.

The rationale behind this mechanism is that the interceptor runs in a thread, which

may or may not be the same thread as the client thread, and the modification to the

interceptor’s thread context should not affect the request context. For instance, with-

out the copy operation, if the interceptor is in the same thread as the client, then the

modification to the interceptor’s thread context will affect the request context. This

is not a desirable effect. The same reason is for the server side copy operation. The

thread/request context is a slot table. Each slot in the table has an ID for access, the

slot contains the thread specific data.

Type: Domain-dependent. This aspect view uses the Messages, Request sessions and

Service sessions abstractions from the base view. It also uses the abstractions from the

Portable Interceptor view and the Thread Specific Storage view.

Roles and role relationships: This aspect view does not have its own roles, be-

cause its operations are established on the Upcall and Downcall roles defined in the

Portable Interceptor view. This aspect view also make use of the abstractions, such as

RequestInfo and State from the Portable Interceptor and the Thread Specific Storage view.

Role contracts: There are two abstract pointcuts in this aspect view. They specifies

where the thread context should be logically copied to the request context at the client

side, and where the request context should be logically copied to the thread context at

the server side.

Page 57: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 48

Mapping: The mappings of this aspect view for MJMS and MORB are similar to

each other. At the client side, once the RequestSession (the Downcall of the portable

interceptor view) is initialized with the RequestInfo (the request context), the slot table

will be copied from the thread context to the request context. At the server side, once

the service context is decoded from the underlying request, and the RequestInfo (the

request context) is filled with the request data, the slot table in the RequestInfo will be

copied to the thread context. Due to the completely different usage scenarios, only the

mappings for initialization are different between MORB and MJMS. In MORB, at both

the client and server side, the initialization happens when the ORB is created with user or

system defined properties. In MJMS, at the client side, the initialization happens when

the ConnectionFactory is created; at the server side, the initialization happens when the

JMS server is initialized with the user provided property file.

4.6.9 Callback

Description: This aspect view generally encapsulates the generic mechanism for event

handler registration and event dispatching. Each event handler has an unique handler ID.

When an event is generated by the underlying system, it will be correctly dispatched to

its registered event handler by using the handler ID. This simple mechanism can be used

to implement the asynchronous messaging for middleware systems. The asynchronous

messaging allows a message handler to be registered with the middleware system. When

a request is sent out, the user application on the middleware does not need to stop to

wait for the reply coming back. Once the reply message is ready, the middleware system

will use the registered handler to notify the user application.

Type: Domain-dependent. The design of the callback view does not assume any

abstractions from the base view.

Page 58: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 49

Roles and role relationships: There are two basic roles for this aspect view. They

are the event trigger and the handler registrar role. The handler registrar registers an

event handler in the library internal table. The event trigger fires an event, and inter-

nally dispatches an event handler to handle the event. An event can be a receipt of an

asynchronous message or a return of asynchronous remote call.

Role contracts: The event trigger is associated with a pointcut specifying where an

event is triggered. The pointcut of the handler registrar specifies the location where the

event handler is registered with the library. The event, event handler and handler ID are

the generic data used by this aspect view. They can be mapped to the base view entities,

or they can be directly implemented during the mapping.

Mapping: In MORB, this aspect view is used to implement the CORBA asyn-

chronous messaging. The sematic of this type messaging is that when a remote invoca-

tion is sent to the server, the client ORB will return to the application layer right away

without waiting for the reply. When the reply arrives, the ORB will invoke the pre-

registered ReplyHandler, which is user defined. The event trigger role is mapped to the

protocol initiator. When the initiator receives a asynchronous reply from the server, it

will fire the callback. The handler registrar role is mapped to the remote object stub. The

event handler and event handler ID are directly implemented during the mapping. Since

the asynchronous messaging callback is triggered by a reply from the remote server, the

event is mapped to the Response class, which is a reply of the CORBA remote request.

When the asynchronous messaging is used, the generated client-side stubs will include

the extra method calls to the ORB to register the ReplyHandler. These new operations

are introduced to the ORB by using Aspectj ”inter-type declaration” capability. At the

same time, certain advices are used during the mapping to change the ORB behaviour

Page 59: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 50

from ”synchronous” to ”asynchronous” by preventing the ORB to wait for the reply.

In MJMS, this aspect view is used to implement the asynchronous message receiving

at the JMS client, so the JMS server can send messages to the client when the mes-

sages are available without constant client polling. The event, event handler and handler

ID are implemented, as MessageEvent, MessageEventHandler and MessageEventHand-

lerID respectively. The MessageEvent carries the actual data of the message, and the

MessageEventHandler has the access to the user-defined MessageListener, so that the

MessageEventHandler can transfer the message to the MessageListener. The event trig-

ger role is mapped to the protocol initiator, which is responsible for receiving from the

JMS server. Once a message is received from the server, the initiator will create a Mes-

sageEvent object to fire the event. The handler registrar role is mapped to the Session

class, because all the messages are sent or received through a session on the JMS client.

The server side adaption includes the mechanism for constantly checking the availability

of the messages, so that the JMS server can notify the client.

4.6.10 Reactor

Description: Since JDK 1.4, the standard Java library includes the new Input/Output

(NIO) implementation. First, this new library provides a block-oriented I/O system in

which the data is dealt in blocks. Compare to the traditional stream-oriented I/O sys-

tem that deals data one byte at a time. Secondly, the NIO supports the asynchronous

I/O for networking. When there are many connections to a server, the server need a

large number of threads to handle them. The large number of threads will create great

overhead and waste computing cycles for switching between different threads. With the

asynchronous I/O, the server will be notified when an I/O event happens, so that the

server can support the arbitrary number of connections without occurring overhead. This

aspect view well modulizes the NIO support for the middleware system, so that the NIO

Page 60: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 51

library can be easily applied.

Type: Domain-dependent. It utilizes the base view concepts, such as Acceptor and

Connector.

Roles and role relationships: The core entities of the reactor aspect view con-

sist of a reactor and four roles: AsyncAccpetor, AsyncConnector, AsyncTransport, and

AsyncWorker. The primary function of this aspect view is to disable the blocking opera-

tions in conventional Java network I/O, initialize and install ”channels” onto appropriate

roles, and register these roles with the Reactor. The Reactor dispatches incoming data

to corresponding AsyncWorkers based on their registration keys.

Role contracts: The AsyncWorker role is associated with the operations for ob-

taining registration keys. There are four abstract pointcuts, which specify the points to

cancel the network binding and receiving of the conventional I/O calls, and the points

to register selection keys to the reactor and to start the reactor.

Mapping: The mappings of this aspect view for MJMS and MORB are similar to

each other, because it only affects the transport layer, which is implemented similarly

for MJMS and MORB. Please refer to Section 6.1.2 for the detailed description of the

mapping.

4.7 Aspect view implementation guideline

Section 4.6 presents a few reference implementations of aspect libraries (aspect views),

which show how the aspect libraries are implemented and applied in middleware systems.

However, the implementation of the aspect libraries is quite different from the traditional

Page 61: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 52

object-oriented design. In this section, we show the experiences and guidelines that we

develop during the implementation of the aspect libraries in Section 4.6.

4.7.1 Design from scratch

When designing an aspect library from scratch, we need to consider several design issues.

First, the library should provide good reusability, which is a necessary requirement for

any software library design. Second, the library should provide useful functionality, which

is why the software developer uses the library. Third, the library should have a modular

internal structure, so that the library itself can be easily understood and maintained.

Lastly, the aspect library must deal with a mapping issue, which does not exist in the

traditional object-oriented library. The aspect library should be easily mapped to the

core system implementation (base view), as simple as calling a library method in the

object-oriented library. By keeping these requirements in mind, we develop the following

design and implementation guidelines:

1. Decide the right abstraction level. When the aspect library is designed in a highly

abstract way, the library implementation will make very little assumption about its

base view implementation and usage context. This will result in high reusability.

However, the highly abstract design captures less functionality, and the library be-

comes less useful. The more specialized design includes more functionality in the

library, but makes the library hard to apply to different application contexts. In

general, the library design should balance the reusability and functionality accord-

ing to the real usage scenarios.

2. Use aspects as glue. Although the aspect library is based on the aspect-oriented

approach, not all the implementation logic is necessarily contained in aspect classes.

In fact, most of the library implementation should be designed in traditional de-

composition models, and the aspect classes are used to glue the library internal

Page 62: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 53

class hierarchy to the base view hierarchy. The roles with their abstract pointcuts

and operations, as discussed in Section 4.4.2, are used by the aspect classes, as

a vehicle to exchange data with the base view. The advantage of this structure

is that the design is simplified and the object-oriented design experience can be

transferred to the aspect library design.

Base View

AbstractAspectClass

ConcreteMappingAspectClass

Base View

weave

AbstractAspectClass

ConcreteMappingAspectClass

AdaptationAspectClass

weaveweave

Aspect Library

Figure 4.15: Adaptation aspects connect aspect libraries with base view

3. Use adaptation aspects. No matter how we carefully design library abstract point-

cuts, there are always cases that we cannot identify appropriate source locations to

map the pointcuts. This difficulty is caused by the mismatch between the library

assumption and the base view implementation. To solve this problem, the library

pointcuts can be first mapped to the join points in the adaptation aspect class

instead of the base view classes. Then, the pointcuts of the adaptation class are

mapped to the base view, as shown in Figure 4.15. The advantage of this arrange-

ment is that the adaptation aspect is created during the aspect library mapping,

so it knows exactly where advices should be applied and what types of advices (be-

Page 63: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 54

fore, after and around) should be used. The adaptation aspect provides one level of

indirection during the mapping to bridge the mismatch between the aspect library

assumption and the actual base view implementation.

4. Turn advices to addressable units. As the number of aspect views increases, the

interaction between aspect views increases as well. An aspect view can crosscut not

only the normal class modules of the other aspect view, but also the aspect classes.

However, one important limitation of most aspect-oriented programming languages

is that the advice construct is not addressable, i.e., the advices are not named. The

consequence is that it is difficult to write pointcuts to crosscut these advices. To

solve this dilemma, we can turn the programming logic of an advice to a private

method, and invoke the method in the body of the advice. Since methods can be

addressed by pointcuts, the advices also become addressable. This style should be

uniformly applied to all aspect modules.

5. Encapsulate the join point sequence states in roles. As the aspect view becomes

more complex, the aspect class is going to be associated with certain internal state

information. The join point sequence states are a set of such internal states. Nor-

mally, the developer can decide the execution order while mapping aspect views to

the base view. However, in multi-threaded environments, it is hard to predict the

control flow, so it is hard to know the join point sequence. To detect the invalid

join point execution sequence, we can implement a state machine, and at each join

point, this state machine can be invoked to check the execution. If the sequence is

invalid, a runtime error should be thrown. We could encapsulate the state machine

in the aspect class, but usually in this case, the aspect object cannot be initiated

as a singleton object, and the complexity of aspect implementation increases. An-

other alternative is that we could attach the state machine to a role in the base

view, then the aspect object can be kept as a singleton object. For example, in

Page 64: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 55

the interceptor view, the interceptors are invoked by the library at different inter-

ception points, and the interceptors must be executed in a pre-defined order. To

satisfy this ordering requirement, the down call and up call roles of the intercep-

tor view are associated with a state machine to validate the execution sequence at

each join point. Since the interceptors are typically executed in a multi-threaded

environment, this design guarantees the correct execution.

6. Use roles to collect and store information for aspect views. Very often, the pro-

gram context that is exposed in one join point cannot support certain aspect logic

execution. Therefore, we need to store the data in a temporary location. When all

the data is ready, then execute the aspect logic. In multi-threaded environments,

the aspect class is not a safe place to store such information. We can choose a

base view entity to store such information. That entity should be available at all

the associated join points, so that the corresponding advice can store information

there, and retrieve it later. This approach collects the limited context at each join

point together to support complex advice logic. For example, the collocator role of

the collocation view is created for this purpose. The information about the hosts

and ports of the remote and local services is rarely available at one join point, so

the collocator is the entity to temporarily store such service location information,

which can be used to decide the usage of the initiator proxy.

4.7.2 Implement from refactoring

We do not always directly implement the aspect libraries from scratch. Many legacy

systems contain the good design, but many useful features are crosscutting in nature.

When they are applied to different systems, they are usually re-implemented. These

kinds of system features are very good candidates for aspect libraries. To refactor these

features as aspect libraries, several issues must be considered. First, we must understand

Page 65: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 4. Modelware Concept 56

what functionality and services this library is going to provide. Then, we should identify

the major implementation classes of the functionality from the current code base. These

classes are refactoring candidates, and will become the internal implementation of the

library. We need to make sure that the aspect functionality can be separated from the

main execution flow, and the rest of the system implementation can still perform mean-

ingful tasks. Otherwise, the functionality should not be included in the aspect library.

Secondly, we need to identify the interaction and data exchange between the aspect li-

brary and the base view implementation. This information can help us to create the

role models and build aspect interfaces with the rest of the system. Thirdly, we need

to reduce the coupling between the library and the base view system. Since the library

implementation is refactored from an existing system, it must make very strong assump-

tions about the existing system. For example, very often, the library implementation will

use the class types from the base view. This strong assumption will reduce the reusability

of the library. Generally, the assumptions about the existing systems should be turned

to roles of the aspect view, so that these assumptions can realized in the new system by

mapping.

Page 66: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5

Modelware Customization

Framework (MCF)

Modelware is a methodology to manage the complexity of large software systems, such as

middleware. The Modelware methodology provides an excellent opportunity for software

customization and configuration. In Modelware terms, a software system consists of a

base view and a set of aspect views. As shown in Section 4.4, the aspect views are

integrated with the base view by the ”projection” operations, which are implemented in

the adaptation module of each aspect view. Since this ”projection” process employs the

class directional approach [18], the base view knows nothing about the aspect view and

its adaptation module. Therefore, by weaving different sets of aspect views into the base

view, the same software system can be customized with different flavours. We use the

term ”feature” to represent the flavour provided by an aspect view to the base view. A

feature consists of the code implemented in conventional programming languages, such

as Java, and the code using AOP constructs, such as pointcut, advice and inter-type

declarations in Aspectj terms. Depending on different AOP technologies, the weaving

process can take place at compile time, load time and runtime. In this work, the reference

modelware implementation is developed in early verions of Aspectj, which only supports

57

Page 67: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 58

the compile time weaving, so the discussion in this section is in the context of compile

time weaving. We have implemented this framework in Java to faciliate the Modelware

customization. In the following discussion, we will use the term ”feature” to refer to an

aspect view mapped to the base view.

5.1 MCF Overview

ExplicitAcquisition

FunctionalInference

Verification

FunctionalDependency

Rules

CompositionConstraintsOther

indicationUser

preferences

Synthesis

ConvolutionDescriptions

Figure 5.1: Modelware Customization Framework stages

The Modelware customization framework consists of four high-level stages as shown

in Figure 5.1. The whole customization process starts with the explicit acquisition of

middleware functionalities by either user preferences or other application requirements.

The initial manifest gathered in this stage is a set of features, then this information is

passed into the Functional Inference stage. In this second stage, the initial manifest

is checked by an inference algorithm against the dependency rules of all the features.

Due to the dependency among the features, the Functional Inference stage could add

features that are required by the selected features, suggest adjustments and re-initiate

the Explicit Accquisition stage. If all the dependency rules are satisfied, the process

Page 68: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 59

goes to the Verification stage with the inferred manifest. The inferred manifest is then

validated according to external constraints, such as computing environment and resource

availability, in the Verification stage. Then, the final manifest is produced and passed to

the Synthesis stage where the tailored middleware is synthesized according to convolution

descriptions and a well-defined coding naming schema. The convolution descriptions

define the cross-cutting relationship among all the features. The coding naming schema

facilitates the code selection and compilation process.

5.2 Dependencies, convolution descriptions and con-

straints

5.2.1 Definitions

In Modelware customization framework, three types of specifications are defined in addi-

tion to the middleware implementation: feature dependencies, convolution descriptions

and composition constraints. An important concept proposed in Modelware customiza-

tion framework is the separation between feature dependency and feature convolution.

The feature dependency is established on high level design concepts, and reflects the

nature of the relationship among different features. By definition, if Feature A depends

on Feature B, then the functionalities of A require the existence of B. The dependency

relationship is not commutative, i.e., Feature A depends on Feature B, but B does not

necessarily depend on A. The feature convolution concept is established on the imple-

mentation level, and it does not directly correspond to the dependency relationship. By

definition, if Feature A convolutes Feature B, then at least one of the following properties

must be met:

1. Feature A introduces additional states to the modules of Feature B.

2. Feature A introdces additional behaviour, i.e. method or procedure, to the modules

Page 69: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 60

of Feature B.

3. Feature A uses the types, defined in Feature B.

4. Feature A uses the states or behaviour that are introduced by Feature B.

This is similar to the knows-about relationship defined in [18]. That is, if Feature A

convolutes Feature B, then A knows about B. However, the convolution relationship is

not commutative, either, i.e., Feature A convolutes Feature B, but B does not necessarily

convolute A. The connection between dependency and convolution is that if Feature A

depends on Feature B, then A must convolute B. However, the convolution does not nec-

essarily lead to the feature dependency. The rationale behind this relationship between

dependency and convolution is that if Feature A depends on Feature B, then there must

be some association between A and B, which leads to the feature convolution; however,

if Feature A convolutes Feature B, it could be just that A adds certain flavour to B.

For example, in our reference Modelware CORBA implementation, we have a feature for

ORB request char code set conversion and a feature for wide char data type support. The

wide char feature enables the code set feature to do wide char conversion, but without

the code set featrue, the wide char support can still provide useful functionalities. There-

fore, the wide char feature convolutes the code set feature, but does not depend on the

code set feature. Since the dependency always leads to the convolution, the convolution

relationship is not specified when the dependency is present. Convolutional descriptions

are used at the synthesis stage to guarantee that the right interaction code is selected.

This mechanism is explained in detail in Section 5.5.1.

The composition constraints are also dependencies that dictate the inclusions and

exclusions of functionalities reflecting certain external conditions. Different from feature

dependencies which are propositional, constraints are predicates on conditions indepen-

Page 70: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 61

dent of middleware itself. For example, targeting a cellphone application on J2ME 1

platforms requires the omission of certain functionalities due to the lack of support in

J2ME virtual machines. This omission can be specified as a constraint to validate a

manifest generated for cellphone applications.

5.2.2 Feature dependency specification

1 feature1 = feature2 * (feature3 + feature4);2 feature4 = feature5 * !feature6;3 feature3 = feature6;

1 aspect feature1, feature2, … ;2 modulename {3 feature1 = feature2 * (feature3 +feature4);4 …..;5 };

<?xml version="1.0"?><!ELEMENT dependency (definiti<!ELEMENT definition (feature+<!ELEMENT rule (LHS, RHS)><!ELEMENT feature (#CDATA)> <!ATTLIST feature negati<!ELEMENT LHS (feature)><!ELEMENT RHS (product+)><!ELEMENT product (feature+)>

<?xml version="1.0"?><dependency> <definition> <feature> feature1 </feature> <feature> feature2 </feature> <feature> feature3 </feature> <feature> feature4 </feature> <feature> feature5 </feature> <feature> feature6 </feature> </definition>

<rule> <LHS> <feature> feature1 </feature> </LHS> <RHS> <product> <feature> feature2 </feature> <feature> feature3 </feature> </product> <product> <feature> feature2 </feature> <feature> feature4 </feature> </product> </RHS> </rule> <rule> <LHS> <feature> feature4 </feature> </LHS> <RHS> <product> <feature> feature5 </feature> <feature negation=”yes”> feature6 </feature> </product> </RHS> </rule> ...</dependency>

Figure 5.2: Dependency rules specified in logic notation

The specification of feature dependency consist of rules. Mathematically, We use

boolean expression to represent the relationship between a feature and its dependent

features. Figure 5.2 illustrates a few sample rules expressed in boolean notations. ”*”

stands for logical AND, and ”+” stands for logical OR. The negation operation is

represented by ”!”. The logic equation on the right hand side of a rule specifies the

dependency relationship for the feature on the left hand side. In Figure 5.2, feature1

depends on feature2 and feature3 or feature4 (Line 1); feature4 depends on feature5, and

if feature4 is included in the manifest, feature6 must be excluded from the manifest (Line

2). To facilitate the framework processing, We also develop a XML format for the feature

dependency specification. Figure 5.3 shows the Document Type Definition (DTD) for

the feature dependency XML document. To simplify the inference algorithm described in

section 5.3.2 and XML processing, the logic equation must be specified in sum-of-products

form. A product is a term in which variables or their negation forms are ANDed together.

The sum-of-products form means that a logic expression consists of product (AND)

1Java Micro Edition. URL: http://java.sun.com/j2me

Page 71: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 62

terms that are summed (ORed) together [7]. For example, the dependency specified in

Figure 5.2 can be specified in an XML document as shown in Figure 5.4. Note that if the

negation attribute of a feature element is not specified, the default value of that attribute

is no. That is, the feature is not in negation form.

1 feature1 = feature2 * (feature3 + feature4);2 feature4 = feature5 * !feature6;3 feature3 = feature6;

1 aspect feature1, feature2, … ;2 modulename {3 feature1 = feature2 * (feature3 + feature4);4 …..;5 };

<?xml version="1.0"?><!ELEMENT dependency (definition, rule+)><!ELEMENT definition (feature+)><!ELEMENT rule (LHS, RHS)><!ELEMENT feature (#CDATA)>

<!ATTLIST feature negation CDATA "no"><!ELEMENT LHS (feature)><!ELEMENT RHS (product+)><!ELEMENT product (feature+)>

Figure 5.3: Feature Dependency Specification DTD

5.3 Functionality acquisition

The goal of functional acquisition is to obtain a tailored set of middleware functionalities

as desired by the user application with minimum cost. The detail of cost specification is

discussed in section 5.4. The process is divided into two stages: direct collection of func-

tionalities (explicit acquisition) and the adjustment according to functional dependencies

(inference).

5.3.1 Explicit acquisition

There are two basic forms of explicit acquisition: automatic feature extraction and user

preference indication. Automatic feature extraction is to examine the user program

source that will run on the middleware system and to detect middleware functionalities

that user applications intend to use. This intent can be discovered most explicitly in

Page 72: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 63

1 feature1 = feature2 * (feature3 +feature4);2 feature4 = feature5 * !feature6;3 feature3 = feature6;

1 aspect feature1, feature2, … ;2 modulename {3 feature1 = feature2 * (feature3 +feature4);4 …..;5 };

<?xml version="1.0"?><!ELEMENT dependency <!ELEMENT definition <!ELEMENT rule (LHS, R<!ELEMENT feature (#CD <!ATTLIST featur<!ELEMENT LHS (feature<!ELEMENT RHS (product<!ELEMENT product (fea

<?xml version="1.0"?><dependency> <definition> <feature> feature1 </feature> <feature> feature2 </feature> <feature> feature3 </feature> <feature> feature4 </feature> <feature> feature5 </feature> <feature> feature6 </feature> </definition>

<rule> <LHS> <feature> feature1 </feature> </LHS> <RHS> <product> <feature> feature2 </feature> <feature> feature3 </feature> </product> <product> <feature> feature2 </feature> <feature> feature4 </feature> </product> </RHS> </rule> <rule> <LHS> <feature> feature4 </feature> </LHS> <RHS> <product> <feature> feature5 </feature> <feature negation=”yes”> feature6 </feature> </product> </RHS> </rule> ...</dependency>

Figure 5.4: XML document of feature dependency in Figure 5.2

service declaration descriptions expressed in well-defined languages such as the interface

definition language (IDL) in the CORBA and DCOM world, remote interfaces of the

Java RMI mechanism, as well as the web service description language (WSDL) of Web

Services. The language elements of IDL, for instance, embody a rich set of middleware

functionalities including data types, synchrony/asynchrony of message passing, invoca-

tions styles, and many others. Remote service descriptions can serve as the initial recipe

for determining the final ingredients of the synthesized middleware. In many cases, ser-

vice descriptions alone are not sufficient to determine all the necessary functionalities

because some are present, not as language elements, but as libraries or extension points

Page 73: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 64

for controlling the behaviour of middleware itself. One example is the interceptor infras-

tructure in CORBA implementations. The use of these types of functionalities can only

be detected by analyzing the application source code. Another type of explicit acquisi-

tion is to allow the user to select additional features in foreseeing their future uses. A

tool can be provided to facilitate both compiler-based and user-driven acquisition.

5.3.2 Rule-based inference

The functionality manifest established through the explicit acquisition typically will not

be the final manifest used in synthesis. An inference process is needed to reason about

functional dependency rules and to possibly include additional functionalities. This pro-

cess must provide two guarantees regarding the inferred manifest:

1. Each feature in the manifest must have its feature dependency satisfied.

2. The inferred manifest must be a minimum cost superset of the explicit manifest.

The second garantee is critical to the Modelware Customization Framework and also

difficult to implement because the term ”minimum cost” can be interpreted differently in

different contexts. An appropriate cost model can be employed by inferrence algorithms

to rank all possible supersets. The cost functions in the model can reflect the weights

of many properties regarding a particular functionality such as its physical size, memory

requirements, energy consumptions, level of preference, and others. The definition of the

cost function can either be user-defined or provided by the middleware vendor. We will

describe such an algorithm and the associated cost function (Section 5.4).

Given the initial feature manifest, the algorithm in the inference process is responsi-

ble for selecting unspecified features in order to satisfy all functional dependency rules.

If multiple choices for selections exist, the algorithm guarantees to generate a minimum

cost superset of the initial manifest. Before we introduce the algorithm, we first define

Page 74: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 65

Algorithm 1 Simple Inference Algorithm

Require: intial manifest F, dependency rules R1: F ′ ← F2: loop3: for each r ∈ R do4: if r is activated by F ′ then5: result← evaluate(r, F ′)6: if result = true then7: GOTO next r8: else if result = false then9: RETURN error

10: else11: for each unknown feature f in r do12: set f to 1 or 0 so that r evaluates to 113: end for14: end if15: end if16: end for17: if F ′ = F then18: BREAK19: else20: F = F ′

21: end if22: end loop23: Set all unknown features in F to false24: RETURN F

Page 75: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 66

a few terms. Feature state : A feature can be in one of three states during the inference

process: selected (true), excluded (false), and unspecified (unknown). Rule activation:

A dependency rule r is activated if the feature on the left side of r is selected, i.e., its

value is ”1” in the manifest. If a feature is excluded from the manifest, its value is ”0”;

if a feature is in unknown state, its value is ”x”. Our algorithm only deals with rules

written in the form of sum-of-products. We first present a simple algorithm, Algorithm 1

requires all rules having only one product term evaluated to unknown. The algorithm

simply iterates each dependency rule r and invokes the evaluate function on r against

the inferred manifest. The function returns either true (rule satisfied) or false (rule

violated) or unknown. In the case of unknown, new features are added to the manifest

to satisfy r. The algorithm stops if no new features are added after iterating through

all rules in consecutive runs. The complete algorithm handles multiple disjunctive un-

known product terms in dependency rules by recursively invoking the simple algorithm

on each product term. At each recursive step, the cost function is used to determine the

minimum configuration and pass it to the upper recursive level. The evaluate function

in Algorithm 1 is based on the truth table defined in Figure 5.6. Note that the selection

of features from the explicit acquisition stage could conflict with each other according

to the predefined rules. In this case, the explicit acquisition process is restarted with

adjustment suggestions from the inference algorithm.

Figure 5.5 shows how the inference algorithm is executed on the rules in Figure 5.2.

The initial state of the feature set is State 0 as shown in Figure 5.5. The state of the

feature set is specified in the order of feature1 to feature6. This is an example that

the inference algorithm must deal with multiple disjunctive unknown product terms in

dependency rules. First, to satisfy Rule 1, there are two choices: set feature3 to ”1” or

set feature4 to ”1”. The algorithm will branch to the two choices, which result in State 1

and State 4. At State 1, to satisfy Rule 3, the algorithm sets feature6 to ”1”. Now, all the

Page 76: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 67

(1, 1, x, x, 1, x)

(1, 1, x, 1, 1, x)

(1, 1, x, 1, 1, 0)

(1, 1, 0, 1, 1, 0)

(1, 1, 1, x, 1, x)

(1, 1, 1, 0, 1, 1)

(1, 1, 1, x, 1, 1)

rule 1

rule 3

all rules satisfied all rules satisfied

rule 2

state 0

state 6state 3

state 5state 2

state 4state 1

Figure 5.5: Execution of the inference algorithm on the rules in Figure 5.2

activated rules are satisfied. The algorithm will set feature4 to ”0”, because feature4 is

not required to satisfy any activated rule at this point. The result is State 3. Similarily,

another branch from State 0 will result in State 6. To decide which branch to be the

final choice, the cost function is used.

(1, 1, x, x, 1, x)

(1, 1, x, 1, 1, x)

(1, 1, x, 1, 1, 0)

(1, 1, 0, 1, 1, 0)

(1, 1, 1, x, 1, x)

(1, 1, 1, 0, 1, 1)

(1, 1, 1, x, 1, 1)

rule 1

rule 3

all rules satisfied all rules satisfied

rule 2

X1 X2 X1 * X2 X1 + X2 ! X1 0 0 0 0 1 0 1 0 1 1 1 0 0 1 0 1 1 1 1 0 X 0 0 X X X 1 X 1 X 0 X 0 X 1 1 X X 1 0

Figure 5.6: The truth table used by the evaluate function in Algorithm 1

Page 77: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 68

5.3.3 Verification

During the verification stage, the inferred manifest is checked against composition con-

straints. Though logically separate from the functionality acquisition mechanism, verifi-

cation is frequently invoked in the inference stage to validate the inferred manifests. Vio-

lations of composition constraints can either be used to prune choices of feature supersets

or to reinitiate the acquisition process with the information about offending functional-

ities and violated constraints. This requires different indications of user preferences or

modifications of the application in the worst case.

5.4 Feature cost function

The feature dependency rules include an ”+” operator, which represents an OR opera-

tion. The consequence of this operator is that the inference process will have a tie for

feature selection. For example, in Figure 5.2, if feature1 is selected in the initial con-

figuration, then according to rule 1, there will be three choices: 1. select feature2 and

feature3; 2. select feature2 and feature4; 3. select feature2, feature3 and feature4. Any

of the three choices will satisfy rule 1. To break this tie, we associate each feature with

an cost function, so that the inference algorithm can choose the choice with minimum

cost as the final decision. The customization framework user decides what cost function

to use. A cost function could be based on the memory usage requirement, the effects to

processing speed or other user defined requirements. For instance, for rule 1 of Figure 5.2,

feature3 utilizes the system resource better on Platform A; feature4 utilizes the system

resource better on Platform B. Then, we can assign feature3 with lower cost on Platform

A, and assign feature4 with lower cost on Platform B.

Page 78: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 69

5.5 Target synthesis

During the target synthesis stage, the tailored software system is finally composed in

strict accordance with the final manifest generated at the inference stage. Due to the

convolution phenomena, it is often not correct to naively select the entire functionality

of a feature but only relevant parts according to a specific final manifest. This partial

selection could be different from one to another. To tackle this difficulty, we propose

to use a well-organized code space for features according to a structural schema, which

represents the convolution relationship between features.

5.5.1 Structural schema

The primary purpose of the structural schema is to make the code space of system fea-

tures comprehensive to the synthesizer. The traditional structure of the code space is

based on name spaces (or packages in Java terms) and, therefore, suited for the verti-

cal dimension. Horizontal features, usually modularized in aspect views, however, are

non-hierarchical and convolutional. Therefore, the structural schema for Modelware Cus-

tomization Framework must make the following properties explicit for each aspect view:

the differentiation between implementation and interaction, and the set of binary rela-

tionships with other features. The former is necessary because, if the feature is selected,

the implementation of features is included completely, but the interaction logic might

subject to partial selection. The explicit binary relationships in the schema allow the

synthesizer to select the correct parts according to what features are in the final manifest.

Instantiations of the schema elements, i.e., implementation, interaction, and binary rela-

tionship can be either source files or bytecode representations. Figure 5.7 illustrates the

general definition of the schema. In this hierarchical schema, the implementation and the

interaction of a feature, represented by feature, are separated into two sub-trees, func-

tional implementation and interaction. The specific interactions between any two features

Page 79: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 70

are organized using one feature’s identifier as the package name under the ”interaction”

subtree of the other feature’s root. For instance, if feature1’s identifier is a package name

under feature2’s interaction subtree, then feature2 convolutes with feature1.

<< regular name space >>

feature

funct. impl

interaction

base view

feature

<< more feature name >>

base view

<< more featurename >>

Figure 5.7: The structural schema of Modelware Customization Framework

5.5.2 Implmentation selection

Algorithm 2 Synthesis Procedure

Require: final manifest F1: Include the modules in base view2: for each included feature f in F do3: Include all modules in the path ” f => funct. impl ”4: Include all modules in the path ” f => base view ”5: for each f ′ convoluted by f do6: if f ′ included in F then7: Include all modules in the path ” f => interaction => f ′ ”8: end if9: end for

10: end for

With the help of our packaging schema, the final synthesis procedure proceeds as

described in Algorithm 2. The output of this procedure is a list of modules corresponding

to the final manifest. In our current implementation, a resource list is generated and

Page 80: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 5. Modelware Customization Framework (MCF) 71

handed over to the AspectJ weaver. More sophisticated building tools such as Ant 2

could also be exploited. A note-worthy characteristic of our feature synthesis procedure

is that it is easy to add a new aspect feature if its implementation conforms to the

code naming schema. The framework is able to reason about this new feature if its

dependencies and convolution are correctly specified.

2Ant. URL: http://ant.apache.org/

Page 81: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6

Evaluation

In Chapter 4, we present two case studies to show how effective the Modelware method-

ology and its reference implementation can be used in building common middleware op-

erations. For each case study, we compare the performance of our implementation with

a well-known open source implementation; We also quantify the programming effort of

the two case studies in two aspects: 1. supporting functionality evolution of middleware

in time; 2. supporting functional diversity in space, i.e., different computing platforms

from Java Card, to mobile devices, and to desktop environment.

6.1 Modelware CORBA (MORB)

6.1.1 Runtime characteristics

In this set of performance evaluations, we primarily want to demonstrate the benefit of

the architectural flexibility of Modelware in competing with ORBacus 1 on the same set

of benchmark measurements collected by Benchie [29]. The performance delta should not

be influenced much by algorithmic factors but mainly architectural ones since almost all

1An open source industrial strength CORBA Java implementation.http://www.orbacus.com/support/new site/index.jsp

72

Page 82: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 73

of the critical Modelware functions, such as data marshalling and unmarhalling, GIOP

protocol stack, and connection management, are just reused ORBacus implementations.

The benchmark tests are performed on Pentium 4 2GHZ PC running Linux Redhat 8.0.

We disable the concurrency protection of user applications for both MORB and ORBa-

cus 2.

Figure 6.1: Benchmark comparison of Modelware CORBA to ORBacus

We present three categories of benchmark tests: a. roundtrip pings representing the

minimum cost of CORBA stack traversals; b. data marshalling/unmarshalling opera-

tions representing the performance of client-encoding and server-decoding capabilities; c.

multi-server tests representing the dispatching capabilities of CORBA. We customize 3

2This is the default policy of ORBacus3A reminder that our customization only involves changing the selections of compiled classes for

bytecode weaving.

Page 83: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 74

MORB for these three categories as follows: since the concurrency support is not nec-

essary for tests in categories a and b, ”threading” and ”thread-safe locks” become re-

dundant and are configured out of the architecture. We denote this configuration as

”MORB A”. We enable the ”concurrency” support and disable all other features such as

”interceptor” and ”service context” for category c Benchie tests in the ”MORB B” con-

figuration. We show the results of benchmark tests for both MORB configurations and

ORBacus in Figure 6.1. Figure 6.1:A shows that, for 10,000 pings, MORB shows dramatic

performance improvements over ORBacus, as the shape of the histogram of ”MORB A”

shifts to the left of that of ORBacus. The average invocation time for MORB is 105

microseconds, a 43% speed-up comparing to 183 microseconds found with ORBacus. We

believe this is primarily due to the Modelware’s ability of lifting concurrency overheads

since, once we enable ”concurrency” and ”thread-safe” features in ”MORB B”, the aver-

age invocation time increases to 161 microseconds. In the marshalling and unmarshalling

performance comparisons (Figure 6.1 B and C), the improvement decreases from 40% to

12%, as the descending differential curves on both graphs show. This confirms the fact

that MORB reuses the encoding/decoding algorithms of ORBacus, and the performance

difference tends to diminish, as the data exchange work dominates the request processing.

Figure 6.1 D shows that, in the absence of facilities such as ”interceptors” and ”context”,

the dispatching can be more efficient in MORB compared to ORBacus, an architectural

flexibility enabled by Modelware to optimize for performance.

6.1.2 Support Middleware Evolution in Time

In many performance-sensitive application domains, high performance is often a manda-

tory requirement in addition to location transparency. This translates to low overhead

and fast response for request processing in the middleware layer. TAO [27] is a success-

ful example of high-performance implementations exploiting techniques such as zero-copy

buffer, reactive communication models, and the high speed network I/O. For a lot of con-

Page 84: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 75

ventional middleware implementations, many such techniques are not employed because

of the limitations of the underlying OS and VM at the time of the design. The evolution

of OSs or VMs might lift these design limitations in the infrastructure but not easily in

the middleware architecture. This is because leveraging new capabilities often requires

systematic, i.e., crosscutting, changes to many middleware architectural layers such as

the data representation and the network communication design. The new I/O intro-

duced in Java 1.4 platforms 4 is an example of VM evolution having profound impacts on

Java-based middleware architectures. Its zero-copy buffer and asynchronous I/O primi-

tives can be used to dramatically improve the performance of traditional stream-oriented

middleware message passing. In Modelware, this improvement is captured entirely in a

separate aspect library as discussed in Section 4.6 and can be transparently applied to

the base view at post-compilation time.

There are two different approaches of projecting this library to the base view, one

being mapping these four roles to the base view model entities. The ”reactor” function-

ality thus affects all concrete implementations of Acceptor, Connector, and Transport.

However, in foreseeing future non-socket based connection management in Modelware,

we chose to project onto the base view models, not onto the concrete implementations 5.

The library is 30KB in zipped byte-code size. The projection code only involves base

view models and their implementations. Therefore, no new code is created for MORB to

become reactive except the mapping of an abstract pointcut. This mapping starts the

Reactor when MORB is initialized by standard CORBA APIs.

To quantify the performance improvement, we simulate a multi-connection scenario

as follows: we host MORB on a IBM ThinkPad T41 running WindowsXP, and we start a

4Java NIO. http://java.sun.com/j2se/1.4.2/docs/guide/nio/5As we mentioned earlier, projection is done through ”declare parents” statements and very easy to

modify.

Page 85: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 76

Number of clients 10 50 100 500

Ave. Reactive 43.3 195.02 135.53 208.67

Ave. Proactive 73.1 476.98 250.49 620.59

Improvements percentage 41% 60% 46% 66%

Table 6.1: Improvements of using Java New I/O in Modelware

number of clients on a Pentium 4 2G box running the Linux 2.4 kernel. The two comput-

ers are on a wireless LAN. Each client uses 300 ”oneway” calls to warm up, and the time is

taken for the completion of the next 300 calls. All the clients are separate processes syn-

chronized by a semaphore to try to create as many simultaneous connections on the server

side as possible. Table 6.1 summarizes the average time for each scenario comparing the

reactive MORB with the proactive version (unit is in milliseconds). Our results confirms

the findings [24] that request processing based on asynchronous I/O greatly alleviates

the middleware overhead of threading when the number of simultaneous incoming con-

nections is large (over 50 in our case). In Modelware, these two communication facilities

can be inter-changed at the bytecode level.

6.1.3 Support Middleware Evolution in Space

Application domains of middleware systems have diverged from traditional enterprise

environments to mobile and embedded devices due to the popularity of ubiquitous com-

puting. Differences of computing environments manifest in the middleware architecture

as different APIs, communication styles, data types, and many others, even though the

RPC semantic does not change. In conventional architectures, evolving middleware into

different platforms or domains often results in non-modular modifications to the archi-

tecture so that the code reusability of common functionalities is dramatically reduced.

The focus of this experiment is to measure how well Modelware supports reusability

Page 86: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 77

in creating middleware platforms for three dramatically different application domains:

smart cards (Java Card), mobile devices (J2ME), and traditional environments (J2SE).

We measure reusability as the ratio of the code size (LOC) between reused components

in the implementation library and the entire middleware implementation. We distinguish

between two types of usability: inter-domain reusability, where components are reused

in all three platforms, and intra-domain reusability, where components are selected for

a specific platform. We have implemented three Modelware-based CORBA implementa-

tions: the Java Card platform (872 LOC and 56.1k bytecode size), the J2ME platform

(1901 LOC and 219k bytecode size for the full configuration), and MORB (6370 LOC and

508k bytecode size for the full configuration). The J2ME version is created and tested

using the Nokia Series 60 emulator 6. The Java Card version is created and tested on

the Sun Java Card toolkit 2.2.1. The Java Card implementation is significantly smaller

than the J2SE and J2ME versions because Java Card applications always play a passive

role in the master-slave model 7. Therefore, we only implement the request processing

functionality for the Java Card instance of Modelware.

In Table 6.5, we report our measurements of both inter-platform and intraplatform

reusability for these three implementations. For each implementation, we also list the

features being reused or created. Our experimental implementations show that different

flavors of ORBs can be created with a high degree of reusability. The code to be newly

created to support new platforms ranges from 2% to 22.5% of the entire ORB code size.

Page 87: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 78

Platform: Standard desktop platform (J2SE)

Overall reusability: 77% (cross-domain 8.7%, intra-domain 68.3%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant.

Intra-domain reuse: Object reference, concurrency control, transport, type support,

two-way communication, protocol initiator and responder, OMG interfaces, code set

conversion, portable interceptor, invocation service context, thread specific storage

support, transparent collocation support, reactor

Newly created: ORB interface impl, OMG interface adaptation for Modelware

components, aspect view adaptation

Platform: Mobile devices (J2ME)

Overall reusability: 98.6% (cross-domain 25.15%, intra-domain 73.38%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant.

Intra-domain reuse: Object reference, concurrency control, type support except

float & double, two-way communication, transport, protocol initiator, protocol responder,

OMG interfaces

Newly created: J2me version of the ORB interface implementation, OMG interface

adaptations as mentioned previously.

Platform: Embedded devices (Java Card)

Overall reusability: 97% (cross-domain 63.53%, intra-domain 34.27%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant.

Intra-domain reuse: Transport, protocol responder, Modelware hashtable,

Modelware vector

Newly created: Java card ORB interface implementation

Table 6.2: Reusability study of Modelware CORBA in supporting different application

platforms

Page 88: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 79

Message Receiving (A)

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 4 6 8

# of sessions

Rec

eivi

ng ra

te (M

sg/s

econ

d)

OpenJms

mjms

difference

Message Receiving (B)

0

500

1000

1500

2000

2500

3000

3500

4000

1 5 10 20 30 40 50Message size (KB)

Rec

eivi

ng ra

te (M

sg/s

econ

d)

OpenJms

mjms

difference

Message Sending (A)

0

500

1000

1500

2000

2500

3000

3500

4000

1 2 4 6 8

# of sessions

Send

ing

rate

(Msg

/sec

ond)

OpenJms

mjms

difference

Message Sending (B)

0

500

1000

1500

2000

2500

3000

3500

4000

1 5 10 20 30 40 50

Message size (KB)

Send

ing

rate

(Msg

/sec

ond)

OpenJms

mjms

diferernce

Figure 6.2: Benchmark performance comparison between MJMS and OpenJms

6.2 Modelware Java Message Service (MJMS)

6.2.1 Runtime characteristics

MJMS is built based on the Modelware base view and aspect view library. The focus of

this experiment is to show the benefits of the simplicity and flexibility of the Modelware

library, and show that the middleware systems built by using the Modelware approach

can achieve good performance compare to the systems implemented in the traditional

approach. We compare MJMS with OpenJms on the Sonic JMS benchmark 8 mea-

6Nokia Series 60 Platform. http://forum.nokia.com7Java Card: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-javadev.html8Sonic JMS benchmark. http://www.sonicsoftware.com/products/sonicmq/performance benchmarking/index.ssp

Page 89: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 80

surements. The benchmark results are collected on a Pentium 4 2.5GHz PC running

MicroSoft Windows XP.

# of subscribers 1 2 3 4 6 8

OpenJms 196 263 302 325 354 340

(msg/sec)

MJMS 3744 5892 7188 6103 4460 3539

(msg/sec)

Table 6.3: Performance improvements in Publish/Subscribe model

In our experiment setup, there are a message server, a message sender and a message

receiver. There are one connection between the sender and the server and one connection

between the receiver and server. The sender uses several sessions to deliver messages to

the message server. Each session runs in a single thread context. The receiver asyn-

chronously receives messages from the message server by registering callback message

listeners with the server. Once there are messages available, the server will invoke the

message listeners to send the messages to the receiver. The receiver can have multi-

ple message listeners. Each listener is executed in a receiver session. We present three

categories of benchmark tests. In Category A, we compare the connection multiplex-

ing/demultiplexing capability by varying the number of sessions for the connection. In

Category B, we compare the message transmission rate under the heavy payload. Fig-

ure 6.2 shows that in Category A and B, MJMS performs constantly 9-10 times faster

than OpenJms. As the number of sessions and message payload increase, MJMS per-

fomance changes in the same pattern as OpenJms. We believe that this is due to the

simplicity of the Modelware library and the effectiveness of the Modelware composition

approach, so that the same set of implementations, which are used to build MORB, can

be easily reused to build a JMS system. This result also proves that the overhead of

Page 90: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 81

composing middleware by using aspect-oriented technology is very small. Note that in

the experiments of Category A, the OpenJms implementation will begin to run out of

memory when the number of sessions are larger than 8. This shows the good scalability

of MJMS implementation. The measurements of Category A and B are based on the

JMS point-to-point model in which the message queue is used on the server. Category

C measures the receiving rate in the publish/subscribe model by varying the number

of subscribers to a common topic, as shown in Table 6.3. In this category, the MJMS

performance is also constantly better than the the OpenJms performance.

6.2.2 Support Middleware Evolution in Time

Message Sending

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

0 1 2 5 8

Message size (KB)

Sending rate (msg/second)

without

with

Message Receiving

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

0 1 2 5 8Message size (KB)

Receiving rate (msg/second)

without

with

Figure 6.3: Performance improvements with collocation support

As the complexity of the enterprise computing system increases, the enterprise com-

puting services must be able to dynamically adapt to different usage scenarios and en-

vironments. One of common situations is that the computing services could move from

one machine to another machine, or from one process to another process. In the case of

JMS, the message server could move from a remote machine to the same machine as the

message client, and run in the same process as the client. Normally, the client contacts

Page 91: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 82

the message server through underlying communication network, and assumes that the

server is located on a different machine or at least in a different process. However, when

the message server is located in the same process as the client, the network communica-

tion overhead is not necessary for the message delivery.

One optimization to solve this problem is to allow the client to contact the mes-

sage server through local method calls. However, the remote server assumption is deeply

hard-coded in the original architecture, this simple optimization will involve a lot of mod-

ifications of the original implementation, so it is not easy to integrate this feature with

the existing middleware system. In Modelware approach, we capture this optimization

in an aspect view, Collocation, as shown in Section 4.6.6. By adding simple adapta-

tion code, this optimization can be added to the core implementation of the middleware

system to support its evolution without even modifying the original source code. The

adaptation process is straight-forword. we just need to use the Aspectj ”declare parents”

capability to let the MJMS base code implement the collocator and initiator owner roles,

and concretize the pointcut for using the initiator proxy.

To show the benefits of supporting the collocation optimization, we compare the

runtime performance of MJMS with different payload sizes per message when supporting

and not supporting the collocation optimization. The experiments are conducted on an

AMD Athlon(tm)XP 1.53GHz PC running MicroSoft Windows XP Professional with

512MB physical memory. Figure 6.3 shows the comparison for the message sending rate

and message receiving rate. In most cases, the version with collocation support is around

100% faster than the version without collocation support.

Page 92: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 83

6.2.3 Support Middleware Evolution in Space

JMS is a part of J2EE 9 standard, and is traditionally deployed in enterprise computing

environments. In this experiment, we study the resusability of Modelware implemen-

tation when creating JMS-like middleware systems for three different platforms: Java

Card, J2ME, and J2SE. This experiment follows the style of Section 6.1.3. We mea-

sure the ratio of code size (LOC) between the componets reused from the Modelware

implementation library and the entire Modelware JMS implementation. This ratio indi-

cates the reusability of the Modelware library. For the reusability, we categorize it into

inter-domain reusability, which is the reusability of the library components across three

platforms, and intra-domain reusability, which is the reusability of the library components

for the specific platform.

Table 6.4 shows the inter-domain and intra-domain reusability of the three platforms.

The J2ME version and the Java Card version are same as Section 6.1.3. The MJMS for

the Java Card platform has 1157 LOC and 71k bytecode size; the MJMS for the J2ME

platform has 2790 LOC and 280k bytecode size; the MJMS for the J2SE platform has

4490 LOC and 476k bytecode size. Since the Java Card application is always passive and

cannot actively contact the card reader, we only implement the JMS server on the Java

Card platform. Therefore, similar in MORB case, the MJMS for Java Card is significantly

smaller than the versions for J2ME and J2SE. According to J2ME Connected Limited

Device Configuration (CLDC) 1.1 10, the programmer cannot override, modify or add

any class in system package, such as java.* or javax.*. The JMS interfaces are defined in

java.jms package, so in the J2ME version of MJMS, the JMS interfaces are excluded by

removing the interface mapping code.

9Java Platform, Enterprise Edition. http://java.sun.com/javaee/10SUN CLDC. http://java.sun.com/products/cldc/

Page 93: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 84

Platform: Standard desktop platform (J2SE)

Overall reusability: 67% (cross-domain 13.8%, intra-domain 53.2%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant

generic message queue, publish/subscribe matching

Intra-domain reuse: concurrency control, transport, type support, two-way

communication, protocol initiator and responder, JMS message type, data storage,

JMS interface, transparent collocation support

Newly created: JMS server initialization module, JMS interface adaptation for

Modelware components, aspect view adaptation, message handling logic

Platform: Mobile devices (J2ME)

Overall reusability: 78% (cross-domain 25.4%, intra-domain 52.6%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant

generic message queue, publish/subscribe matching

Intra-domain reuse: concurrency control, type support except float & double, two-way

communication, transport, protocol initiator, protocol responder,JMS message type,

data storage

Newly created: JMS server initialization, message handling logic, aspect view adaptation.

Platform: Embedded devices (Java Card)

Overall reusability: 75.5% (cross-domain 49.7%, intra-domain 25.8%)

Cross-domain reuse: Buffer, GIOP Protocol, messages, stub, request, response, servant.

generic message queue

Intra-domain reuse: Transport, protocol responder, Modelware hashtable, Modelware vector

Newly created: message handling logic

Table 6.4: Reusability study of Modelware JMS in supporting different application plat-

forms

Page 94: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 85

6.3 Modelware Reusability

J2SE J2ME Java Card

LOC Bytecode LOC Bytecode LOC Bytecode

Modelware CORBA

6370 508k 1901 219k 872 51.6k

Modelare JMS 4490 476k 2790 280k 1157 71k

Figure 6.4: The code size (LOC) and bytecode size of Modelware CORBA and JMS.

One of the most important goals of Modelware is to achieve high reusability. In the

Modelware approach, the system ”extrinsic” properties, i.e., the features that are not

localized within modular boundaries, are encapsulated in aspect modules. Therefore, the

design and implementation of the middleware systems become simpler and more coher-

ent. The simplicity increases the chance that these components are reused in different

application contexts. At the same time, the ”extrinsic” features are implemented in sep-

arate aspect modules, and the tangling among these features are also reduced. Therefore,

the reusability of these ”extrinsic” features will be increased as well. Figure 6.4 summa-

rizes the sizes of Modelware CORBA and JMS.

J2SE J2ME Java Card

Modelware CORBA 77% 98.6% 97%

Modelware JMS 67% 78% 75.5%

Table 6.5: The percentage of reused Modelware implementation on three Java platforms.

Table 6.5 shows the reusability of the Modelware implementations on three Java plat-

Page 95: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 86

forms. Comparing the results from these two middleware systems (MORB and MJMS),

we can identify several trends that are common in both implementations. The results are

categories into three platforms, i.e., J2SE, J2ME and Java Card, for both MORB and

MJMS. Comparing with J2SE, the J2ME and Java Card are reduced Java platforms,

and they target mobile and embedded devices. Therefore, due to limited memory and

API support, the middleware implementations on J2ME and Java Card are significantly

simpler than the one on J2SE. For both MORB and MJMS, the bytecode size of the

J2ME version is around 50% of the J2SE version; the bytecode size of the Java Card

version is around 15% of the J2SE version. The simplicity of the J2ME version and

the Java Card version results in a high reusability (17% to 26% higher than the J2SE

version), because the implementations of these two versions are mainly essential middle-

ware logic, which is well captured in the Modelware base view. Another trend is that

MORB has the higher reusability than MJMS. This result is mainly due to the fact that

MJMS includes the application level message handling logic, which does not belong to

the Modelware library. We believe that this difference of reusability is caused by the large

difference between the application contexts of the two middleware systems. Therefore,

the current reference implementation of Modelware can only capture the common logic

of the general distribution middleware. When applying the Modelware approach to the

real world design and implementation, stronger application context will be assumed, so

the implementation library based on the Modelware approach will be able to capture

more common logic and achieve the high reusability.

6.4 Modelware Customization

In the Modelware approach, different features are captured by aspect views. These aspect

view implementations are built in an aspect-oriented fashion. By utilizing the weaving

capability of the Aspectj compiler, we can select or deselect different features at compile

Page 96: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 87

1 CodeSet = ServiceContext * (wchar + char);2 PI = ServiceContext;3 callback = concurrency;4 PITSS = TSS * PI;5 reactor = !concurrency;6 concurrency = !reactor;7 string = char;8 wstring = wchar;

Figure 6.5: Feature dependency specifications in Modelware CORBA

time without modifying the source code. The advantage of this capability is that software

companies do not need to keep different teams to maintain a suite of software products

that are designed based on the same base architecture, but are targeted to different user

domains or platforms. The variation of user domains and platoforms can be captured in

aspect views. By creating different configuration for the system at compile time, one team

can maintain the whole product suite. To study the Modelware customization capability,

we adapt the aspect views listed in Section 4.6 to the Modelware CORBA (MORB), and

turn them to selectable features. Figure 6.5 shows the dependency specifications in Mod-

elware CORBA. Note that all the features depends on the base view implementation. In

Figure 6.5, char, wchar, string and wstring are four data type views; Concurrency stands

for the thread-level concurrency view; PI stands for the portable interceptor view; TSS

stands for the thread specific storage; PITSS stands for the portable interceptor thread

specific storage.

By using the Modelware Customization Framework, we create five different versions

of MORB as shown in Table 6.6. For each version, we first indicate a set of initial

selection of features, then pass the selection to the framework. If the initial selection

Page 97: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 88

Features Feature Customization

v1 v2 v3 v4 v5

I F I F I F I F I F

concurrency 1 1 x 1 1 1 x 0 0

string 1 1 x 0 x 0 x 0 1

wstring 1 1 1 1 x 0 x 0 x

char 1 1 x 0 1 1 x 0 1

wchar 1 1 1 1 1 1 x 0 x

code set 1 1 x 0 1 1 x 0 1

service context 1 1 1 1 x 1 x 0 1

portable interceptor 1 1 x 1 x 0 x 0 x

collocation 1 1 x 0 x 0 x 0 x

TSS 1 1 1 1 x 0 x 0 x

PITSS 1 1 1 1 x 0 x 0 x

callback 1 1 1 1 x 0 x 0 1

reactor 0 0 0 0 0 0 0 0 0

Validity valid valid valid valid invalid

Table 6.6: Feature Selection and Sythesis in Modelware CORBA

Page 98: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 89

does not violate the dependency rules in Figure 6.5, the framework will do the inference

analysis on the selection, correctly synthesize the orb and create the final executable.

Table 6.6 shows the initial selections (under I header) and the selection decisions made

by our inference engine (under F header). A selected feature is represented as ”1”, or

”0” otherwise. ”x” means the selection is unspecified. In the ”F” column, we show the

final configuration compared to its initial value in the ”I” column. We can observe a few

characteristics of the customization framework: 1. the selection decisions of all features

are made; 2. most of the ”x” features are set to ”0” driven by the minimalism goal of our

inference algorithm. In this set of experiments, we measure the runtime performance in

the traditional Java I/O implmentation, so we deselect the reactor feature in the initial

selection of all the versions. In Table 6.6, Version 1 includes all the features except the

reactor, and represents a full-scale CORBA implementation. Version 1 is our baseline

of the comparison in this section. In version 4, none of the features are selected, so

it represents a minimum ORB. The rest of the configurations are randomly generated

to show how the Modelware Customization Framework deals the real-world unexpected

configuration requirements. As a result, the customization process shows that the initial

selection of version 5 is invalid, because as shown in Figure 6.5, the callback depends on

the concurrency feature. However, the concurrency is deselected in the initial selection

of version 5. In this case, the inference algorithm will not proceed further, and indicate

the user there is an selection violation.

6.4.1 Static properties

We first measure the static properties on the compiled Java bytecode. The static prop-

erties such as size and coupling are generally considered as reflecting the complexity of

the code and the degree of difficulties in terms of maintenance and evolution. Table 6.7

reports the sizes of the synthesized ORBs as well as the coupling metrics measured on

Page 99: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 90

Target Bytecode Efferent Afferent

Size Coupling Coupling

v1 508k 638 477

v2 396k 494 366

v3 399k 440 321

v4 211k 438 299

Table 6.7: Static Comparisons of Modelware ORBs

bytecode by JDepend 11. We show in table 6.7 the bytecode sizes of the version 2-4 are

between 41.5% (v4) and 78.5% (v3) of v1, with the efferent coupling ranging from 68.6%

(v4) to 77.4% (v2) and the afferent coupling ranging from 62.7% (v4) to 76.7% (v2).

6.4.2 Runtime properties

Client-Server Data Send Average

0

5000

10000

15000

20000

25000

3 10 40 200

500

3000

1000040000

200000

Payload size (byte)

Invocati

on t

ime (u

sec)

v1

v2

v3

v4

Figure 6.6: Performance of synthesized ORBs with different request payload

To study the runtime characteristics of the generated ORBs, we first measure and

11JDepend URL:http://www.clarkware.com/software/

Page 100: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 6. Evaluation 91

Target Response Memory

v1 672 1984k

v2 594 1984k

v3 484 1984k

v4 281 1984k

Table 6.8: Runtime Properties of synthesized ORBs

compare the time taken for payloads to traverse the middleware stack. We then collect

the response time, the and memory usage of these ORBs. The experiments are performed

on a Pentium 4 2.5GHz PC running MicroSoft Windows XP. In Figure 6.6, we plot the

average time of the payload transportation for the synthesized ORBs. In general, the

v2-v4 are faster than v1 in the range between 9.7% (v4) and 3.9% (v2). In addition, we

report the performance results of the request response and the average memory usage,

as shown in Table 6.8. The response time is measured as the average of 100k remote

invocations of an empty method (”ping”). The average memory usages for all the versions

are same. We believe that this is due to the efficient implementation of CORBA in the

Modelware approach, so that none of the synthesized ORBs will consume the significant

system memory.

Page 101: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 7

Conclusion and future work

We believe one of the main reasons for insufficient component reuse in system software

such as middleware is the presence of crosscutting concerns. We have observed two major

characteristics of this deficiency. Firstly, many middleware abstractions, such as design

patterns and usage idioms, live persistently across evolution stages, but their implemen-

tations do not exist as development artifacts that can be directly reasoned and reused.

Second, many designs and algorithms are repeatedly applied in conventional architec-

ture. Unfortunately, due to their crosscutting nature, no effective ways exist in explicitly

representing, evolving, and reusing them.

Our solution to overcome these difficulties is through Modelware in applying the

model-driven approach to the middleware architecture itself. The foundation of our

approach is to enable ”multi-views” in the middleware architecture. That is, we explic-

itly represent the intrinsic properties or the internal logic of the middleware through

platform independent models in the ”base view” of the middleware architecture. The

implementations of these abstract concepts, i.e., the Platform Specific Model, are stored

in the implementation library. The transformation between PIM and PSM models are

in form of dependency descriptions. In addition to the base view, we model and encap-

92

Page 102: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Chapter 7. Conclusion and future work 93

sulate crosscutting properties of the middleware architecture in individual aspect views.

Aspect views dilute the density of the per-module design complexity by exploiting the

orthogonalities among middleware design concerns. In our case studies, we are able to

add new computing capabilities to Modelware through reusable aspect libraries. We

have also illustrated that supporting functional diversification in space with Modelware

only requires relatively small coding efforts. Our customization framework manages the

features of middleware systems, and synthesizes the final executable correctly and auto-

matically. This framework reduces the human cost for the software maintenance.

In the future work, we are going to further enrich our Modelware base view and aspect

view libraries to prompt the adaptation of Modelware approach in middleware industry.

In this thesis, we mainly utilize the AOP compile-time weaving capability for Modelware.

However, the new AOP compilers, such as Aspectj compiler, begin to support load-time

and runtime weaving capability. We are interested in applying these new capabilities

of AOP to Modelware and investigating the benefits. Especially, the runtime weaving

will allow us to migrate middleware to different environments without interrupting the

running computing services. The current cost model in our customization framework is

a static model, which means that the cost function never changes for each feature. In

foreseeing the future usage of our customization framework, we are interested in extending

to a dynamic cost model, in which the cost function possibly changes according to the

selection of different feature sets.

Page 103: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

Bibliography

[1] Subject-oriented programming: a critique of pure objects. ACM Press, 1993.

[2] An Overview of AspectJ. Springer-Verlag, 2001.

[3] “Chapter 5. Spring AOP: Aspect oriented programming with spring,” in

www.springframework.org, Accessed 05/2005.

[4] D. Batory, J. Sarvela, and A. Rauschmayer, “Scaling Step-Wise Refinement,” IEEE

Transactions on Software Engineering, vol. 30, no. 6, pp. 355–371, June 2004.

[5] P. A. Bernstein, “Middleware: a model for distributed system services,” Communi-

cations of the ACM, pp. 86–98, February 1996.

[6] S. Bonnet and O. Potonnie, “A model-driven approach for smart card configuration,”

in GPCE, Vancouver, October 24-28 2004.

[7] S. Brown and Z. Vranesic. The McGraw-Hill Companies, Inc., 2000.

[8] B. Burke and A. Brock, “Aspect-oriented programming and JBoss,” in ON Java.com,

05/28/2003.

[9] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, P. Sommerlad, and

M. Stal. John Wiley & Sons, 1997.

[10] S. Clarke and R. J. Walker, “Composition patterns: An approach to designing

reusable aspects,” in ICSE, Toronto, Canada, May 2001, pp. 5–14.

94

Page 104: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

BIBLIOGRAPHY 95

[11] T. Cohen and J. Gil, “AspectJ2EE = AOP + J2EE,” in ECOOP, 2004, pp. 219–243.

[12] A. Colyer and A. Clement, “Large-scale AOSD for middleware,” in 3rd International

Conference on Aspect-oriented Software Development (AOSD’04), Lancaster, UK,

2004, pp. 56 – 65.

[13] E. W. Dijkstra, “The humble programmer,” Commun. ACM, vol. 15, no. 10, pp.

859–866, 1972.

[14] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Addison-

Wesley, 1995.

[15] J. Hannemann and G. Kiczales, “Design Pattern Implementation in Java and As-

pectJ,” in Proceedings of the 17th ACM SIGPLAN Conference on Object-Oriented

Programming, Systems, Languages, and Applications. ACM Press, 2002, pp. 161–

173.

[16] F. Hunleth and R. Cytron, “Footprint and Feature Management using Aspect-

Oriented Programming Techniques,” in Languages, Compilers, and Tools for Em-

bedded Systems (LCTES’02), 2002.

[17] E. A. Kendall, “Role model designs and implementations with aspect-oriented pro-

gramming,” in OOPSLA ’99: Proceedings of the 14th ACM SIGPLAN conference

on Object-oriented programming, systems, languages, and applications. ACM Press,

1999, pp. 353–369.

[18] M. Kersten and G. C. Murphy, “Atlas: a case study in building a web-based learning

environment using aspect-oriented programming,” in Proceedings of the 14th ACM

SIGPLAN conference on Object-Oriented Programming, Systems, Languages, and

Applications. ACM Press, 1999, pp. 340–352.

Page 105: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

BIBLIOGRAPHY 96

[19] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and

J. Irwin, “Aspect-oriented programming,” in Proceedings European Conference on

Object-Oriented Programming, M. Aksit and S. Matsuoka, Eds. Berlin, Heidelberg,

and New York: Springer-Verlag, 1997, vol. 1241, pp. 220–242.

[20] N. Loughran, N. Parlavantzas, M. Pinto, P. Sanchez, M. Webster, and A. Colyer,

“Survey of aspect-oriented middleware,” AOSD-Europe network of excellence, Tech.

Rep., April 2005.

[21] A. D. McKinnon, K. E. Dorow, T. R. Damania, O. Haugan, W. E. Lawrence, D. E.

Bakken, and J. C. Shovic, “A Configurable Middleware Framework for Small Em-

bedded Systems that Supports Multiple Quality of Service Properties,” submitted

to Software Practice and Experience.

[22] J. Mylopoulos, L. Chung, and B. Nixon, “Representing and using non-functional

requirements: a process-oriented approach,” IEEE Transactions on Software Engi-

neering, 1992.

[23] B. Nuseibeh, J. Kramer, and A. Finkelstein, “A framework for expressing the rela-

tionships between multiple views in requirements specification,” IEEE Trans. Softw.

Eng., vol. 20, no. 10, pp. 760–773, 1994.

[24] D. C. Schmidt, “ACE: An Object-Oriented Framework for Developing Distributed

Applications,” in the 6th USENIX C++ Technical Conference. Cambridge, MA:

USENIX Association, April 1994.

[25] D. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Pattern-Oriented Software

Architecture Patterns for Concurrent and Networked Objects, 1st ed., ser. Software

Design Patterns. John Wiley & Sons, Ltd, 1999, vol. 2.

[26] D. C. Schmidt, A. Gokhale, B. N. S. Neema, and et al., “CoSMIC: An MDA gen-

erative tool for distributed real-time and embedded component middleware and ap-

Page 106: Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf · Aspect-Oriented Middleware ... 4.5.2 Java Messaging Service (JMS) ... 6.2 Benchmark performance

BIBLIOGRAPHY 97

plications,” in OOPSLA 2002 Workshop on Generative Techniques in the Context

of Model Driven Architecture, Seattle, WA, November 2002.

[27] D. C. Schmidt, D. L. Levine, and S. Mungee, “The design of the tao real-time object

request broker,” Computer Communications, vol. 21, no. 4, April 1998.

[28] S. Soares, E. Laureano, and P. Borba, “Implementing distribution and persistence

aspects with AspectJ,” in OOPSLA, 2002, pp. 174–190.

[29] P. Tuma and A. Buble, “Open CORBA Bench Marking,” SPECTS 2001, uRL:

http://nenya.ms.mff.cuni.cz/∼bench.

[30] U. Zdun, M. Kircher, and M. Volter, “Remoting patterns,” in IEEE Internet Com-

puting, no. 6, November/December 2004, pp. 60–68.

[31] C. Zhang, D. Gao, and H.-A. Jacobsen, “Generic middleware substrate through

modelware,” in 6th International Middleware Conference, 2005.

[32] ——, “Towards just-in-time middleware architectures,” in Fourth International Con-

ference on Aspect-Oriented Software Development, 2005.

[33] C. Zhang and H.-A. Jacobsen, “Resolving feature convolution in middleware sys-

tems,” in In Proceedings of the 19th ACM SIGPLAN conference on Object-oriented

Programming, Systems, Languages, and Applications, September 2004.