Mediation and Enterprise Service Bus A position paper

ESB tries to isolate the coupling between the service called and the transport medium.

ESB brings flow-related concepts such as transformation and routing to SOA. Flexibility in the transformation layer + easy connection between services.

ESB requires to provide the following characteristics:
invocation, routing, mediation, messaging, process choreography, service orchestration, complex event processing, QoS, management.

----
Paper

ESB is a mediation solution: early mediation solutions evolved to enhance the gloabl quality of services provided by large scope of DB systems. ESB uses mediation to facilitate the design of applications based on Web Services.

Wiederhold in [8, 9], mediation is "a layer of intelligent middleware services in information systems, linking data resources and application programs".

a mediator as "software module that exploits encoded knowledge about certain sets or subsets of data to create information for a higher layer of applications. It should be small and simple, so that it can be maintained by one expert or, at most, a small and coherent group of experts"

types of mediators:

• examiners -> content body for validation, authentication, etc.
  
• transformation mediators -> content body for data type transformation
  
• transcoder mediators -> modify the format and not the content. helps to go through different protocols
  
• cache mediators
  
• routers
• operator mediators -> comparators, aggregators, etc.
  
• clone mediators -> dispatch a unique request to several services

ESB is more than a mediator. It also provides

• a trading service in order to find services
• commuication service (mostly synchronous with MOM and pub/sub)
• orchestration service (based on BPEL)

Mediation in ESB includes

• Security
• Dynamic Routing and dispatch of requests (load balancing, responding to data source failure)
  
• other non-functional actions related to QoS management -> quality measurement, tracing, caching, failure detection, recovery.

Apache Synapse -> mediation for web services

Open-source ESBs

• Celtix
• Petals
• Objectweb
• Mule
• ServiceMix
• OpenESB

Java Enterprise Service Bus API (JBI) doesnt closely deal with mediation but provides standardization on exchanges between services.

with workflow languages we can model the our application but we cant serparate the proxies from the application model. as a consequence any change in the implementation will aslo affect the model and vice versa, even though in many situations it is not desirable.
Looking at the picture above, the question is whether an event processing engine handles the process of mediation and to what extent?

designing a mediation element should be kept separate from composing a mediation element.

Mediation tool development is used. This tool allows to

• describe mediation chains with ADL
• describe the execution environment
• automate the deployment and administration

This is a very interesting image as it is very close to things that we have in mind with mediation and enabling composition of services through mediators.

ESB combined with a pub/sub middleware seems to be the way to go towards this direction. In this sense mediator is a component that is able to receive 1 to n pieces of data and send 1 to n pieces of data. it can be seen as a binding between clients (1..n) and services (1..n).

A mediation chain is close to the concept of partnerlink in BPEL.

OSGi can help ESB with improving dynamism. so mediators can be defined and implemented as OSGi bundles to be dynamically loaded to the ESB infrastructure to enable communication between services of different types.

** 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
  

A taxonomy of quality of service aware adaptive event dissemination middleware

This paper has to be read later in more details. It provides an overview of EBMs and the set of QoS requirements that they need to admit to.

Probelm that paper tries to address:

few middleware options provide support for nonfunctional service guarantees. There is a lack of comprehensive survey that analyzes all the EDMs providing support for QoS.

some of the QoS requirements for the EBM or EDM

• security
• load balancing
• reliability
• fault tolerance
• ordering
• semantics delivery

The event model has three message types

• advertisement
• notification
• subscription

There are two types to composite events

• temporal: time dependencies between primitive events.
  
• spatial: conjunctive/disjunctive combination of individual events
  

michlmayr 2008 - two papers

1. publish/subscribe in the VRESCO SOA Runtime

The overall architecture for VRESCO looks very similar to a combination of ReCoIn and OSGiBroker. Client Programs make a call to the system using DAIOS and the client library. VRESCO runtime provides support for publishing/subscribing/querying/notification using the engines that VRESCO offers.

