Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf ·...
Transcript of Aspect-Oriented Middleware - University of Torontoexec/thesis_lib/2006/gao_masc.pdf ·...
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
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
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
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
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
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
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
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
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
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
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
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.
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
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/
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
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
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.
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
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
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.
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.
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
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
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
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
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
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/
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
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.
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-
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
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
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-
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,
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/
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-
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
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/
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
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
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-
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.
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-
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
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
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.
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
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-
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
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
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
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
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
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.
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.
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.
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.
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
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
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
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
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-
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
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
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.
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
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
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
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-
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
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
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
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
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
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
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
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.
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
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
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/
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
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.
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-
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.
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
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.
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
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
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
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
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.
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/
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
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-
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
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
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
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
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/
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.
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
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.
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
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.
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-
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.