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

Dynamic Function Placement for Data-intensive Cluster Computing

Application partitioning is difficult because of :

• variation in application behavior
• variability in resource availability
• availability in workload mixes

Effective use of cluster resources require

1. load balancing
2. proper partitioning of functionality among producers and consumers

Function placement is done in abacus only based on black box monitoring removing the burden from the programmers to worry about function placement.

Abacus consists of a programming model and a runtime system. In the abacus programming model, the programmers need to define their components as explicitly migratable functionally independent components or objects.

Anchored elements need to be explicitly defined in the graph of the application. I think this is required because when it comes to modeling the grapho for the application, these components should be makred properly.

Abacus components:

1. Migration and Location Transparent Invocation Component (Binding Manager)
   
2. Resource Monitoring and Management Component (Resource Manager)

Resource Manager uses notifications to collect monitoring information (mointoring and profiling happens during runtime).

The best net benefit is calculated by the server in order to determine whether it is worth doing the migration (minimum requirements for doing the migration). Code Mobility and Dynamic Linking are sidestep in this model.

Mobile Objects are defined by the programmer.

Cluster characteristics critical for function placement:

• Communication bandwidth between nodes
• Relative processor speed among nodes
• Workload characteristics (e.g., bytes moved among functions, instructions executed by each function)

-> Data Intensive Applications: those that selectively filter, mine, sort, or otherwise manipulate large data sets. Spread the parallel computations across the source/sink servers.

Programmable Storage Services. is what they consider as a potential alternative to Cloud when it comes to naming.

Difference between Coign and Abacus is that Coign relies on the profiling history of functions / components to make decisions, while Abacus tries to do it at runtime.

Equanimity dynamically balances the load between a single client and its servers. Abacus extends it to real world clusters, i.e., resource contention, resource heterogeneity, workload variation.

Dynamic adaptation of resource placement based on resource usage and availability.

The two applications used in Abacus:

1. The file system
2. The search application
   

Goals for Abacus:

1. improve overall performance

Parameters measured:

• Data Flow Graph
• Memory Consumption
• Instructions Executed per Byte
• Stall Time

The Coign Automatic Distributed Partitioning System

The problem:

The need to partition and place pieces of applications on different nodes. Considering the effort, repartitioning is not done frequently because of the required effort even though repartitioning may buy a lot of efficiency for the application.

Application reprofiling is supported based on the periodical profiling of the application and calculating the optimal solution.

The architecture for Coign:

• The application is augmented with instrumentations for Coign using the binary re-writer.
• The instrumented binary is run through a set of profiling scenarios (degrading application performance. inter-component communications are summarized)
  
• The profile analysis engine combines component communication profiles and component location constraints to create an abstract inter-component communication graph (ICC).
• Location constraints are obtained from the programmer, from analysis of component communication records, and from application binaries.
  
• The ICC graph is combined with a network profile to create a graph of potential communication time on the network
• The graph cutting algorithm: lift-to-front minimum cut

The set of components for Coign Runtime:


Instance Classifier is probably the most important part of Coign Runtime. This is probably the most important part of the profiler as it tries to identify similarities between instances and extracted profiles. They have listed the following classifiers which need to be further investigated:

1. incremental classifier (Straw man classifier)
   
2. Procedure Called-By Classifier (PCB)
3. Static Type Classifier (ST)
   
4. Static Type Called-By Classifier (STCB)
5. Internal-function Called-By Classifier (IFCB)
6. Entry Point Called-By Classifier (EPCB)
7. Instantiated-By Classifier (IB)

The next step is correlating the profile of one instance with another instance based on similar resource usage and communication behavior. They have used instance communication vector.

The algorithm that it uses is the lift-to-front minimum cut graph cutting algorithm

Capacity Leasing in Cloud Systems using the OpenNebula Engine

Borja Sotomayor, Rubeen Santiago Montero, Ignacio Martero Llorente, and Ian Foster
http://www.cca08.org/papers/Paper20-Sotomayor.pdf

The problem: is advanced leasing.

• In the current models resources are allocated at the time of request.
• resource requests subject to notrivial policies are not supported
• capacity specification in advance is not supported
• no support for variable resource usage
• dynamic renegotiation of resource allocation is not possible
• small cloud systems can benefit from queuing, priorities and advanced reservation

Approach: OpenNebula + Haiza

OpenNebula:

