SERVICE-ORIENTED ARCHITECTURE in MOBILE NETWORK Long Nguyen Hoang - - PowerPoint PPT Presentation

SERVICE-ORIENTED ARCHITECTURE

Dec 2006

Long Nguyen Hoang silver@cc.hut.fi Marek Konieczny marek.konieczny@gmail.com

in MOBILE NETWORK

Agenda

• SOA overview
• SOA in mobile network
• Why Mobile SOA
• WS standards for mobile
• Mobile SOA models
• Conclusion

SERVICE-ORIENTED ARCHITECTURE Part 1

Start programming with Business not with Architecture

SOA - Problem Statement

SOA – The Solution

Purchase Purchase E E-

• commerce

commerce portal portal Customer Customer relationship relationship services services Fulfillment services Fulfillment services Authentication Authentication and authorization and authorization services services Credit authorization Credit authorization Billing services Billing services

A SOA System in real life

SOA Architecture

Business Process Legacy System

CRM System SAP ERP System Trading partners Data warehouse

Service Layer

Check customer credit Setup account Fraud check

Application Layer

Metadata, QoS, Security, Monitor, Management

<?xml version="1.0" encoding="UTF-8"?> <process name="loanApprovalProcess" ... > <partnerLinks> <partnerLink name="customer" partnerLinkType="..."/> <partnerLink name="approver" partnerLinkType="..."/> </partnerLinks> <variables> <variable messageType="..." name="request"/> <variable messageType="..." name="approvalInfo"/> </variables> <sequence> <receive createInstance="yes" operation="approve" variable="request" ... /> <invoke operation="approve" inputVariable="request"

• utputVariable="approvalInfo" ... />

<reply operation="approve" variable="approvalInfo".../> </sequence> </process>

Duplicate Number!

SalesDB

start end

Router Billing

Business process Visual Designer Business process description language

SOA - Definition

• Key technologies
• Interaction : SOAP
• Semantic : WSDL
• Visibility : UDDI
• WS Standards
• Advantages
• Reusability
• Interoperability
• Composite services
• Scalability, extensibility
• Adaptability (platform independence)
• Definition
• A paradigm for organizing and utilizing distributed capabilities

that may be under the control of different ownership domains. (OASIS)

SOA in MOBILE NETWORK Part 2

Fit An Elephant Through The Eye Of A Needle???

Why SOA in Mobile realm

Pure data content Standardization

Loose coupling Flexible Portable

Different services from different providers

GSM services 3G, 4G Location-based services Personal service

SOA and Mobile Services

Service Directory Service invoke A simplified view of a SOA with support for mobile device suspend find find suspend register resume Mobility Controller

Service Environment A Service Environment B <<moves>>

S2 S1 S4 S3

Composite services in different service environments

Mobile SOA Worries

Processing requirements:

• Claim: CPUs in mobile devices can’t handle complex XML Parsing and

XML Security

• Truth: Based on Nokia demo/pilot activities during 2002-2005, current

Smartphone implementations have no problems on handling WS messages/features and it only gets better very soon…..

• Minimize SOAP primitives using kSOAP and

kXML (v2) for J2ME

• the common XML and SOAP packages currently available are quite

large and contain hundreds of classes (combined into a single jar file, they take up less than 42K)

• these packages depend on features of the Java runtime that simply don't

exist on a microdevice (Connected Limited Device Configuration )

Mobile SOA Worries (cont.)

J2EE Application Server

kSOAP

AlertServlet

Service ABC AkertSerivce Backend System

AlertServiceClient (Midlet Application) kSOAP

Mobile Phone kSOAP Messages (via HTTP) SystemAlert Objects System Events (sent visa JMS)

Mobile SOA Worries (cont.)

Limited downlink/uplink bandwidth

• Claim: WS and XML are verbose, thus the downlink/uplink capacity

generally available for mobile devices can’t provide acceptable response times for the applications

• Truth: WS applications typically send/receive info only when needed,
• reduce the overhead significantly
• acceptable response times to users even with basic GPRS data rates (<40kbps).
• Compression (such as GZIP, WBXML, DiffEnc) can help
• Wait until W3C Efficient XML Interchange WG finish work
• An alternative encoding of the XML Information Set
• Addresses the specified requirements identified by the XML Binary

