SERVICE-ORIENTED ARCHITECTURE
Dec 2006
Long Nguyen [email protected]
Marek [email protected]
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