Calling the cloud: Enabling mobile phones as interfaces to cloud applications

http://people.inf.ethz.ch/oriva/pubs/riva_middleware09.pdf

Sweet Home 3D App: http://www.sweethome3d.eu/download.jsp

The discussion is that the applications are executed either on the mobile phones or on the server. However, there is a need to split the application between the two.

Application profiling is done by providing a consumption graph.

Measured parameters:

• The consumed memory
• The data traffic generated both in input and output
• The code size

The consider the amount of transferred data as the major factor in creating the consumption graph.

Problems with the approach:

• The instrumentation is done manually which requires access to the source code for the bundles
• The focus is only on the user interface because they are considered as more suitable resources to be moved to the cloud
• Also they argue that the hardware requirements vary from phone to phone and thats why they are filtering that parameter of CPU usage out. And thus, the bundles CPU cost is omitted.
  
• The developer marks bundles as movable and nonmovable. What is the reason for a developer to classify bundles as movable and nonmovable? how do you know that the classification is correct and that it works properly?
• They have assumed that every bundle exposes only one service and not more. So, the application does not work with more services
  

In the consumption graph, every vertex is a bundle and every edge is a service dependency.

Bundle Characteristics:

• type: movable or nonmovable
• memory consumption
• code_size
• in: the amount of input data to a bundle B
  
• out: the amount of data sent out of a bundle B

The modularity considered is at the functional level and not at the class or function level. But whether there is better approach to think of modularity is another problem that potentially shoudl be addressed.

The distribution happens only between two nodes and not more.

The optimal cut maximizes or minimizes an objective function and satisfies a phone's resource constraints.

• k: bundles running on the mobile device
• t: bundles on the mobile device with dependency to bundles on the server
• alpha: the bandwidth
• fij: how many times communication between the two bundles happens!!! (weird idea)
• beta: the capacity of the coomunication link + the installation overhead! ( How does it reflect on the installation overhead when it is a completely client dependent parameter!)
• also the proxy cost represents how much effort is required for the proxies to be created in order for the proper communication to happen between the client and the server

DR-OSGi: Hardening Distributed Components with Network Volatility Resiliency

http://people.cs.vt.edu/~tilevich/papers/DR-OSGI.pdf

• A clear exposition of the challenges of treating the ability to cope with
  network volatility as a separate concern that can be expressed modularly.
• An approach for hardening distributed component applications with re-
  siliency against network volatility.
• A proof of concept infrastructure implementation|DR-OSGi|which demon-
  strates how existing distributed component applications can be hardened
  against network volatility.

They use R-OSGi as the base for their system and protect against network volatility.

Scenarios

1. A remote service becomes unavailable|
2. A temporarily unavailable remote service becomes available again

Case Studies:

1. Log Service
2. UserAdmin Service
3. Distributed Lucene
4. DNA Hound
   

** on adopting content-based routing in service oriented architectures

WS-Eventing and WS-Notification are defined in SOA to introduce asynch notifications among web services.

WS-Notification has the following parts

• WS-Base Notification
• WS-Brokered Notification
• WS-Topic
  

WS-Notification gets close to WS-Eventing when it comes to WS-Base Notification which introduces the core roles of

• notification producer
  
• subscription manager: enables a subscriber to pause/resume/cancel a subscription
  
• subscriber
• notification consumer

WS-Brokered Notification introduces concept of notification broker rather than direct communication between the source and the sink of messages.

ESB also supports Content-Based Routing (CBR) in order to transfer messages from one service to another in a B2B type of interaction. Messages can be routed based on some pre-defined rules.

Mule and IBM Web Sphere are examples of ESB messagebrokers.

** Addressing QoS for pub/sub and CBR systems is a challenge

Different discovery approaches

• SeCSE: an apprach based on facets for discovery of services in different phases
• DIRE is the publication infrastructe developed for SeCSE
• in DIRE registries can hold any type of service
• REDS is used as a pub/sub mechanism to replicate service descriptions
• Service descriptions are shared among all registries subscribed to a topic
  