Characterization WG,

• Keep maintaining the existing interoperability between XML applications

and XML specifications.

Mobile SOA Worries (cont.)

Use different SOAP Bindings:

• SOAP-over-HTTP

A SOAP message is transported using HTTP by encapsulating a SOAP request into the message body of a HTTP GET or HTTP POST.

• SOAP-over-TCP

A SOAP message is contained into the data octets part of a TCP packet. Apache Axis and Microsoft WSE (Web Service Enhancement) 2.0 already include APIs that enables the sending of SOAP messages via TCP channel.

• SOAP-over-SMTP

A SOAP messages are encapsulated in the bodies of emails. this allows asynchronous message exchange between web services.

Mobile SOA Worries

SOAP-over-UDP

• A SOAP message is encapsulated into the data octets part of a single UDP
• packet. The most suitable for applications where short SOAP messages are

sent frequently and reliability is not of concern.

Mobile SOA Worries

• Intermediaries : Handheld Flexible

Representation (HHFR)

W S- M FR End- poi nt

WS-MFR Schema Representation Headers Stream Info Context Store

• 1. Negotiation over SOAP

W S- M FR End- poi nt

• 2. Stream of Message in

Preferred Representation

Mobile SOA Worries

• Intermediaries: Wireless SOAP
• Efficient sync/async messaging
• Efficient XML serialization
• Persistent connections across

mobility

Internet (SOAP) Web Service Mobile Gateway (SOAP to Binary) Mobile Device (Binary to SOAP to Objects) Wireless (SOAP) Wireless system

Web Services for mobile

• WS Star Standards (WS*)
• Liberty Alliance Standards
• Representational State Transfer (REST)

Architecture

• an lightweight HTTP-based model for the programmatic consumption of

web content and services, that uses URIs for representing "items" on the web, and the HTTP methods GET, PUT, POST and DELETE to operate

• n them. Returned data is typically in XML.
• 3GPP Open Service Access (OSA)

WS Star Standards

Foundation Applications & Application Structure Transport

Connected Applications Connected Applications Management Management Business Business Processes Processes … …

Security Security

WS WS-

• Security

Security WS WS-

• Trust

Trust WS WS-

• Federation

Federation

Reliability Reliability

WS WS-

• RM

RM

Transactions Transactions

WS WS-

• Coordination

Coordination WS WS-

• Transactions

Transactions

Messaging (SOAP, WS Messaging (SOAP, WS-

• Addressing)

Addressing)

XML XML Metadata Metadata

WSDL, WS WSDL, WS-

• Policy

Policy

UDP TCP HTTP UDP TCP HTTP

Without federated identity

All information must be duplicated, the citizen registers 5 times, may use 5 different identifications and passwords, and in some cases may have to do two to three different transactions within one ministry or agency

A use case : A citizen changes his/her name without federated identity :

Logon to the Ministry of Interior : change of name change of records Logon to the Ministry of Finance : change of fiscal identity change of marital status Logon to the Ministry of Social Aid : if eligible for social aid Logon to Ministry of Health : change of name for same social security number Logon to Ministry of Defence : change name for same ID #

Liberty use case

Citizen connects once through any government authority; Automatically recognized by other government services Citizen authenticate to any government authority One sign-on opens all connected services within the circle of trust

education interior finance social aid

Citizen connects to any government authority within the circle of trust of public

• services. Automatic update through integration between agencies

Liberty’s Architecture

Liberty Identity Services Interface Specifications (ID-SIS)

Liberty Identity Federation Framework (ID-FF) & Security Assertion Markup Language (SAML) 2.0

Liberty Identity Web Services Framework (ID-WSF)

Enables identity federation and management through features such as identity/account linkage, simplified sign on, and simple session management Enables interoperable identity services such as personal identity profile service, contact book service, geo-location service, presence service and so on. Provides the framework for building interoperable identity services, permission based attribute sharing, identity service description and discovery, and the associated security profiles

