SERVICE-ORIENTED ARCHITECTURE

Dec 2006

Long Nguyen Hoangsilver@cc.hut.fi

Marek Koniecznymarek.konieczny@gmail.com

in MOBILE NETWORK

AgendaSOA overviewSOA in mobile network

Why Mobile SOAWS standards for mobileMobile SOA models

Conclusion

SERVICE-ORIENTED ARCHITECTURE

Part 1

Start programmingwith Business

not with Architecture

SOA - Problem Statement

SOA – The Solution

PurchasePurchase

EE--commercecommerceportalportal

Customer Customer relationshiprelationshipservicesservices

Fulfillment servicesFulfillment services

Authentication Authentication and authorization and authorization servicesservices

Credit authorizationCredit authorization

Billing servicesBilling 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 creditSetup account Fraud check

Application Layer

Metadata, Q

oS, S

ecurity,M

onitor, Managem

ent

<?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" outputVariable="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 technologiesInteraction : SOAPSemantic : WSDLVisibility : UDDIWS Standards

AdvantagesReusabilityInteroperability

Composite servicesScalability, extensibilityAdaptability (platform independence)

DefinitionA paradigm for organizing and utilizing distributed capabilitiesthat 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 realmPure data contentStandardization

Loose couplingFlexiblePortable

Different services from different providersGSM services 3G, 4GLocation-based servicesPersonal service

SOA and Mobile Services

Service Directory

Serviceinvoke

A simplified view of a SOA with support for mobile device

suspend

find

find

suspend registerresume

MobilityController

Service Environment AService Environment B

<<moves>>

S2S1

S4S3

Composite services in different service environments

Mobile SOA WorriesProcessing 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 A

BC

AkertS

erivce

Backend System

AlertServiceClient(Midlet Application)

kSOAP

Mobile PhonekSOAP 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 significantlyacceptable 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 workAn alternative encoding of the XML Information SetAddresses 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-HTTPA SOAP message is transported using HTTP by encapsulating a SOAP

request into the message body of a HTTP GET or HTTP POST.

SOAP-over-TCPA 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-SMTPA SOAP messages are encapsulated in the bodies of emails. this allows

asynchronous message exchange between web services.

Mobile SOA WorriesSOAP-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 WorriesIntermediaries : Handheld Flexible Representation (HHFR)

WS-MFREnd-point

WS-MFR SchemaRepresentationHeadersStream Info

Context Store

1. Negotiation over SOAP

WS-MFREnd-point

2. Stream of Message in Preferred Representation

Mobile SOA WorriesIntermediaries: Wireless SOAP

Efficient sync/async messagingEfficient XML serializationPersistent 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 StandardsRepresentational 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 on them. Returned data is typically in XML.

3GPP Open Service Access (OSA)

WS Star Standards

Foundation

Applications & Application Structure

Transport

Connected ApplicationsConnected Applications

Man

agem

ent

Man

agem

ent

Bus

ines

sB

usin

ess

Proc

esse

sPr

oces

ses

……

SecuritySecurityWSWS--SecuritySecurity

WSWS--TrustTrust

WSWS--FederationFederation

ReliabilityReliabilityWSWS--RMRM

TransactionsTransactionsWSWS--CoordinationCoordination

WSWS--TransactionsTransactions

Messaging (SOAP, WSMessaging (SOAP, WS--Addressing)Addressing)

XMLXML

Met

adat

aM

etad

ata

WSD

L, W

SW

SDL,

WS --

Polic

yPo

licy

UDP TCP HTTPUDP 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 namechange of records

Logon to the Ministry of Finance : change of fiscal identitychange of marital status

Logon to the Ministry of Social Aid : if eligible for social aidLogon to Ministry of Health : change of name for same social security numberLogon to Ministry of Defence : change name for same ID #

Liberty use caseCitizen 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 ArchitectureLiberty 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 of telecom networks.

WS for telecom services: call control, messaging ,location, presence, charging and account managementCan deploy applications within or outside of the telecom network

OSA (cont)

MMSC -Xcomponent

M ultimediaMessage W ebService

Parlay X I/FM M SCM M S-C

M M 7 VASPInterface

M obile netw ork

Stock Q uoteW eb Service

Stock Q uoteW eb Service

… … ..content1 =get StockQ uote ()… ..Retrieveuser Profile… .messageId= sendMessage( content )… .status= getMessageDeliveryStatus (messageId)if status=M essage_Waiting… .fi…content2 =get StockQ uote ()messageId= sendMessage ( content2 )

Userprofile

1

2

3

4

5

6

Service DiscoveryWS-Discovery

A multicast discovery protocol to locate servicesProbes 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 FrameworkA service manager as a mediator layer between the service providers and mobile devicesManage the information flow between both components. Use dynamic invocation interface (DII)

invoke Web Services without knowing their communication interface at compile time.

METEOR-SWeb Service discovery infrastructureAn ontology based infrastructure to provide access to registries

based on business domains grouped into federations

Mobile SOA models

Native ClientMobile Java ClientMobile Thin ClientP2P

Model 1 – Native Client

Not so goodScalability

Need installing, OTADeployabilityReally badPortabilityHigh, OS themeUsability

TicketPurchaseApplication

TicketPurchaseService

Authentication & Payment

Service

1

3

4

2

5

8 7

6

Phone Network

PhonebookApplication

MessagingApplication

CalendarApplication

Model 2 – Mobile Java Client

Based on server-sideScalability

Simple and easyDeployabilityBetter than native, depend on MIDPPortabilityQuite usable, must define own UI elementUsability

1

3

4

6

7

Phone

TicketPurchaseService

Authentication & Payment

Service

CalendarService

2

8

TicketPurchaseApplication

MIDPMessaging

5

NetworkMIDP Environment

MessagingApplication

BuddylistService

Model 3 – Mobile Thin Client

Server side, browser supportScalability

As simple as it getsDeployabilityStrongPortabilityGood, offline problem, non-compatible with native solutionUsability

1

34

7

Phone

TicketPurchaseService

Authentication & Payment

Service

CalendarService

2

TicketPurchase

UI

5

NetworkMobile Browser w/ scripting

MessagingApplication

BuddylistService

MessagingGateway

6

Model 4 – P2PP

B

R

P

B

R

R

P

PR

Complicated, Mobile as a service providerScalability

Have to know all provider nodesDeployabilityGood if follow the same P2P modelPortabilityUnder investigationUsability

P2P Web Services Model

GUI

Local ServiceRepository

SOAPGUI

Adaptation

GUI

Remote ServiceRepository QoS

ClientProxy

Service

Security

Transport

Client

ServerXML Parser

Software Architecture enabling P2P Web Services

Proxy ServiceJava

methodinvocations

Autom.proxy gen.

(WSDL2Java)

SOAPcalls

Publishservice

Proxy object generation from the WSDL service description

WSDL kSOAP

Service methods

RequestHandler

ResponseHandler

HTTPInterface

DeploymentInterface

2

1

0 4

3

5

Client RequestHTTP POST/GET

Client Response

kXML

SOAP Server Core Structure

Comparison

1*: Native Client2*: Java Client3*: Thin Client4*: P2P

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

+++-

---+

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

1* 2* 3* 4*

ConclusionWhy not just WAP?Mobile SOA is potentialNew and maturing paradigmSome predictions

WS-* for mobileM-CommerceMobile ServicesMobile phone as a service providerLocal web services provider on mobile phone

ReferencesExternal text file

Thank you for attentionQ&A