1. Core: Manages the lifecycle of a VM + management and monitoring of the physical host
   
2. Capacity Manager: Adjusts placement of VMs
   
3. pluggable Virtualizer Access Driver: expose the basic functionality of the hypervisor

Hiza is a lease manager:

1. leases in Haiza, hardware resource, software environment, and availability
2. Supports
3. advance reservation lease: request for resource at a specific time
   
4. best effort leases: resources are assigned as soon as possible, queuing resources if necessary
   
5. immediate leases: provisioned when requested or not at all
   

Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities

Comparing some cloud services:

QCon SF 2009: Simon Guest, Patterns of Cloud Computing

QCon SF 2009: Simon Guest, Patterns of Cloud Computing
By Stefan Tilkov on November 19, 2009 2:38 PM | Permalink | Comments (0)

Similar Post: http://horicky.blogspot.com/2009/11/cloud-computing-patterns.html

These are my unedited notes from Simon Guest's talk about Patterns for Cloud Computing at QCon SF 2009.

* "This talk is about Jim, he has many questions about cloud computing…"
* 5 pattern of cloud-based applications
* Definition of cloud computing
* Different models:
o Applications must run on-premises – complete control, upfront capital costs
o Application runs at a hoster – lower capital costs, but pay for fixed capacity even if idle
o Shared, multi-tenant, pay as you go – pay someone for a pool of computing resources that can be applied to a set of applications
* Public Cloud vs. Private Cloud – private cloud useful e.g. for telcos offering this to their customers
* Windows Azure – compute, storage, management, based on 64bit Windows images
* SQL Azure - RDBMS
* .NET Service - service bus and access control
* [ed.: Who thinks of these names, and even more importantly, why doesn't Microsoft fire them?]
* Different models infrastructure (IaaS) vs. Platform as a Service (PaaS) as main paths
* Slide shows that MS offers a higher-level stack than Amazon - EC2 provides instance, Windows Azure model is a platform as a service model
* [Seems to me this is one of the major problems of Azure – it seems neither one or the other, as I would define PaaS as what GAE does, which is much higher-level than simply a Windows Server]

Pattern #1: Using the Cloud for Scale

* Shows how to scale up a Web app using more machines, load balancer, database partitioning
* A lot of work - a lot of money
* Designed for peak capacity, idle for a lot of time
* Much easier to let cloud vendor handle this dynamically
* Prerequisite for successful scaling in the cloud: having a queue to decouple web tier and backend
* Starbucks [of all possible examples! ;-)] as an example for queueing
* Demo: "PrimeSolvr" (Web 2.0 because it's missing the last "e")
* 3 takeaways: 1) core tenet of cloud computing: ability to scale up/down 2) understand how to communicate between roles and nodes 3) strategy for when to scale up and down

Pattern #2: Using the cloud for multi tenancy

* Simply approach internally: one application per customer - works only for small numbers
* Implications: Schema customizations, UI customizations
* 3 options for data in a multi-tenant environment: 1) share DB between customers 2) each customer gets a separate DB - hard to do on-premise, much easier in the cloud 3) fixed DB schema with customizations on a tenant-by-tenant basis
* Demo: ASP.NET MVC app using the HTTP host name to switch UI and DB Schema
* Takeaways: 1) Consider multi-tenancy first, hard to retrofit 2) Design considerations must include both data and UI specifics 3) Identity as a very important consideration, see MS Patterns and Practices paper on multi-tenancy ID

Pattern #3: Using the cloud for compute

* Popularized by MapReduce
* Apache Hadoop, Cloudera, Amazon Elastic MapReduce, Hadoop implementation
* Typical on-premise solution: very infrastructure-heavy, complex, expensive
* No explicit framework implementation on Azure
* Demo (inspired my MapReduce): Development Fabric (local execution environment), not using virtualization [similar to GAE environment]; next step is upload to Azure staging area, next level production
* Takeaways: MapReduce very visible, although can be hard to initally grasp, learn about existing implementations; MS academic effort: Dryad

Pattern #4: Using the cloud for (infinite) storage