• WS-Discovery proposal
• IP multicast -> only applicable to large scale systems
• Meteor-S uses MWSDI and JXTA to provide p2p network of UDDI registries
  

overall two methods for service discovery

• replication of service descriptions
• propagation of queries within the network of registries

Vision of SOA promotes an environment which is GLOBAL and OPEN for service providers to offer their services and consumers to access and use them. Composition at runtime is also promoted to enable dynamic adaptation to changes in the environment.

--> PAPER ARGUMENT: a scalable service discovery infrastructure to allow different organizations to offer and access services globally, complemented by a pub/sub infrastructure to suit the needs of those systems that have an inherently asynch behavior and to monitor the environment.

------------

REDS is a framework of java classes to easily build a modular CBR infrastructure.

• Defining message and filter
  
• Routing Strategy can be modified
  

There are three challenges in CBR:

• the matching challenge
• the security challenge
• the reconfigurability challenge

Open issues:

• QoS for the middleware (e.g., how messages are delivered FIFO, random , etc.)
• Dependability vs Scalability
• Expresiveness vs Scalability
• Reflectiveness
• Context-awareness: context information to be used as notifications
  

Context Aware Middleware

Grounded Theory for the survery. The theory emerges from the interrelatons of general categories

Traditional Middleware: Hide heterogeneity and distribution

in Pervasive Computing this heterogeneity and distribution is dealt with in Middleware, without hiding them.

Types of Context

• Environment (infra-structure, vs, or self-contained)
  
