Mobile Middleware Course: Support Technologies Sasu Tarkoma

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 42

Mobile Middleware Course

Support Technologies

Contents

Virtualization
Session Initiation Protocol (SIP)
IP Multimedia Subsystem (IMS)
Web services
Research systems

Virtualization

Virtualization system is a framework that


combines or divides computing
resources to present a transparent view
of one or more environments

Hardware/software partitioning (or


aggregation)
Partial or complete machine simulation
Emulation (can be partial or complete)
Time-sharing

VMware Architecture
Guest OS App
Guest OS
Host OS Apps

VMwareApp

Virtual Machine

Host OS

VMware driver

VM monitor

disks

PC Hardware

memory

CPU

Source: http://www.ecsl.cs.sunysb.edu/~susanta/slides/virt.ppt

Source: http://www.ecsl.cs.sunysb.edu/~susanta/slides/virt.ppt

Mobile virtualization

Server Based Virtualization of Desktop Infrastructure


Client Side Solution Assured Computing
Environment
Application Virtualization
Moving the desktop to a virtualized image in the data
center allows the complex components to be protected
and componentized
Workload isolation and migration
Application virtualization
Virtualization is a possible solution to the fragmentation
problem
http://www.vmware.com/technology/mobile/

SIP

An Application-layer control (signaling)


protocol for creating, modifying and
terminating sessions with one or more
participants.
Sessions include Internet multimedia
conferences, Internet telephone calls
and multimedia distribution.
Members in a session can communicate
via multicast or via a mesh of unicast
relations, or a combination of these.
Text based, model similar to HTTP.

SIP History

Mid-1990s, emerged from the research


of Dr. Henning Schulzrinne, Columbia
University, on Multi-party Multimedia
Session Control (MMUSIC)
1996, submitted to the Internet
Engineering Task Force (IETF) and
developed by the SIP Working Group
1999, first published as IETF RFC 2543
2000, selected by 3GPP
2002, RFC 3261 (with further
supplements in other RFCs)

SIP features

User location: determination of the end system to


be used for communication
User capabilities: determination of the media and
media parameters to be used
User availability: determination of the willingness
of the called party to engage in communications
Call setup: "ringing", establishment of call
parameters at both called and calling party
Call handling: including transfer and termination
of calls

SIP messages

Start Line (Request Line or Status Line)

Headers

message type (method type & URI in


requests, and response code in responses)
protocol version
fields to convey message attributes
can span multiple lines, appear multiple
times, take multiple comma-separated values

Body (Content)

to describe the session to be initiated


to contain opaque textual or binary data

SIP
1.
2.
3.

4.
5.
6.

SIP Addressing
Locating a SIP Server
Sending SIP Requests: SIP
Transactions
SIP Methods
SIP Responses
Subsequent Requests and Responses

6.

100 Trying

3.
DN
tes S Q
t.c ue
om ry
:
4.
Re
sp
on
se

15. OK

12. 180 Ringing

2. 100 Trying

16.

180 ACK
Media (RTP)

13. 200 OK

200 OK

10. 100 Ringing

User Agent Alice

14.

Proxy Server
9. INVITE
sip:[email protected]

11. 180 Ringing

B?

5. INVITE
To:sip:[email protected]

y:
er
Qu

1. INVITE
To:sip:[email protected]

LS
7.

Proxy Server

Location
Service

se
on
sp I
Re UR
8. SIP

DNS
Server

User Agent Bob

IMS

The IP Multimedia Subsystem Provides


Multimedia Services Across Networks (fixed &
mobile), such as:

Instant Messaging, Video Sharing, Push-To-Talk,


Gaming, Video Conferencing

IMS Uses SIP protocol To Setup Multimedia


Sessions Over IP Network
SIP is a signalling protocol to:

Locate user given SIP Universal Resource


Identifier (URL) (e.g., sip:[email protected])
Set up session and negotiate its parameters

IMS Proxies

A Proxy-CSCF (P-CSCF) is a SIP proxy that is the first point of contact for the IMS
terminal

A Serving-CSCF (S-CSCF) is the central node of the signalling plane

it is assigned to an IMS terminal during registration, and does not change for the duration of
the registration
it sits on the path of all signalling messages, and can inspect every message
it authenticates the user and establishes an IPsec security association with the IMS terminal.
it can also compress and decompress SIP messages using SigComp, which reduces the
round-trip over slow radio links
it may include a Policy Decision Function (PDF), which authorizes media plane resources
e.g. quality of service (QoS) over the media plane. It's used for policy control, bandwidth
management, etc. The PDF can also be a separate function.
it also generates charging records
It is always located in the home network. It uses Diameter Cx and Dx interfaces to the HSS
to download and upload user profiles it has no local storage of the user. All necessary
information is loaded from the HSS
it handles SIP registrations, which allows it to bind the user location (e.g. the IP address of
the terminal) and the SIP address
it sits on the path of all signaling messages, and can inspect every message
it decides to which application server(s) the SIP message will be forwarded, in order to
provide their services
it enforces the policy of the network operator