* Problem: Affinity between hardware and data
* how does the cloud help? breaks the affinity
* virtualized layer between the data you store and the hardware underneath
* Three ways: blobs, tables, relational
* MS: Azure Blog Storage – REST API (using GET (even range requests) and PUT); PutBlock API to move blocks - transaction build up [must look this up]
* Azure Table Storage (Key/Value pairs)
* Initial relational effort: SQL Server Data Services (MIX 08) - REST API on top of SQL
* Customer reaction: We want to do TDS (MS native DB protocol)
* SQL Data Services (MIX 09), late SQL Azure: TDS (SQL Server) in the Cloud
* Similarity between internal and cloud architecture makes it easier for customers [agreed, even though this might me more of a problem]
* Demo: SQL Azure (http://sql.azure.com); Codeplex sqlazuremw (migration wizard) - migration from local SQL Server DB to the cloud (subset of SQL Server functionality, e.g. restrictions on certain value types, clustered indexes)
* Takeaways: 1) Storage in the cloud may look the same, but breaks the affinity problem 2) Pricing is relevant 3) SQL Azure factor for moving to cloud in the first place=
*

Pattern #5: Using the cloud for communications

* Classic approach: VAN, now replace by Internet direct file transfers
* Cloud approach: REST-based queues could be used for communication - not commonly used, problem: need to pass tokens around
* Putting a web facade in front of the queue doesn't work too well either due to firewall problems. HTTP polling is bad [why?]
* MS Solution: .NET Service Bus
* TCP Relay: outbound bi-directional socket, tunneled through the bus and kept alive on both sides. Enables routing of arbitrary protocols across company boundaries
* Alternative: Message Buffer, exposed using AtomPub, support retrieve, peek, lock
* Takeaways: Be careful consuming REST-based queues because of shared secret
* additional trouble because of REST
* service bus as potential solution

Last question: How can patterns be integrated?

* 1) Sample PHP (!) application running on Windows Azure, ported to GAE and EC2 (as ASP.NET)
* 2) Map reduce spreads load across Amazon, Google, MS
* 3) Store results in SQL Azure database
*

4) Coordinate communication using .NET Service Bus
*

How many prime numbers between 1 and 10,000,000? 40 jobs of 250,000 numbers
* WPF client app sends off job
* "I'm gonna submnit the job and pray"
*

Spontaneous applause as the demo actually worked
*

make sure you have a clear definition of cloud computing
* explore the 5 usage patterns
* think about the next steps for implementation and migration

Context-Aware Service Composition in Pervasive Computing Environments

Sonia Ben Mokhtar, Damien Fournier, Nikolaos Georgantas, and Val´erie Issarny

http://www.springerlink.com.proxy.lib.sfu.ca/content/38252l8676501424/fulltext.pdf

The paper presents a context-aware service composition based on workflow integration.

Context-awareness is a property of a system that uses context to provide relevant information and or services to the user where relevant depends on user's task

They use ontologies to define context and then use this information to validate context.

They want to enable the user to perform a task anywhere and any time. Networked services are described in OWL-S extended with context information -> prec0nditions & effects + context attributes.

Context-aware service composition is done in two steps:

1. context aware service discovery provides a set of services that are candidate to composition
2. context-aware process integration provides a set of composition schemes that conform to the task behavior

Matching and discovery of services is done based on the algorithm proposed by palucci in matching the inputs and outputs of user tasks and processes with the inputs and outputs of advertised services. what is important is the fact that there can be subsumption relationship between the advertised and the required services.

During the integration process, contextual preconditions and effects of service operations have to be taken into account, and second, global task's contextual requirements have to be checked.

Filtering of components happens based on the following criteria:

1. Starting from the actual state of the path, the task's following symbols can not be reached in the global automation
2. The simulated context does not fulfill the contextual preconditions of the incoming operations.
3. some attributes of the simulated context do not meet the global contextual requirements of the user task.
   

A Tale of Clouds: Paradigm Comparisons and Some Thoughts on Research Issues

Lijun Mei, W.K. Chan, T.H. Tse

http://ieeexplore.ieee.org.proxy.lib.sfu.ca/stamp/stamp.jsp?tp=&arnumber=4780718&isnumber=4780615

Preliminaries

Cloud Computing

• Horizontal Cloud Scalability: connect and integrate multiple clouds to work together as one logical cloud
• Vertical Cloud Scalability: improve the capacity of a cloud by enhancing the individual nodes in the cloud

Basically the above concepts talk about scalability in depth and scalability in breadth

Service Computing

• to create a service composition, engineers may use specifications such as WSBPEL
• to carry out workflows, webservices or other types of services might be used

Pervasive Computing

