Towards JustinTime Middleware Architectures

1
Towards Just-in-Time Middleware Architectures

• Authors Charles Zhang, Dapeng Gao and Hans-Arno
  Jacobsen
• Middleware Systems Research Group
• Department of Computer Science
• University of Toronto

Published at AOSD 2005
2
Summary

• Motivation
• Proposal
• Just-in-time Middleware (JiM)
• Abacus/ Arachne
• Evaluations
• Conclusions

3
Motivation

• Traditional middleware architectures
• Monolithic or coarse-grained
• Pre-postulated Architectures
• Middleware functionality is independently
  conceived and packaged before their applications

Inflexibility to meet the applications
requirements
4
Motivation

• Need of versatile middleware architecture which
  adapts to
• Changing external execution environments
• Applications requirements

5
Proposal

• A reverse design paradigm middleware
  architecture is post-postulated from the
  knowledge embedded in the user application
• Just-in-time Middleware (JiM)

6
Just-in-time Middleware (JiM)

• Middleware Core (vertical dimension)
• Minimum set of functionalities
• Associated structures (horizontal dimension)
• Aspects

7
Just-in-time Middleware (JiM)

• The executable middleware is only generated after
  the application and according to its requirements
• The application needs should be externalized and
  they drive the composition of the middleware

8
Stages to Achieve this Goal

• ACQUISITION
• Gathering functional requirements from both the
  user application and environmental constraints
• TARGETING
• Reasoning about the final composition of
  middleware
• SYNTHESIS
• Generating the middleware

9
JiM Customization Stages
Application sources
User Preferences
Explicit Acquisition
Adjustment Suggestions
Initial Manifest
Feature Dependency Rules
Functional Inference
Inferred Manifest
Composition Constraints
Verification
Final Manifest
Synthesis
Convolution Descriptions
Middleware Implementation
10
Feature Dependency Rules

• Specify that the implementation of certain
  functionality is composed from other
  functionalities

String
String
Char
11
Composition Constraints

• Specify the inclusions and exclusions of
  functionalities reflecting external conditions
• J2ME does not support the applet infrastructure

12
Convolution Descriptions

• Describes the interactions among features
• Feature A crosscuts Feature B and Feature C
• Portable Interceptors crosscut Dynamic Interface

13
Abacus

• A Java Orb based on aspect-oriented ORBacus a
  prototype implementation of JiM
• Arachne Abacus synthesizer (extends the
  aspect-aware IDL compiler)

14
Abacus configurable aspects
Categories
Features
Server Data Types
Integer, String, Double, Fixed, Float, Long,
Remote Invocation Semantics
Synchrony, Asynchrony,
CORBA Infrastrcutures
Policies, Implementation Repository,
Interceptors, Fault Tolerance,
Remote Invocation Styles
DII, DSI, Any

15
Arachne

• Aspect-aware IDL compiler
• Generates modular stubs and skeletons
• Acquires middleware functionalities from service
  declarations
• Java source parser
• Checks Java class types used in the user
  application
• Inference Engine

16
Aspect-aware IDL compiler

• The stub code for the original IDL definition is
  split into two sets of modules
• Java modules
• AspectJ modules (for aspects)

17
Dependencies in Arachne

• Specified in a HDL (Horizontal Dependency
  Definition Language)

Dependencies expressed in HDL
HDL elements
aspect any, dynamic, pi, synchrony, Core
core synchrony asynchrony any int
string ulonglong ,,, dii dynamic
dsi dynamic .
aspect aspect1, aspect2, Module name
aspect1 aspect2 (aspect3 aspect4)
.
18
Constraints
Constraint
Annotations
Precision
J2ME does not support high precision types such
as double and fixed
Infrastructure
The applet infrastructure is not supported in J2ME
19
Convolution descriptions

• Boolean expression where the left side is a
  feature that crosscuts the features on the right
  side

convolution_descriptions double any
valuetype ulonglong any valuetype
PI DII DSI IR longlong double any
valuetype )
20
Packaging Schema
implementation
core
aspectname
interaction
aspectname
ltlt more aspect namesgtgt

test
core
21
Synthesis process

• Guided by the Arachne user interface
• Loads IDL definitions and application source
• Analysis IDL and source code
• Generates the final manifest (inference engine)
• Generates the modules that compose the middeware
  (using the convolution description and the
  packaging schema)

22
Evaluation

• Two tests
• A Ubiquitous Messenger Application
• Randomized Selections of Features

23
UMessenger
Module CORBAMessenger struct Msg
string from string to
string stringdata long long
numericData
Module CORBAMessenger interface MiniMessenger
void login(in string user) void
logout(in sring user) seqMsg contact (in
Msg info) oneway void asyncContact(in Msg
info)
IDL Definition for Embedded Environment
Module CORBAMessenger valuetype
LargeData private string filename
typedef sequence ltoctetgt content
long save() struct Msg
// repeat fields of minimum message
sequence ltdoublegt floatData LargeData
payload
General IDL Definition
IDL Definition for Desktop Environment
24
Comparisons
Target Environment
Bytecode Size
Response
Memory
Embedded Platform
823.9 k
261 µs
15223 k

Desktop
875.1 k
281 µs
15164 k
Original
1945.3 k
282 µs
19694 k
25
Conclusions

• An ongoing research (just preliminary results)
• Dependent on ORBacus
• Future directions
• To include other middleware features
• To evaluate the middleware using diverse
  application domains
• To integrate with MDA