An Interrogating-CSCF (I-CSCF) is another SIP function located at the edge of an


administrative domain

IMS
Service Delivery Platform
Components

Compositions

Adapters

IMS Service Framework


HSS
(AAA)

IMS Core
P-CSCF

App.
Servers

Media
servers

S-CSCF

Media
server/
gateway

I-CSCF

PDF
IP Core Network
Access Networks

IMS

Example of call routing

CSCF = Call State Control Function


HSS = Home Subscriber Service

Interrogating
Location Query
CSCF
HSS

Invite
From: sip:[email protected]
To: sip:[email protected]
Call-ID

User A

Serving
CSCF

Serving
CSCF

Multimedia session

Ok

User B

Non-Real-Time

Real-Time Interaction

Session-Based
Voice

Non-Session-Based

Push-to-talk
Chats

Push-toVideo

Online
Games

Instant Messaging
Push email

Enterprise
VPN
Streaming
Video

Web, HTML

IP/TV

Messaging
SMS and MMS

Peer-to-Peer
Video on Demand
SIP (IMS) only
Applications

E-Commerce

SIP or Non-SIP
Applications

Non-SIP Only
Applications

Event-based Systems and


Publish/subscribe

Event delivery from publishers to subscribers

A frequently used communication paradigm

Decoupling in space and time


Solutions from local operation to wide-area networking
Proposed for mobile/pervasive computing

The event service is a logically centralized service

Event is a message with content


One-to-many, many-to-many
Builds on messaging systems and store-and-forward

Basic primitives: subscribe, unsubscribe, publish

Various routing topologies and semantics

Web Service Architecture

The three major roles in web services

Service provider

Service Requestor

Any consumer / client

Service Registry

Provider of the WS

logically centralized directory of services

A protocol stack is needed to support


these roles

Web Services Protocol Stack

Message Transport

XML Messaging

Responsible for encoding messages in common XML format


XML-RPC, SOAP

Service Description

Responsible for transporting messages


HTTP, BEEP

Responsible for describing an interface to a specific web


service
WSDL

Service discovery

Responsible for service discovery and search


UDDI

What is SOAP?

Fundamentally stateless one-way message exchange paradigm


More complex interactions may be implemented
Exchange of structured and typed information
Between peers in decentralized fashion
Using different mediums: HTTP, Email, ..
Request-reply and one-way communication are supported
Note that XML infoset is an abstract specification
On-the-wire representation does not have to be XML 1.0!

SOAP 1.2 HTTP Subset. SOAP as HTTP extension


Specifications
SOAP Version 1.2 Part 0: Primer
SOAP Version 1.2 Part 1: Messaging Framework
SOAP Version 1.2 Part 2: Adjuncts
SOAP Version 1.2 Specification Assertions and Test Collection

SOAP Node acting


as initial sender

SOAP Nodes acting


as ultimate receivers

SOAP Sender

SOAP Receiver

SOAP Sender

SOAP
Receiver
SOAP
SOAP
Receiver
Receiver

Soap
Application 1

Soap
Application 2

Soap
Application 1

Soap
Soap
Soap
Application
Application
Application
2 22

SOAP
Message Path
SOAP

SOAP
SOAP
Message
Processor
Processor

Underlying
Protocol
Layer

Underlying Protocol
Message Path

Host 1

BUYER

SOAP Layer

SOAP Layer

SOAP Node acting SOAP Node acting


as initial sender
as ultimate receiver

SOAP
Message Path
SOAP

SOAP
SOAP
SOAP
SOAP
Message
Processor
Processor
Processor
Processor

Underlying
Protocol
Layer

Host 2

Underlying Protocol
Message Path

Host 1

MARKETPLACE

Hosts

SELLERS

REST

REST (Representational State Transfer) (Roy Fielding,


PhD thesis)

Architectural style of networked systems


Applications transfer state with each resource representation

State is a property of a resource

Resources

Representations of the data are transmitted

Any addressable entity


Web site, HTML page, XML document, ..

URLs Identify Resources

Every resource uniquely identifiable by a URI

REST II

Uses standards

Addressing and naming: URI


Generic resource interface: HTTP GET, POST, PUT,
DELETE
Resource representations: HTML, XML, GIF,..
Media types: MIME

Loose coupling
Stateless transactions
Self-descriptive messages
Hypermedia is the engine of application
state

Just resources and URIs

Event Systems I

Traditional MoM systems are message queue based (one-to-one)