• embedded in constantly changing computing environments
• a well developed environment will enable the pervasive software to work eveywhere without extra effort
• Environmental features are used to understand and react to the users. These environmental variables are referred to as context and are collected using different sensors and information in the environment

Comparing Cloud with Pervasive and Service Computing

• Service Computing is good in providing functionality and providing flexible services
• Pervasive Computing enables users to use software everywhere and provides slef adaptivity with respect to the environmental contexts

Cloud computing needs both functionality modeling and context sensitivity.

In terms of IO Cloud Computing is closer to Service Computing
In terms of storage, Cloud Computing seems to be closer to Pervasive Computing

Comparison of IO for cloud, service, and pervasive computing


Comparison of storage for cloud, service, and pervasive computing
Comparison of calculation features for cloud, service, and pervasive computing

How do computing entities plug into the system?

• service computing: registration and discovery of srvices
• pervasive computing: mobile computing entities join and leave the environment
• cloud computing: Applications can be entity aware to plugin heterogeneous computing entities. New computing entities can be added or should be added to the system dynamically and on the fly.

How do computing clouds store and access large-scale data?

• Pervasive computing: mobile entities store their data in the environment
• Service computing: usually the amount of data stored is negligible and services are more often stateless services which do the calculation but do not deal with storing information
• Cloud Computing: there is finite amount of space for storage on the cloud too, so cloud systems may need to share data or may need to provide some sort of inter-cloud communication in order to scale better and transfer some of the data to other clouds

How does a computing cloud become adaptive to both internal and external changes?

• Service computing: environmental changes, evolving quality of services,
  
• Pervasive computing: quality of mobile entities involved
• Cloud computing:
  
• How does the environment change for a cloud?
  

An Architecture for Non Functional Properties Management in Distributed Computing

[[ CHECK REFERENCES ]]

Pierre de Leuss1, Panos Periorellis1, Theo Dimitrakos2 and Paul Watson1

http://www.cs.ncl.ac.uk/publications/inproceedings/papers/1149.pdf

Three categories for Grid

1. computational grid
2. data grid
3. service grid: instead of providing computational or data resources enables sharing of specific functions defined and exposed as services

Cloud Computing: Resources come from the cloud, a public network, rather than a specific identifiable system.

The rational behind cloud computing:

• the underlying complexity of the system and their characteristics should not only be hidden from the underlying users but for the most part to the technical users as well. Amazon Simple Storage Service (SimpleDB) is a webserivce providing storage capabilities.
• It is not only about computation and data
  

Potential Research challenges

• adaptability in response to changes in the nonfunctional requirements of the system
  
• From changes in internals of components to external changes
• Reaction on Message interceptions received by the infrastructure
• Safety and Security of the profiles

Interesting points

• nonfunctional properties management
• rapid adaptation
• dynamic composition
• distributed system integration

IBM's perspective on autonomic computing

• Self-configuration: adapts automatically to dynamically changing environments
  
• Self-healing: system discovers, diagnose, and reacts to disruptions
  
• Self-optimizing: systems monitor and tune systems automatically
• Self-protecting: systems anticipate, detect, indentify and protect themselves.
  

Cloud Computing – Issues, Research and Implementations

Mladen A. Vouk
Department of Computer Science, North Carolina State University, Raleigh, North Carolina, USA

http://loveni.name/clover/Cloud%20Computing%20-%20Issues,%20Research%20and%20Implementations.pdf

In the context of cloud computing the key question should be whether the underlying infrastructure is supportive of the workflow oriented view of the world.

Characteristics of a cloud environment

• support large number of users ranging from very naive to very sophisticated
• support construction and delivery of curricula for these users
• generate adequate content diversity, quality, and range
• be reliable and cost-effective to operate and maintain

In the context of the VCL technology an image is a tangible abstraction of the software stack.

Service Composition and Provisioning

• sample and combine existing services and images
• create new composites, update them, etc.
• workflow aggregation and automation

Cloud computing research issues

• image and service construction
• Cloud provenance data (process, data, workflow, system or environment)
• optimization
• image portability
• security
• utilization
  

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
   

Composing REST services and collaborative workflows

Bite offers a language for composing REST services.

REST composition enables some sort of data flow composition model (similar to Yahoo Pipes)

Human interactions happen by forms, instant messaging, linked email exchange, etc.

Collaborative services such as Lotus support unstructured interactions between ad-hoc communities linked via common business goals. Complex collaborative applications.

Design Goals for Bite

