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

Appplication Data Srevices: Making Steps Towards an Appliance Computing World

Andrew Huang, Benjamin Ling, John Barton, Armando Fox

The paper introduces to main dilemmas in using devides

1. They are more complex
2. There are too many features

The vision of the paper: "An appliance computing world is one in which people move data effortlessly among artifacts to accomplish a variety of tasks"

The paper introduces a set of princtiples and attributes for any ADS system

• At1: People move data using concrete syntax. Like "Post the picture to my wall"
• P1: Bring devices to the forefront: computers and devices are invisible into the physical infrastructure (Mark Weiser's vision)
  
• A2: Devices are simple, single purpose appliances: This is not true cause the users have shown acceptance of devices with more complex capabilities. For example turning cellphones to cameras is not something being rejected by the users
• P2: Keep the number of user controllable features on devices to a minimum: This should be correct as it provides better manipulation and control over the device. It should provide simpler user interfaces as well. It shouldn't be too complicated or anything at the end for the user to be used.
• A3: People perform a variety of traditional tasks, as well as a new set of advanced tasks with their devices. The functionality to perform highlevel tasks can be placed on users' PCs but be kept hidden from the user.
• P3: Place the software required to accomplish tasks in the network infrastructure
  

Their implementation of the ADS system sends request as tuples (userid, command-tag, data) with userid and command-tag used for the following purposes:

• Application Selection
• Access Control
• Other service features

They have three parts to the architecture

1. Data Receive Stage
1. Role: Deals with device heterogenity
2. It handles all the device connection requirements but is very poor for scalability. It becomes a single point of failure for the system as well.
   
3. It relies on a stateless Access Point (What is stateless I don't really know) amd am aggregator enables extensibility of the Access point by adding new device features
4. Aggregator is actually the point of conflict as at that point all the integration between all the access points and the required input data for the application control phase happens.
   
2. Application Control Stage
1. The data is collected to create a chain of components that satisfy the application. It is not clear how this set of data is monitored to satisfy the requirement of the applications and components and how others should be aware of these requirements when developing components.
2. Command Canonicalizer
1. Allows having simple user interfaces
3. Template Database
1. Minimizing device configuration
4. Dataflow Manager
1. Coordinates data input bu the user: How this required data is specified?
   
3. Service Execution