Middleware Design Goals identify the issues for middleware

Middleware Design • Goals identify the issues for middleware design in wireless and mobile environments o An illustrative middleware framework o Detailed design for an image transcoding proxy o

Middleware Definition (RFC 2768) • Def 1: those services found above the transport (I. e. over TCP/IP) layer set of services but below the application environment (i. e. , below application-level APIs) • Def 2: a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment.

Issues for Middleware Design • Diverse networks (wireline, indoor & outdoor wireless) • Network dynamics: congestion, link errors, failures, attacks • User mobility • Thin-client support • Device and platform heterogeneity • Large number of users and devices

Goals for Middleware Design • Minimal change to the existing infrastructure and applications: may add/change a few more “boxes” • Adaptation to network dynamics (induced by mobility and wireless links) • Support for heterogeneous devices (e. g. laptop, desktop, pocket PC, palm-devices) • Customized service (e. g. , adaptive content delivery) • Scalable and secure service • Portability: seamless migration across computing platforms • User-friendly design • Service availability (in the presence of failures, attacks and large user population)

An Adaptive-Proxy Based Middleware Design Framework • Three-tier model: client – proxy – server • A programming model for proxy-based design: TACC Transformation: distillation, filtering, format conversion, etc. o Aggregation: collect and collate data from various sources o Caching: both original and transformed content o Customization: user-customized service (user profiling, adaptive service to each user’s needs or device characteristics) o

On-demand dynamic distillation • Issues to address: client variations along 3 dimensions: o o o Network variation: bandwidth, latency and error behavior Hardware variation: screen size and resolution, color or grayscale bit depth, memory, CPU power Software variation: application-level data encodings, etc. • Design principles for adapting to variation: o o o Datatype-specific lossy compression mechanisms: distillation and refinement based on semantic type of the data On the fly adaptation: compute a desired representation of a typed object on demand Complexity away from both clients and servers: done at an intermediate proxy

Distillation and Refinement • Main idea: high-level semantic types allow datatype -specific operations o o o Images: can discard color info, high-frequency components, or pixel resolution Video: additionally include frame rate reduction Formatted text: can discard some formatting information • Datatype-specific distillation: highly lossy, datatype -specific compression that preserves most of the semantic content of a data object while adhering to a particular set of constraints • Datatype-specific refinement: fetching some part (possibly all) of a source object at increased quality, possibly the original representation

Choices to handle client variations • Server ignores variations: low-end clients may suffer • Servers use the most basic data types and minimal graphics: high-end client suffers • Servers provide multiple formats: no middle ground of representations • Progressive encodings: typically assume that all parts of the encoded documents are equally important • on-demand distillation and refinement: generate onthe-fly based on client characteristics.

Why do we need a proxy ? • Servers concentrate on serving high quality content, rather than having to keep multiple versions • Servers do not pay the costs required to do on-demand distillation • Simple and inexpensive clients can rely on the proxy to optimize content from servers designed for high-end clients • Distillation and refinement can be offered as a value-added service by a service provider • Client communicates with a single logical entity—proxy, allowing the client to manage bandwidth at the application level • Pushing the complexity away from both clients and servers by relocating it into the network infrastructure

A Scalable Cluster-based Infrastructure • Address three issues: incremental scalability, 24 X 7 availability, and cost effectiveness • A cluster based architecture for scalable network services Exploit the strength of cluster computing o Cluster-based servers o • BASE data semantics: basically available, soft state, eventual consistency. •

Why do we need clusters? • Scalability: o o well-suited for networking service workloads that are highly parallel Clusters can grow incrementally over time • High availability: o o Natural redundancy due to the independence of the nodes Hot upgrade: disable a node and upgrade it in place • Commodity building blocks: allow the use of commodity building blocks rather than high-end low-volume machines • Bad thing about clusters: o Administration; component and system replication (software should decompose into loosely coupled modules); partial failures; shared state

Sharing semantics • Traditional transactional database model: ACID (atomicity, consistency, isolation, and durability) o o o strongest semantics at the highest cost and complexity No guarantee for availability Suited for e-commerce transaction, billing users, maintaining user profile info etc. • Many users/services prefer availability rather than strong consistency or durability: o o o Stale data can be temporarily tolerated as long as all copies of data eventually reach consistency after a short time Soft state: can be used to improve performance Approximate answers are preferred if delivered quickly compared to exact but slow answer

BASE semantics • BASE: basically available, soft state, eventual consistency Handle partial failures in clusters with less complexity and cost o Trading consistency for simplicity o Trading consistency for availability o Use of soft state to allow each watcher process to detect that its peer is alive (rather than mirroring the peer’s state), be able to restart its peer (rather than take over its peer’s duties) o

An example: adaptive transcoding proxy • Web server – transcoding proxy – web browser • Proxy architecture: Content analysis o Adaptive transcoding policies: when and how much to transcode o Transformation modules: text modification, images decode & compress o • Key design goal: fixed quality or fixed delay

Design • Two scenarios: Store-and-forward image transcoding o Streamed image transcoding o • Two main issues: Whether to transcode o How much to transcode o • A pair of key computation to decide whether and how much to transcode: Without transcoding: 2*RTT + S / min(Bpc, Bsp) o With transcoding: 2*RTT + Dp + S / Bsp + Sp/Bpc o

Details for store-and-forward image transcoding • Prediction o o Transcoded image’s output size in bytes: high correlation between output size and the image area (number of pixels) linear interpolation Prediction of transcoding delay: approximated by linear function of the input image area • Policies: o o Fixed-quality transcoder: if (transcoding = feasible), transcode according to user’s parameter vector Fixed-delay transcoder: if(transcoding=feasible), search space of transcoding parameters to find optimal set that maximizes quality subject to the given response time, transcode using the optimal parameters

Streamed image transcoding • Perform transcoding under two stability conditions: No buffer overflow o Output transmission link is not saturated o