Also, persistence is supported for storing events into the DataBase and for querying a history of events, etc.

Below is a snapshot for VRESCO event architecture, which is again very close to the Event architecture that OSGiBroker offers
VRESCO makes use of ESPER event processing engine in order to enable filtering of events and managing events when it comes to their collection and aggregation to infer some meanings from the published events.

Listeners are Esper EQL commands that request for a specific type of event to be delivered to the subscriber registered with the event processing engine.

Persistence is supported in their VRESCO pub/sub system by using NHibernate engine which persists all the events. The events history can then be queried for specific set of exchanged events.


2. Advanced Event Processing and Notifications in Service Runtime Environments

VRESCO supports the following set of events

• Binding and Invocation Events
• Query information events
• user information events

They consider two types of external consumers

1. human
2. services
3. WS-Eventing
4. WS-Notification

Even Ranking

• Priority-based
• Hierarchical
• root events have higher importance compared to leaf events
• Type-based
• Content-based (the keyword exception is more important than warning)
  
• Probability-based (frequent events are less important than infrequent events)
  
• Event Patterns
  

Event-correlations are used to avoid losing track of events and their relationships. something like an event identifier can be used to correlate events to one another.
I think event correlation can be done either by scanning the content for events or by looking into channels and separating events based on the channels they get published to.

Correlation sets enable users to track all relevant events for a correlation ID without losing the track of what is happening between these correlation sets.

VRESCO Web service Eventing specifies 5 different operations

• subscribe
• unsubscribe
• renew
• expires
• subscription ends

important: due to the large set of published events, relational databases are not always preferrable as a more efficient indexing strategy is required. Vector space engine as described in [17] might be a better choice. The advantage is that the search returns a list of fuzzy matches together with a similarity rating.

Throughput for different methods of publishing events can be measured. Also, since we are using caching, it is easier to see how throughput affects the overall behavior of the system. As for events, we can also store all the events in the DB and query the DB only in situations needed. This decreases the chance of having low preformance as a result of dealing with the relational DB.

Their related work is very interesting and important. It is a MUST READ set of papers.

Henssen 2008 - QoS attributes

Capturing and Using QoS Relationships to Improve Service Selection