Event systems and publish/subscribe are one-to-many or many-tomany

One object monitors another object


Reacts to changes in the object
Multiple objects can be notified about changes

Events address problems with synchronous operation and polling


In distributed environments a logically centralized service
mediates events

anonymous communication
expressive semantics using filtering

Pub/Sub Service
Subscriber
Subscriptions

Su
re bs
re que crib
sp s
e
on t/
se

Publisher
Notifications
message
instances

Situation

Notification
Consumer
Notify

Notification
Engine
Subscription
Manager
Subscription
management on
behalf of the
Publisher

Receives
notifications

Matches and sends


notification to the
appropriate
consumers

Subscriptions

Event Systems II

Push versus Pull


May be implemented using RPC, unicast, multicast,
broadcast,..
Three main patterns

Observer design pattern

Notifier architectural pattern

Used by many research systems

Event channel

Used in Java / Jini

Used in CORBA Event/Notification Service

Filtering improves scalability / accuracy

Research topic: content-based routing

Tuple Spaces

Tuple-based model of coordination


The shared tuple space is global and persistent
Communication is

Primitives

decoupled in space and time


implicit and content-based
In, atomically read and removes a tuple
Rd, non-destructive read
Out, produce a tuple
Eval, creates a process to evaluate tuples

Examples: Linda, Lime, JavaSpaces, TSpaces

Java Message Service (JMS)

Asynchronous messaging support for Java


Point-to-point messaging

Topic-based publish/subscribe

Map,Object,Stream,Text,andBytes

Durable subscribers

SQL for filtering messages at the topic event queue


One-to-many

Message types:

One-to-one

Event stored at server if not deliverable

Transactions with rollback

Client 1

Sends

Acknowledges

Queue

MSG

MSG

Client 2

Consumes

Subscribes

Client 1

Publishes

MSG

MSG

Topic

Client 2

Delivers
Subscribes
MSG
Delivers

Client 3

OMG Distributed Data Service I

The Data Distribution Service for Real-Time


Systems (DDS)
The specification defines an API for data-centric
publish/subscribe communication for distributed
real-time systems.
DDS is a middleware service that provides a global
data space that is accessible to all interested
applications.
DDS uses the combination of a Topic object and a
key to uniquely identify instances of data-objects.
Content filtering and QoS negotiation are supported
DDS is suitable for signal, data, and event
propagation.

DDS
Data-Object
Identified by means
of the Topic

Dissemination
Publisher

Identified by means
of the Topic
Subscriber
Data values
DataReader

Data values
DataWriter

Subscriber
Data values
DataReader

Pervasive computing middleware


Projects

Key Issues

UIC

Heterogeneity of devices and networks: It helps users to specialize to the particular


properties of different devices and network environments

X-Middle

Disconnected operations in mobile applications: It allows mobile users to share data


when they are connected, or replicate the data and perform operations on them off-line
when they are disconnected; data reconciliation takes place when user gets reconnected

Gaia

Dynamic adaptation to the context of mobile applications: It supports the


development and execution of portable applications in active spaces

Lime

Programming constructs which are sensitive to the mobility constraints: It explores


the idea by providing programmers with a global virtual data structure and a tuple space
(Tspace), whose content is determined by the connectivity among mobile hosts

Tspaces

Asynchronous messaging-based communication facilities without any explicit


support for context-awareness: It explores the idea of combination of tuple space
(Tspace) and a database that is implemented in Java. Tspace targets nomadic
environment where server contains tuple databases, reachable by mobile devices
roaming around

L2imbo

QoS monitoring and control by adapting applications in mobile computing


environment: It provides the facilities of multiple spaces, tuple hierarchy, and QoS
attributes

Aura

Distraction-free pervasive computing: It develops the system architecture, algorithms,


interfaces and evaluation techniques to meet the goal of pervasive computing

Fuego Core (HIIT)

Mobile and wireless environments have


different requirements than desktop systems

Vision: A service application is distributed


among various application servers, network
elements and terminals
Three year Tekes project (2002-2004)

User mobility, terminal mobility, connectivity, device


characteristics, dynamic environments

Industrial partners: Nokia, TeliaSonera, Elisa,


Ericsson, Movial
Open source software

Demonstration at WMCSA 2004

Fuego Architecture

The Fuego middleware service set for


mobile computing

Data communication

Data synchronization

Efficient wireless SOAP


Efficient content-based routing (asynchronous
events)
3-way XML document merging
XML-aware distributed file system

Applications

Presence service, mobile ticker, image-album

Ubiquitous and Pervasive software


MobileServices
Services
Mobile
MobileApplications
Applications
Mobile

PresenceService
Service
Presence

PresenceClient
Client
Presence
Sync.Filesystem
system
Sync.File

Sync. File
System