Liberty specifications build on existing standards (SAML, SOAP, WS-Security, XML, etc.)

Open Service Access (OSA)

Open Service Access Parlay/ OSA Parlay X

Architecture to make use of network functionality

through open standardized interface

A set of APIs to develop applications that

exploiting the current and emerging features

• f telecom networks.

WS for telecom services:

call control, messaging ,location, presence, charging and account management

Can deploy applications within or outside

• f the telecom network

OSA (cont)

MMSC -X component Multimedia Message Web Service

Parlay X I/F MMSC MMS-C MM7 VASP Interface Mobile network

Stock Quote Web Service Stock Quote Web Service

…… .. content1 =get StockQuote () … .. Retrieve user Profile … . messageId= sendMessage( content ) … . status= getMessageDeliveryStatus (messageId) if status=M essage_Waiting … . fi … content2 =get StockQuote () messageId= sendMessage ( content2 )

User profile

1 2 3 4 5 6

Service Discovery

• WS-Discovery
• A multicast discovery protocol to locate services
• Probes are sent to a multicast group, and target services that match

return a response directly to the requester.

• Target services send announcements when joining/leaving the network.
• M-Services Framework
• A service manager as a mediator layer between the service providers

and mobile devices

• Manage the information flow between both components.
• Use dynamic invocation interface (DII)
• invoke Web Services without knowing their communication interface

at compile time.

• METEOR-S
• Web Service discovery infrastructure
• An ontology based infrastructure to provide access to registries
• based on business domains
• grouped into federations

Mobile SOA models

• Native Client
• Mobile Java Client
• Mobile Thin Client
• P2P

Model 1 – Native Client

Not so good

Scalability

Need installing, OTA

Deployability

Really bad

Portability

High, OS theme

Usability

Ticket Purchase Application Ticket Purchase Service Authentication & Payment Service 1 3 4 2 5 8 7 6 Phone Network Phonebook Application Messaging Application Calendar Application

Model 2 – Mobile Java Client

Based on server-side

Scalability

Simple and easy

Deployability

Better than native, depend on MIDP

Portability

Quite usable, must define own UI element

Usability

1 3 4 6 7 Phone Ticket Purchase Service Authentication & Payment Service Calendar Service 2 8 Ticket Purchase Application MIDP Messaging 5 Network MIDP Environment Messaging Application Buddylist Service

Model 3 – Mobile Thin Client

Server side, browser support

Scalability

As simple as it gets

Deployability

Strong

Portability

Good, offline problem, non-compatible with native solution

Usability

1 3 4 7 Phone Ticket Purchase Service Authentication & Payment Service Calendar Service 2 Ticket Purchase UI 5 Network Mobile Browser w/ scripting Messaging Application Buddylist Service Messaging Gateway 6

Model 4 – P2P

P

B

R

P

B

R R

P P

R

Complicated, Mobile as a service provider

Scalability

Have to know all provider nodes

Deployability

Good if follow the same P2P model

Portability

Under investigation

Usability

P2P Web Services Model

GUI

Local Service Repository

SOAP GUI Adapt ation

GUI

Remote Service Repository QoS

Client Proxy Service Security Transport

Client Server XML Parser

Software Architecture enabling P2P Web Services

Proxy Service

Java method invocations Autom. proxy gen. (WSDL2Java)

SOAP calls

Publish service

Proxy object generation from the WSDL service description

WSDL kSOAP

Service methods Request Handler Response Handler HTTP Interface Deployment Interface 2 1 4 3 5 Client Request HTTP POST/GET Client Response

kXML

SOAP Server Core Structure

Comparison

• 1*: Native Client
• 2*: Java Client
• 3*: Thin Client
• 4*: P2P

+/- +/- +/- +/- + + +

• +

+/- Scalability +/- Deployability +/- Portability +/- Usability

1* 2* 3* 4*

Conclusion

• Why not just WAP?
• Mobile SOA is potential
• New and maturing paradigm
• Some predictions
• WS-* for mobile
• M-Commerce
• Mobile Services
• Mobile phone as a service provider
• Local web services provider on mobile phone

References

• External text file

Thank you for attention Q&A