Wishbone: Profile-based Partitioning for Sensornet Applications

Two major problems with application partitioning:

• Heterogeneity
• Decomposition

The requirements for wishbone applications

1. Streaming dataflow model: the model should be a dataflow graph
   
2. Predictable input rates and patterns: because they use profiling they need to set this constraint

The front-end creates a dataflow graph. The backend performs graph optimization and reduces work functions to an intermediate language that can be fed to a number of code generators.

namespace is used to logically define the distribution of the code, i.e., the code that can be distributed, not the code that necessarily needs to be distributed.

if the code to be placed (logically) in a node is stateful, the state of the stateful operators should be replicated on the node too.

Stateful server oprators can not be moved to the network, however, stateful node operators can be brought to the server.

The system considers two modes of conservative and permissive where in the conservative mode the stateful nodes are not pushed to the server but in the permissive mode, the stateful operators can be pushed to the server, in case the application is capable of dealing with data loss.

For dataflow, the Scheme compiler executes the code during the compilation to measure the data flow, producing platform independent data rates.

Once partitoned, the partition is executed within simulated or real hardware to measure the cpu foot print for the partition. Timing statements are placed at the beginning and end of each operation. The timestamp can help with extracting the memory footprint for each piece of the code.

Cost is measured using Cost = aC + bNet

The ILP algorithm used is minimum cost cut for partitioning the graph

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
   

Semantic-based Contxt-aware Dynamic Service Composition

http://portal.acm.org/citation.cfm?id=1516533.1516536

Contributions

1. Not only system designers but also end users to specify rules on how to compose context-aware applications
2. It supports both rule-based and learning-based context-aware service composition
3. It utilizes semantic similarities among components to improve its adaptability in a dynamic environment
4. supports seamless service migration which autonomously composes a new application and migrates onto it when user context changes
   

Componetn Service Model with Semantics (CoSMoS)

There is a UML meta model for CoSMoS wichi helps with Defining

• Functional Informaiton
• Semantic Information
  
• Contextual Information
• User specific rules

Component Runtime Environment

CoRE consists of the following pieces

• Dscovery Manager
• Execution Manager
• User Manager

Three methods for context acquisition

1. metadata of the components: context information is embedded in the components metadata
   
2. context-aware discovery or user submodule: acquiring context information through existing context aware technologies
   
3. inference: infer context based on a set of facts

Semantic Graph-based Service Composition (SeGSeC)

two approaches are used

1. Rule-based
2. Learning-based

Problem in creating the workflow is that, semantic correctness of the workflow gets checked at the end of its execution, wherease it can be included in the process of execution so that the semantically valid components get discovered first before actually having to deal with the composition and orchestration of components

The learning algorithm for selecting a component
Pi = max (SSi,j x (CMDj + const)) 1 <= j <= n SS i,j = semantic similarity between two components CMDj = context matching degree. (how well the component matches the context it is used in based on the previous experiments in using this component in this context). To decide about context matching conditioins a C4.5 DT algorithm is used collecting information about a composed workflow. context aware dynamic service composition systems have problems for the following reasons:

1. predefined rules usually cannot be modified once they are deployed
2. it is difficult to define a generic rule that is applicable to every user
   
3. some users preferences may be too complex to define as a set of rules

interesting evaluations for dynamic composition of context-aware services. I skipped the experiments but they might be worth reading.

Combining Quality of Service and Social Information for Ranking Services

Qinyi Wu, Arun Iyengar, Revathi Subramanian, Isabelle Rouvellou, Ignacio Silva-Lepe, Thomas Mikalsen
http://www.research.ibm.com/people/i/iyengar/ICSOC2009.pdf

FROM BEFORE

The authors propose ServiceRank as a method to rank services based on the opinion of those using a service as well as local behavior of services, mainly response time and response failure.

Problems:

1. what is the proper answer response from a service? Does it have to match a value expected by the client or can it be just any response? How does the client know of the proper value for a computation prior to using a service? Does it then require to have knowledge about the service?
   
2. How does data from all services is collected? is there a single repository where the services publish the results their experiments with the services?

ServiceRank as a ranking algorithm to bring opinion of the community about using a service into consideration when deciding on the quality of service

Problems:

1. It is not clear how requesting services decide about the correctness of the returned data? is a response rated as correct when only a response is received, or when the correct response is returned. In the first case, how would the service be guaranteed as the proper service, and in the second case how are we going to know what is the returned value for the request?
2. How the cumulative data about the experience of other services gets collected? There are monitoring services that keep the record of all services. There are going to be multiple monitor services associated with the applications connected to the SOAlive. This is not a real case for the real world applications.
   

The paper also contains a set of experiments to demonstrate how a composition can be affected by quality of service and how the cumulative study for service composition.

The approach can be used as a method to provide cumulative study on service composition within a composition chain.

Evolving Services from a Contractual Perspective

Vasilios Andrikopoulos, Tilburg University, Netherlands
Salima Benbernou, University Lyon1, France
Mike Papazoglou, Tilburg University, Netherlands
http://infolab.uvt.nl/pub/andrikopoulosv-2009-124.pdf

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

two views are introduced

exposition vs expectation
required vs provided

A contract records the benefits and the obligations
the contract describes what is the acceptable results and contributions for a task described

The client formulates the contract, instructing the provider on what functionalities are going to be used.

Shallow Changes are divided into two categories

• contractual invariance changes: a simple mediation would do the trick
  
• contractual evolving changes: changes that require revisiting the contract but do not require changes in the other party