Filter Service

Event Bus

Filter Service

Jetty
Jetty

WirelessSOAP
SOAP
Wireless

HTTP1.1
1.1
HTTP

Event Service

BEEP
BEEP

Servlets
Servlets

ApacheAxis
Axis
Apache

Jetty
Jetty

WirelessSOAP/SOAP
SOAP/SOAP
Wireless

HTTP1.1
1.1
HTTP

BEEP
BEEP

TCP
Host Identity Protocol (HIP)
IP
IP

Mobile Clients

Distributed Servers

Automaticreconciliation
reconciliationofofXML
XMLdocuments
documents
Automatic
Ubiquitous
and
Pervasive
software
Optimized
storage
of
XML
Expressive
async.
communication
Optimized
storage
of
XML
Expressive async. communication
Mobile
Services
Ad-hocfile
filesharing
sharing
Mobile
Services
Content-based
routing
using
filters
Ad-hoc
Presence
service
based
on
events
Content-based
routing
using
filters
Presence
service
based
on
events
Integrateswith
withexisting
existingfile
filesystems
systems
(NFS) / mobility support
Eventbuffering
buffering
Integrates
(NFS)
Control
of
presence
attribute
visibility
Event
/ mobility support
Mobile
Applications
Control of presence attribute visibility
Mobile Applications
Presenceoperation
Service
Supportfor
forcontext-aware
context-aware
Presence
Service
Support
operation
PresenceClient
Client
Presence

Sync. File
System
Event Service
Efficientsync/async
sync/asyncmessaging
messaging
Efficient
Sync.Filesystem
system
Filter Service
EfficientXML
XMLserialization
serialization
Sync.File
Efficient
PersistentEvent
connections
acrossmobility
mobility
Bus
Persistent
connections
across
Reliablemessaging
messaging
Servlets
ApacheAxis
Axis
Reliable
Filter Service
Servlets
Apache

Multiplexingmultiple
multipleconnections
connectionson
onTCP
TCP
Multiplexing
Prioritization
connections
Prioritization
ofofconnections
Jetty End-to-end
Jetty
Wireless
SOAP
Wireless
SOAP/SOAP
authentication
of
hosts
Jetty
Jetty
Wireless
SOAP
Wireless
SOAP/SOAP
End-to-end authentication of hosts
Encryptionofofnetwork
networktraffic
trafficusing
usingIPsec
IPsec
Encryption
HTTPMobility
1.1
BEEP
HTTP1.1
1.1
BEEP
Mobility
andmultihoming
multihoming
support HTTP
HTTP
1.1
BEEP
BEEP
and
support
Resilientsockets
sockets
Resilient
TCP
Host Identity Protocol (HIP)
IP
IP

Mobile Clients

Distributed Servers

FUEGO DEMO

SPICE

Provides service and component development and


deployment infrastructure

For network operators and 3rd party service providers


IMS as enabling technology. Focus on IMS evolution
Combining IMS with Web services
Support expected business models

Goals

3rd party services can be easily created


Converged services - combining telecommunications and
IT services
Service provider can focus on the core business
Platform support:

identity, charging, context awareness interface, service


roaming between platforms, technology abstractions,

Generate operator revenues jointly with 3rd parties


(revenue sharing)

Architecture
Users, service developers

Scenarios
State of the
art

Business Models

Converged B3G Platform


Architecture
Knowledge
Web services
Technology
SIP-AS
HSS

CSCF

IMS

MRF

Future
solutions
and
standards

SPICE Platform
Service Execution Environment
Exposure and Mediation Layer
Terminal Platform
Value added
services layer
Knowledge layer
Component layer
Capabilities &
Enablers
IMS client
Browser
Basic OS support

SPICE Service Execution Environment


Value added services layer
Composite components and orchestration
Knowledge layer
Brokers, Mediators, Reasoners
Component service layer
SPICE components and component
Capabilities & Enablers
Repositories,
IMS System
Third party
profiles,
Legacy
components
ACLs, SLAs
systems

SPICE: Key Principles

SPICE users are essentially IMS subscribers, not necessarily


registered in IMS

SPICE Application Servers are primarily but not exclusively


IMS AS

SIP-based mechanisms are the default choice for access using


conversational or multimedia sessions
For converged network services, we are also examining HTTP
and Web services based access

SIP-based data models should be used for interaction


between the users and the SPICE platform

Rationale: loose coupling of non-IMS-based services with IMS


through the use of IMS credentials and identity management

IETF-defined presence data model and filtering/authorizing


mechanisms, the OMA-defined UAProf model
For example, in Knowledge Management Framework, HTTP or
Web services or SIP-based mechanisms may be used

OMA/IMS network enablers should be used in priority

Presence, IM, voice and video calls, Messaging

You might also like