Promotes the use of MCDA (multi-criteria decision Analysis

• important to analyze weights related to criteria + weights related to interactions between criteria
  
• 
  

Dealing with Quality Tradeoffs during Service Selection

aggregation approaches for integrating weights into the service selection procedure for a QoS:

1. compensatory [29][30]: they amount to being substitution rates. The priorities for different criteria to be expressed on the same scale
   
2. noncompensatory [4, 8, 21, 31]: weights are simply a measure of relative importance of the criteria involved. They are only used to indicate the relative importance
   

Promotes the use of outranking methods for defining global priority constraints

outranking relation is a binary relation S on the set of potential choices A such that aiSaj to decide that ai is at least as good as aj.

Pj(a, b) = Fj[dj(a, b)] for all a, b
dj(a, b) = gj(a) - gj(b)

where gj(a) is the score of service a over quality of service a

There are six categories of functions for F

1. immediate preference
2. indifference threshold
3. increases continuously until reaching the indifference threshold
4. comprises an indifference and a preference threshold
5. increases continuously between an indifference and a preference threshold
6. Gaussian law with a fixed standard deviation

• aggregating the preferences
• wj is the preference for characteristic j
  

• outranking flows
• The positive outranking flow expresses how an alternative a is outrankking all the others (n-1 alternatives)
  
• The negative outranking flow indicates how an alternative a is outranked by other n-1 alternatives

complete ranking of PROMETHEE method is derived using the following formula

The paper is clumsy when it comes to their real experiment. values are drawn from no where and it is not clear how these values are calculated. The author needs prior knowledge and there is a lack of proper description

Monitoring the QoS for Web services

QoS metrics

• Provider-advertised (execution price)
  
• Consumer-rated (service reputation)
  
• Observable
• IT Level
• Business Level

The QoS value needs to be recomputed whenever the execution of a service instance is computed

observational model

• service monitoring architecture
• QoS metric computation
• high volume of service operational events
• complexity of metric computation
• metric value persistence

computing/updating metric values in realtime using a high performance metric computation engine

contributions of the paper:

• monitoring-enabled SOA infrastructure
• declarative event detection
• event routing
  
• mointoring QoS with small programming efforts
• Efficient QoS computation
• compilation interpretation approach
• improve event processing throughput
• custom executable ECA rule at buil time
• observatoin model is transformed to invoke generated code
• model driven planning to enable wait free concurrent threading

QoS is a broad concept encompassing a large number of context-dependent and domain-specific nonfunctional properties.

1. Process Monitor Context
2. Service Mointor Context (Service Interface Monitor Context)
   
3. QoS metrics

Event (eventPattern)[condition]|expression

• eventPattern = service operational event / change in the metric
• condition = circumstance to fire an event
• expression = association predicate + value assignment
  

Metric computation engine takes observation models as input and generates event subscriptions for the semantic pub/sub engine. Thus, the events from one service engine are delivered to another service engine.

High Performance Metric Computation for QoS Metrics

ECA rules are mapped to a state chart with the transitions from events to metrics or metrics to metrics.

There are two parts to execution of state charts.

• Interpretation of state chart logic
• Interpretation of the expressions within the states
• Thread scheduling for executing events
  

Examples of Mashups

IBM's QED Wiki
Yahoo Pipes
Google Mashup Editor
Microsoft's Popfly

Semantics identified by Web services community

• data (I/O)
• functional (behavioral)
• nonfunctional (QoS, policy)
• execution (runtime, infrastructure, exceptions)

Semantic Annocation of Web Services

• hREST
• SA-REST

Mashups available on the Web

• ProgrammableWeb
• APIHut

A Model for Web services Discovery with QoS

Ran, S. 2003. A model for web services discovery with QoS. SIGecom Exch. 4, 1 (Mar. 2003), 1-10. DOI= http://doi.acm.org.proxy.lib.sfu.ca/10.1145/844357.844360


Service Supplier -> provides Certifier with QoS information -> Certifier either accepts or downgrades the information -> returns the result back to the supplier -> supplier registers the service (the functional descriptions + the certified QoS) + UDDI checks with certifier the QoS.

Web services are provided by third parties and are invoked dynamicall over the intenet and thus their QoS can vary greatly.

A framework is need to capture QoS provided by supplier and QoS required by customer and try to provide a match between the two.

ISO 8402 Description for Quality: the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.

QoS: a set of non-functional attributes that may impact the quality of the service offered by a
Web service

Categories for QoS

1. Runtime related quality of service

• Scalability (related to throughput and performance)
  
• Capacity (concurrent requests)
• Performance ( speed in completing a service request)
• Response time
• Latency
• Throughput (number of completed service requests over a time period)
• Reliability
• Mean Time between Failuers
• Mean Time to Failure
• Mean Time To Transion
• Availability
• Robustness / Flexibility
• Exception Handling
• Accuracy

2. Transaction Support

• Integrity ACID ->
  
• Atomicity -> entirely executes or not at all
• Consistency -> maintains integrity
  
• Isolation -> runs as if no other transactions are present
  
• Durability -> the results are persistent

3. Configuration Management and Cost Related

• Regularity ( how well the service is aligned with the regulations)
  
• Supported Standard (if the service complies with standards)
  
• Stability / Change Cycle (frequency of change in the service in terms of interface)
  
• Cost ( the cost for using the service)
  
• Completeness (the difference between the specified set of features and the implemented set of features)

4. Security related QoS

• Authentication
• Authorization
• Confidentiality
• Accountability
• Traceability + Auditability
• Data Encryption
• Non-repudiation (A Principal can not deny requesting the service after the fact)
  

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
   

Supporting Pluggable Configuration Algorithms in PCOM

Marcus Hadnte, Klaus Herrmann, Gregor Shiele, Chrisitan Becker

The authors have defined the initial definition of PCOM in [1]

Devices have component containers that mange the hosted components on the device. The functionalieis are offered as contracts in terms of interfaces. Also it can have resource requirements that a component must meet in order to use a component. For applications there is an application anchor which is possibly the starting component (root) for an application.

configuration algorithms control the chaining of components.

The goals for PCOM are

1. Resilience failure
2. Efficiency & minimalization
3. Simplicity & Extensibility

In the new design the container is broken into parts

1. the application manager: starts the anchor but it restarts it to the very beginning point whenever needed, which is quite stupid
   
2. assembler: implements the functionality of computing valid configurations. Assembler can launch different configuration algorithms depending on the situation.
   
3. component container: are actually the providers of components for the other two components in the system.
   

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
   

A Reflective Framework for Discovery and Interaction in Heterogeneous Mobile Environments

Grace, P., Blair, G.S., Samuel, S.: A reflective framework for discovery and interaction in heterogeneous mobile environments. SIGMOBILE Mob. Comput. Commun. Rev. 9 (2005) 2-14.

a component is “a unit of composition with contractually specified interfaces, which can be
deployed independently and is subject to third party creation” [14].

Three layers

• concrete middleware section
• binding framework
• service discovery framework
• abstract middleware-programming model
• abstract to concrete mapping

lookup operation across different discover protocols.

Problem: How to find which discovery protocol is in use?

1. Having a fixed point of agreement
   
1. Not all protocols can gurantee to use this technology.
2. The higher level mechanisms may change
2. The approach that they promote is Cycle and See

Interesting component design for OpenCom

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?

FARSITE: Federated, Available, and Reliable Storage for an Incompletely Trusted Environment

A. Adya, W. J. Bolosky, M. Castro, R. Chaiken, G. Cermak, J. R. Douceur, J. Howell, J. R. Lorch, M. Theimer, R. P. Wattenhofer, "FARSITE: Federated, Available, and Reliable Storage for an Incompletely Trusted Environment", 5th OSDI, Dec 2002. http://citeseer.ist.psu.edu/adya02farsite.html

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

Farsite: secure, scalable file system

logically functions as a centralized file server but physically distributed among a set of untrusted computers

Randomized Replication => availability
cryptographic techniques => secrecy of file content (confidentiality)
Byzantine-fault-tolerant => integrity

scalable => distributed hint mechanism
high performance => locally caching data, lazily propagating file updates, varying the duration and granularity

Farsite:

• central file server




• shared namespace


• location-transparent access


• reliable data storage


• local desktop filesystems




• low cost


• privacy from nosy sysadmins


• resistance to geographically localized faults

The security is provided as a matter of virtual security of cryptography, randomized replication, and Byzantine fault tolerance.

The goal: harness the collective resources of loosely coupled insecure and unreliable machines to provide logically centralized secure and reliable file storage service.

cryptography and replication to preserver the confidentiality and integrity

directory metadata is relatively small. It must be comprehensible and revisable directly by the system. Byzantine is used for this.

Farsite's intended workload and machine characteristics are those observed on desktop machines.
workload

1. high access locality


2. low persistent update rate


3. a pattern of read/write sharing that is sequential

Machine Characteristics

1. high fail stop rate
   


2. low but significant rate of malicious or opportunistic subversion

Administration in Farsite is an issue of configuring a minimal system and to authenticate new users and machines. Also signing certificates.

Farsite is intended to run on the desktop workstations ~ 10^5 machines nonce of which are dedicated servers. Connected by a high-bandwidth, low latency network whose topology can be ignored.

Fundamental technology trends for Farsite:

1. a general increase in unused disk capacity (disk capacity is increasing at a faster rate than disk usage, this enables replication of reliability)
   


2. a decrease in the computational cost of cryptographic operations (this enables distributed security)

The system allows the flexibility of multiple roots each of which can be regarded as the name of a virtual file server that is collaboratively created by the participating machines.

The security of any distributed system is an issue of managing trust.

The security components that rely on redundancy need to trust that an apparently distinct set of machines, is truly distinct and not a single malicious machine pretending to be many => Sybil Attack

The certificates

1. namespace certificate : associating the root with a set of machines managing the root metadata


2. user certificate: associating a user with his personal public key so that his identity can be validated


3. machine certificate: associating a machine with its own public key to establish the validity of a machine

Machine certificates in Farsite are not signed directly by CAs but rather by users whose certificates designate them as authorized to certify machines.

users' private key is encrypted by a symmetric key and then stored on a globally readable directory in Farsite. CA private key is kept offline because the entire security of Farsite depends on their secrecy.

Each machine in Farsite may play three roles

1. client: a machine that directly interacts with the user


2. directory group : a set of machines that collectively manage file information


3. file host

Automating Product-Line Variant Selection for Mobile Devices

White, J., Schmidt, D. C., Wuchner, E., and Nechypurenko, A. 2007. Automating Product-Line Variant Selection for Mobile Devices. In Proceedings of the 11th international Software Product Line Conference (September 10 - 14, 2007). International Conference on Software Product Line. IEEE Computer Society, Washington, DC, 129-140. DOI= http://dx.doi.org/10.1109/SPLC.2007.12

PLAs are a promising approach to help developers manage the complexity of variability between mobile devices.

PLAs can be retargeted for different requirement sets by leveraging common capabilities, patterns, and architectural styles.

The design of a PLA is typically guided by the Scope, Commonality, and Variability (SCV) [7].

With the large array of device types and rapid development speed of new devices and capabilities, the system will not be able to know about all device types a priori.

The problems with the existing component-based and feature-based models is the following:

• lack of ability to consider resource consumption constraints, such as the consumed memory
  
• An appropriate architecture for how a device discovery service would be used to characterize a device's nonfunctional requirements (OS, RAM, etc.)
• Fast feature selection speed to help with dynamic software delivery for mobile devices

Contributions by the paper:

• Scatter’s graphical requirement and resource specification mechanisms and show how they facilitate the capture and analysis of a wide variety of requirement types
• how Scatter transforms requirement specifications into a format that can be operated on by a constraint solver
• the automated variant selection engine, based on a Constraint Logic Programming Finite Domain (CLP(FD)) solver
• how PLA constraints impact variant selection time for a constraint-based variant selection engine.
• PLA design rules that we have gleaned from our experiments that help to improve variant selection time when using a constraint-based approach.

The three key challenges associated with creating automated variant selector in pervasive environments

• Unknown device signatures (to respond to devices with different capabilities)
  
• Variant Cost Optimization (the cost associated with the selected variants should be examined before orchestration, selection, and composition of the variants)
  
• Limited selection time ( The time for selecting the appropriate set of variants should be reasonable compared to the time that the user is going to be available in a context where s/he needs the type of service)

In traditional PLA, software developers decide about the set of variants to be selected, configured, and organized to work together.

In pervasive environments there are two problems with manual component selection:

• The target device signatures are not known ahead of time
• variant selection must be done on demand
• The solution would be to capture a formal model of PLA's commonalities and variabilities so that automation can take place
• A model to capture non-functional requirements to prevent deploying the components on systems whose functional requirements fail due to the inconsistencies with the underlying infrastructures

Scatter has the following features

• graphical modeling tool that defines a domain specific modeling language to visually model the components of the interface, the dependencies and composition rules of components, the non functional requirements of each component
• A compiler to convert the graphical notation to a Prolog knowledge base and a CSP
• remote mechanism to a device discovery service that communicates the discovered devices to Scatter's variant selection engine
• A variant selection engine based on Prolog constraint solver that selects a correct and optional variant for a product
  

A key challenge in pervasive environments is that variant selection must take into account requirements based on business and context data.

At one extreme, a tool can limit the types of constraints that can be solved to a small subset that is considered most important. At the other extreme, a tool can allow developers to capture any type of constraint, but provide no guarantee of having a way of deducing a variant that satisfies them.

The strategy is to allow the datasources to change while the types of constraints remain constant.

The type of constraints as they have classified:

• Software Stack on the device
• Resource consumption constraints
• hardware capability constraints
• business/location based constraint

What does this mean? The restriction imposed by the specification format are only on the types of comparisons that can be done and not on the data that the comparison is based upon.

SOAP-based Web service and a CORBA remoting mechanism for remotely communicating device characteristics as they are discovered. (Key, Value) pairs form the reports to Scatter. (How does the device know that it should provide the following information in order to get the component it is looking for? There should be another agent installed on the device, being able to report the information to the device).

A rule is specified that only allows a component to be deployed on a device, if for every local nonfunctional requirement on the component, a resource is present that satisfies the requirement.

A CSP is a problem that involves finding a labeling (a set of values) for a set of variables that adhere to a set of labeling rules (constraints).

A variant becomes a binary string where the ith position represents if the ith component is present.

• Nonfunctional requirements. Components with mismatched nonfunctional requirements are completely eliminated from the chain of composition.
• Prune using low-granularity requirements. Rely on the footprints that various classes of variants provide
• Limit resource tightness. Filter out unessential resource consumptive components
• Create Service classes: Annotating the components based on the class that they are required to be selected from. The more non0functional requirements, the quicker a decision maker can find the required components that it is looking for.

Resource constraints are a key requirement type in mobile devices with limited capabilities.

The whole approach is based on CONSTRAINT-BASED SOLVER AUTOMATION

A key challenge of automating product variant selection is debugging mistakes in the product line specification.

The Sybil Attack

Douceur, J.R. “The Sybil attack” in First International Workshop Peer-to-Peer Systems, IPTPS, 2002 Cambridge, MA, USA, March 7-8, 2002, pp. 251-260.

The goal:

• To show that Sybil attacks are always possible without the presence of a logically centralized authority.
• The impracticality of establishing distinct identities in a large-scale distributed system.
  

Peer-to-Peer systems commonly rely on the existence of multiple independent remote entities to mitigate the threat of hostile peers. There are two methods to do so:

• Replicating computational or storage tasks among several remote sites to protect against integrity violation
• Fragmenting tasks among several remote sites to protect against privacy violation

if the local entity has no direct physical knowledge of remote entities, it perceives them only as informational abstractions that we call identities.

The forging of multiple identities is called Sybil Attack

In the absence of a trusted identification authority (or unrealistic assumptions about the resources available to an attacker), a Sybil attack can severely compromise the initial generation of identities, thereby undermining the chain of vouchers.

faulty entities (deceptive) : The entities capable of performing any arbitrary behavior except as limited by explicit resource constraints

correct entities (honest): entities abiding the rules of any protocol we define

message: an uninterpreted finite-length bit string whose meaning is determined either by an explicit protocol or by an implicit agreement among a set of entities

Each entity e attempts to present an identity i to other entities in the system. l accepts i if e is able to present identity i to l successfully.

A secure hash of a public key is a straightforward and unforgeable identity. It can also generate a symmetric key for a communication session.


Three sources of information about another entity are:

• a trusted agency
• itself
• other (untrusted) entities. (why is it considered untrusted, you can establish trust to some degree but does it still keep it untrusted?)

Direct validation:

• Even when severely resource constrained, a faulty entity can counterfeit a constant number of multiple identities.
• Each correct entity must simultaneously validate all the identities it is presented; otherwise, a faulty entity can counterfeit an unbounded number of identities.