• Storage (ordering data based on context information, vs, centralized storage facilities for storing
  
• Reflection (reification and absorption) (aapplication, middlware, context info)
  
• Quality
• Adaption (transparent, profile, rules)
  
• Migrationi (adaptive middleware systems)
  
• Composition

Aura
1. task oriented
2. task manager: managing tasks
3. environment manager: managing services
4. context observer: managing context (i.e., the intent of the user)

CARMEN:
1. proxies
2. proxy will migrate with the user

• resource move with the agent
• copy the resources when they agent migrates
• using remote reference
• re-binding to new resources

Resources have profiles

• user profiles: preferences, security, ...
  
• device profiles: hardware and software devices, ...
  
• service component profiles: interface for services
  
• site profiles: a group of profiles belonging to a single location

CARISMA
Profile: metadata of the middleware
1. passive profiles: actions the middleware should take when specific context events occur
2. active profiles: relations between services used by the application and the policies to deliver them

reflection is used to alter the profile kept by the middleware

Cooltown
Devices, People, and things are identified by a URL

• context (where, when, who, what, how)
• relationships (Contains, isContainedIn, isNextTo, isCarriedBy)

CORTEX
based on sentient objects: sense and views the behavior of neighbouring objects, reasons about it, and manipulates physical objects accordingly. They dynamically discover each other and share context information

• Publisher - Subscriber: discovery
  
• Group Communication
• Context
• QoS management

configured at deployment time, configured at run-time using Java Reflection

Gaia
a meta-operating system

• location
• context: collected by context providers
  
• event

Entities:

• application
  
• services
  
• device
  
• person

MiddleWhere
uses location providers

• location service
• spatial database
• reasoning engine

The model for location consists of (Points, Lines, Polygons)

Quality of location information (resolution, freshness, confidence)

MobiPADS
Mobilet is the entity that provides a service

• slave: resides on the server
  
• master: resides on the mobile device

context of mobile devices: 1. processing power, 2. memory, 3. storage, 4. network device, 5. battery

applications have access to reflective interfaces for context, service configurations, and adaption strategies

SOCAM: ontologies to model context

Context Provider: external or internal context
Context Interpreter: external context provider
Context Database: instance of the ontology of context
Context Reasoner: to derive more contextual information
Service Location Service: the registry for locating services of Context Providers
Context-aware Mobile Service: services that a context provider registers with the Service Location Service

rules are used to associate services with context information

Types of Context
Geographical Context
Physical Context
Social Context
Organisational Context
User Context
Action Context
Time Context

A survey of Adaptive Middleware

• Middleware is connectivity software that encapsulates a set of services residing above the network operating system layer

Taxonomy of Middleware (Emmerich)

• Transactional
• Message-oriented
• Object-oriented
• Procedural
  

Types of Object-oriented programming models

1. CORBA
2. RMI
3. DCOM

Supporting paradigms for adaptation include:

• Computational Reflection:
• Component-based design
• Aspect oriented programming
• Software design patterns

Computation Reflection:

• the ability of a program to reason about and alter its own behavior

- Reflective Systems (Base-level objects): functinal aspects of the syste
- Self representation (meta-level objects): implementation aspects of the system
- MOP (meta object protocol): an interface to inspect and modify the base level objects

*Behavioral reflection in middleware: modify the behavior of a program by generating code at the self representation level and injecting it to the base level

Component-based design:

components are self-contained
large scal reuse of components for COTS
late composition and late binding are supported

Examples: DCOM, EJB, Corba Component Model (CCM)

Aspect Oriented Programming

* intervened cross-cutting concerns in complex programs
* disentangling the cross cutting concerns leads to simpler software development, maintenance, and evolution

Software Design Patterns
The goal of software design patterns is to create a common vocabulary for communicating insight and experience about recurring problems and their known refined solutions

4.Taxonomy of Adaptive Middleware

1. Schmidt's classification:

• host infra-structure: higher level API than the OS, NP, generic services
  
• distributioin: RMI, solves heterogenity of NPs and OSs
  
• common services: common functionalities such as fault tolerance, security, load balancing, event propagaion, logging, persistence, ...
  
• domain services: specific class of distributed applications
  
• application

2. Adaptation type

• Customizable -> static compile time
• Configurable -> static, before starting the system
• Tunable-> dynamic, before using the system. The middleware core remains intact
  
• Mutable-> dynamic during run-time
  

3. Application Domain

• QoS
• Dependable
• Embedded

QoS-oriented middleware is classified to the following categories:

• Real-time middleware
• Stream-oriented middleware
• Reflection-oriented middleware
• Aspect-oriented middleware

Reflection

• Structural: ability of a system to inspect and modify its internal architecture (architecture and interface)
  
• Behavioral: ability of a system to inspect and modify its computation(interception and resources)

Existing Aproaches and middleware system

Ace

• Layer: Host-infrastructure
  
• Pattern: Service configurator pattern
• Type: repeatedly tunnable middleware

ACE ORB (TAO)

• Pattern: Strategy Design Pattern
• Type: configurable middleware - repeatedly tunnable middleware
  
• Layer: distribution

Component-Integrated ACE ORB (CIAO)

• Pattern: component based design
  
• Layer: distribution
• Type: configurable middleware

DynamicTAO

• Pattern: Service configurator
• Type: repeatedly tunnable middleware

OpenORB

• component based design

Squirrel

• Layer: distribution
• Type: Tunnable and Mutable - (not repeatedly tunnable tho! tunning happens just once)

MetaSockets

• Type: repeatedly tunnable middleware
• Layer: Host infra-structure layer

OpenCorba

• Type: repeatedly tunnable middleware
• Layer: Distribution

FlexiNet

• both fine-grained (per interface) and coarse grained adaptation
  

A Rendezvous of Content Adaptable Service and Product Line Modeling

Seo Jeong Lee1 and Soo Dong Kim2 -- PROFES 2005

They propose a service decision modeling technique for content adaptable applications

Michael Dertouzos [8] four fundamental forces envisioned in pervasive computing:
1- Natural Interaction
2- Automation
3- Individualized information access
4- Collaboration


Taxonomy of variability can be seen as below

The content adaptable service decision process

1. Define System Architecture
1. embrace contextual change
2. embrace ad hoc composition
3. recognize sharing as the default
   
2. Define the variation points and variants
1. Context is profile of network, device, user, service
2. for each of the above profiles we may think of a variation point
   
3. Define the dependencies between variation points
4. Define the dependencies between variants
5. Define the strategy of negotiation
1. It depends on the domain, service, and application
2. The decision value of the strategy should be one_of or in_the_range_of variant values.
6. Select the adequate algorithm or module
1. A QoS algorithm or something similar can be used to choose the require set of components and requirements based on the information that are fed to the system by the system designer.

Synergy between Software Product Line and Intelligent Mobile Middleware

Weishan Zhang and Klaus Marius Hanse 2007

current mobile middleware is designed based on "one-size-fits-all" paradigm lacking flexibility for optimization, customization, and adaptation.

They use the concepts of Frame-based techniques and its XVCL((XML based Variant Configuration Language) to define and configure points of variability.

[4] seems to be interesting to read in this paper.

They consider two major problems with the current mobile middleware applications:

1. Monolithic structure: Specialized optimization and customization might be required
2. Ontology evolution has not been addressed in the current ontology based middleware

They use service oriented architecture to connect different pieces of their services together. This actually imposes performance overhead to the system which may considerably degrade the execution and specification of their system.

• Configuration is done as early as possible
• Frame based ontology management and aggregation mechanism can run both on J2ME and J2SE
• Ontology evolution is more than the management of the ontology itself
• Flexible template capabilities for XVCL

They use racerpro as their main means of reasoning over the ontology.

Frame-based Ontology_Java Processing (FOJP)

• Bridging the OWL ontologies to Java classes by providing mappings
• Management and handling of ontology evolution
• Managing the update of agent definition, including the agent belief, goals, actions, and plans

A context ontology is devided into two parts, the parts that change more frequently and the parts that stay more or less the same for a longer period of time. Then XVCL commands are used in a meta-ontology to bridge these concepts and provide an aggregation of all these classes of ontologies.

Ontology evolution involves two phases

1. meta-ontology development
2. other meta-artifacts for the mobile middleware including the code components
   

Toward Wide Area Interaction with Ubiquitous Computing Environments

The overall idea: to unify abstractions exposed by existing ubicomp systems to provide a coarse gained interface for application interfacing.

Two impediments to wider deployment of ubicomp environment

1. supporting users and applications withing single administrative or user domains
2. lack of a shared model for ubiquitous computing

The considered model for the initial version of web service based middle ware:

• Environment Model
• Through service discovery
• Through a component that handles more complex models of the environment
• Related aspects
• Environment State
• Environment Meta-state
  
• Environment Implementation link: the set of software components
• Event sources
• Context sources
• Services
• Entity Handler
  
• Entities
• Context
• Values
• High level inferred context
• Services
• Entity relationships
• Events
• Data or content

Environment profiles: to provide semantic enrichment

• entities
• services
• context
• events
• content

--------------------
Thoughts:
The paper proposes a bottom up integration of services the functionalities of middlewares with the requirements of an environment. The object in an environment are classified as discussed and the relations between them are established. Based on the requirements of users, rules are defined in the form of Jena rules that can extract the concepts of integration from ontologies and identify what components can be used for what services. The ontology preserves the relationships between the entities, their contexts, and the components.

The reasoner then identifies the set of appropriate components that have to be composed in order to provide the right combination for the request of the environment to be processed.

The problem with their approach is that they have chosen a bottom up approach to bind the components to the concepts of user needs. This makes the whole design very much dependent to the way the composition has been defined in the ontology, thus in case a relationship between the components changes, the whole design will lose its validity and the whole ontology needs to be changed.

On the other hand, this doesn't provide any possibility for component reuse cause the design is bottom up which means the components drive the design as opposed to having the design driving the components. So, it is not possible for the modules to be reused, but instead the whole system can be replaces, making its scalability absolutely questionable.

furthermore, for each new system a new integration model should be defined and thus a whole rework at the level of system design also should be done. so this new architecture doesn't solve the problem of adaptability to the new domain, it just makes it uniquely possible for different systems in different domain to choose the same technology to connect to an environment. This is not the role of a broker tho, is it?