• Atom life-cycle
• Lightweight process model
• Scripting Approach
• Language extensibility
• Web and human integration

It allows for extensibility of the language and it supports parsing the scripts for the languages. also GUI elements can be easily connected to the bite script and their states can get updated by sending reploes to their interfaces.

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

a multi-agent system for the reliable execution of automaticall composed ad-hoc processes

http://www.springerlink.com/content/q7684735gl420772/

Scenario

• the user states his pereference > comedy movie, restaurant with french cuisine
• ad hoc composition is required when the user is roaming
• location based composition for nomadic users

Approach

Components AND Services: a marriage of reason

http://www.i3s.unice.fr/~mh/RR/2007/RR-07.17-P.COLLET.pdf

The article provides a comparative study and positioning of components and services with the overall objective of arguing that the two approaches can be seen as much more complementary than competitors.

components

• black, white, grey boxes
• arbitrary granularity
• state
• reflection
• composition
• structural composition: binding between components needs to be controlled. or the connections between components and sub-components.

services in SOA

• black bozes
• coarse granularity
• loose coupling
• statelessness
• discovery
• orchestration

CBSE is more favored in middleware and embedded systems which exhibit strong NF constraints

SOA is typically preferred in e-business applications which necessitate to chain calls to online services provided by distinct companies.

Applicatoin to Dynamic Communities System

Amui is a messaging server for dynamically and automatically grouping users according to their common interests. the users are filtered based on their topics of interests and are redirected to chat rooms associated to user defined set of keywords. Users will receive ads and can also include some plugin-like applications to carry more content to the users, e.g., videos, etc.

Amui Server is composed of three subcomponents:

• AmiFacade
• The Core
• manage users
• manage groups: group creation/administration
  
• match user keywords to group topics (UGManager) : implements the main functionality
  
• Advertisement Proxy

Fractal WS is a toolkit to make compatible any Fractal component with the technology of Web Services. It uses generative programming and statically typed stubs are generated.

Fractal SCAproposes bidirectional bridge between Fractal and the SCA. From Fractal to SCA components are enhanced so that they are able to create SOAP bindings. On the other hand, SOAP communication service is provided to handle communications from SCA to Fractal.

Enhancing Residential Gateways: OSGi Service Composition

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4140904

Scenario

Home Security Service:

Fire

• ringing alarm
• unlocks the doors
• calls the fire station
• informs John using the most appropriate device

Intrusion

• locks the doors
• calls the police
• informs John

They propose a BPEL like description for providing a composition contract where a virtual bundle gets loaded to the OSGi ServiceRegistry with the BPEL specification for the service, registers itself with the BPEL engine and enables the engine to use the loaded BPEL. The BPEL is then used by the system to do an orchestration of services in the OSGi ServiceRegistry.

OWL-OS/OSGi is used as a semantically enabled OSGi framework in order to provide semantic enhancements to OSGi. The partner link is expanded with some more elements to incorporate semantic information for the partners providing the desired methods or porttypes.

Dynamic Service Composition using Semantic Information

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

Static Service Composition (proactive)

• workflow or state chart is designed to describe the interaction pattern
• BPEL, WSCI
  

Dynamic Service Composition (reactive)

• autonomous application composition
• eFlow[4], SWORD[13]
• dynamic service composition is useful for ubiquitous and end user applications

Scenaio

1. get address for restaurant and home
2. invoke the direction generator web service
3. print out the result image

four domains are introduced

1. data types
2. semantics (Concept)
3. logics
4. components

Comparing CoSMoS with SCA

• data types in CoSMoS are equivalent to DSO in SCA
• semantics are not supported in SCA
• logics is somewhat meaningless for CoSMoS
• components have equivalents in SCA
• composites are not defined in CoSMoS

CoSMoS is a new component model CoRE converts the metadata for the discovered components into CoSMoS and CORE has a pluggable architecture.

Semantic Graph Based Service Composition (SeGSec)

Request Analyzer <-> ServiceComposer <-> Reasoner <-> ServicePerformer

"ServiceComposer genrates the execution path by connecting operations of components", How?? This is not something trivial. Matching the operations for different interfaces for services is quite difficult. I am not sure how it is done. How do they perform this matching of operations at the high level? Reasoning and semantic resolution should be performed before the ServiceComposer module generates the path.

for other systems, there should be a template implementing the requested service. so a B2B template matching is required in this case.