ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability

1
ReMMoC A Reflective Middleware to Support Mobile
Client Interoperability
Sam Samuel Global Wireless Systems Research, Bell
Laboratories, Lucent Technologies, UK

• Paul Grace, Gordon Blair
• Distributed Multimedia Research Group, Computing
  Department, Lancaster University, UK

2
Outline

• The challenges for mobile computing middleware
• Middleware heterogeneity
• The ReMMoC approach
• Reflection, components component frameworks
• A Web Services based programming model
• Evaluation
• Future work concluding remarks

3
The Challenges of Mobile Computing

• The characteristics of the mobile environment
  present a number of challenges for middleware
  developers. For example
• Disconnection
• Low variable Bandwidth
• Address Migration
• Low Power
• Small Storage Capacity
• Middleware seeks to overcome these to better
  support distributed mobile applications.

4
Mobile Computing Middleware

• Different styles of mobile middleware have
  emerged to solve these challenges.
• Asynchronous paradigms
• Publish-Subscribe (REBECA, STEAM)
• Tuple Spaces (LIME, L2IMBO)
• Context-based adaptation
• CHARISMA, OpenORB, Odyssey
• Enhancements to established middleware
• RAPP, Alice, Dolmen (CORBA) Wireless RMI (Java
  RMI)

This explosion of middleware solutions creates
middleware heterogeneity. No interoperability
between different middleware styles.
5
A Mobile Computing Scenario
6
The ReMMoC Approach

• A Reflective Middleware to support mobile client
  interoperability.
• Find mobile services irrespective of the service
  discovery protocol
• Interoperate with services implemented by
  different middleware types
• Design of ReMMoC built upon four concepts
• Components (OpenCOM)
• Reflection
• Component Frameworks (CFs)
• The abstract Web Services programming model

7
The ReMMoC Architecture
8
Component Frameworks in ReMMoC
ILifeCycle
IMetaInterface
IConnections
OpenCOM component framework
ICFMetaArchitecture
CF Service Interfaces (Can be exposed interfaces
of internal components)
CF receptacles (Can be exposed)
Lock Interceptor
Graph of internal components
Validation Plug-in
9
The Service Discovery Framework

• Discover Services advertised by different
  protocols.
• Dynamically reconfigures itself based upon
  current environment conditions.
• Cycles through tests for known types of service
  discovery.
• Single-personality discovery performed over a
  single protocol type.
• Multi-personality discovery executed
  simultaneously over a number of types.
• Current Implementations UPnP and SLP lookup.

10
The Binding Component Framework

• Dynamic replacement of binding types
  (implemented as OpenCOM components) based upon
  information the from service discovery CF.
• Configurations weve implemented - IIOP client,
  IIOP Server, SOAP client, subscriber, publisher

11
An Abstract Programming Model Web Services

• How to program clients independently of the
  changing underlying middleware?
• The aim of Web Services is to allow different
  service providers to implement abstract service
  descriptions upon their chosen concrete
  middleware binding.
• WSDL language defines abstract service
  descriptions.
• A Client application, programmed against the
  abstract WSDL definition, can interoperate with
  different concrete implementations.
• Hence, ReMMoC utilises the abstract service
  descriptions of WSDL
• Meets requirement of programming independently of
  middleware.
• API provides consistent information flow to the
  application.

12
Our Assumptions
Client Application
Service
Concrete Middleware
ReMMoC

• Client application service Programmed against
  shared WSDL description.
• Understand same types
• We address mobile client side of this diagram.

13
Abstract to Concrete
WSDLOperation Name Request Response Input
Message Data Output Message Data
Binding CF
14
Mapping Paradigms to WSDL Operations
SP
SR
SR
SR
Output
Input
Input
Output
Input
RMI
SP
Output
SP
SP
SP
Content Subject Filter
Content Subject Filter
Input
SR
SR
SR
Input
SP
Output
Publish-Subscribe
Subject Filter
SP
Output
Input
Subject Filter
SP
SP
SP
Concrete message
SR Service Requestor
Abstract message
SP Service Provider
15
Evaluation - Mobile Applications

• Goal to develop a mobile application using ReMMoC
  that operates in different locations exhibiting
  middleware heterogeneity.
• Three Applications implemented
• Jukebox, Chat Service, Sport News.
• Different locations (e.g. Office Home
  Environment).
• Heterogeneous discovery protocols (UPnP SLP).
• Heterogeneous binding protocols (P/S, SOAP,
  IIOP).
• The same application code (containing only
  abstract operations) operates continuously across
  different locations.

16
Evaluation Memory Capacity

• Mobile devices are resource light and reflection
  is expensive why not reconfigure at the server
  side?

17
Future Work

• Dynamic component downloading architecture based
  upon context information.
• Extension to include other binding paradigms
• Tuple spaces, data-sharing, multimedia streaming
  etc.
• Integration with resource management
  architecture.
• Evaluation using more complex applications
• Ambient intelligent environments, ubiquitous
  computing.
• Investigate Web Service description formats that
  include non-functional aspects (e.g. Web Services
  Endpoint Languages) and more complex interaction
  patterns (e.g. Web Services Flow Language).

18
Concluding Remarks

• Mobile environments contain heterogeneous
  middleware
• ReMMoC developed to support application
  developers in face of this type of heterogeneity
• Reconfiguration of binding and service discovery
• Evaluated and demonstrated across a set of mobile
  applications
• Jukebox
• Chat service
• Sport News Service