SERVICE-ORIENTED ARCHITECTURE in MOBILE NETWORK Long Nguyen Hoang silver@cc.hut.fi Marek Konieczny marek.konieczny@gmail.com Dec 2006
Agenda SOA overview SOA in mobile network Why Mobile SOA WS standards for mobile Mobile SOA models Conclusion
Part 1 SERVICE-ORIENTED ARCHITECTURE Start programming with Business not with Architecture
SOA - Problem Statement
SOA The Solution
A SOA System in real life Authentication and authorization services Customer relationship services Purchase E-commerce portal Credit authorization Billing services Fulfillment services
SOA Architecture Application Layer Service Layer Setup account Check customer credit Fraud check Legacy System CRM System SAP ERP System Trading partners Data warehouse Metadata, QoS, Security, Monitor, Management Business Process
SalesDB start Duplicate Number! Visual Designer Billing Router end Business process <?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> Business process description language
SOA - Definition Definition A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. (OASIS) Key technologies Interaction : SOAP Semantic : WSDL Visibility : UDDI WS Standards Advantages Reusability Interoperability Composite services Scalability, extensibility Adaptability (platform independence)
Part 2 SOA in MOBILE NETWORK 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 Environment A Service Environment B S3 S4 Mobility Controller find Service Directory S1 S2 resume find suspend register <<moves>> invoke Service suspend Composite services in different service environments A simplified view of a SOA with support for mobile device
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.) Backend System Service ABC AkertSerivce System Events (sent visa JMS) J2EE Application Server ksoap Messages (via HTTP) Mobile Phone ksoap ksoap AlertServlet SystemAlert Objects AlertServiceClient (Midlet Application)
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) Context Store WS-MFR Schema Representation Headers Stream Info 1. Negotiation over SOAP WS-MFR End-point WS-MFR End-point 2. Stream of Message in Preferred Representation
Mobile SOA Worries Intermediaries: Wireless SOAP Efficient sync/async messaging Efficient XML serialization Persistent connections across mobility Wireless system Web Service Mobile Gateway (SOAP to Binary) Mobile Device (Binary to SOAP to Objects) Internet (SOAP) Wireless (SOAP)
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 on them. Returned data is typically in XML. 3GPP Open Service Access (OSA)
WS Star Standards Connected Applications Management Business Processes Applications & Application Structure Security WS-Security Security WS-Trust WS-Federation Reliability WS-RM Transactions WS-Coordination WS-Transactions Messaging (SOAP, WS-Addressing) Metadata WSDL, WS-Policy Foundation XML UDP TCP HTTP Transport
Without federated identity 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 # 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
Liberty use case Citizen connects once through any government authority; Automatically recognized by other government services interior education Citizen authenticate to any government authority finance One sign-on opens all connected services within the circle of trust 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 Federation Framework (ID-FF) & Security Assertion Markup Language (SAML) 2.0 Liberty Identity Services Interface Specifications (ID-SIS) Enables interoperable identity services such as personal identity profile service, contact book service, geo-location service, presence service and so on. Enables identity federation and management through features such as identity/account linkage, simplified sign on, and simple session management Liberty Identity Web Services Framework (ID-WSF) 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) Parlay X WS for telecom services: call control, messaging,location, presence, charging and account management Can deploy applications within or outside of the telecom network Parlay/OSA A set of APIs to develop applications that exploiting the current and emerging features of telecom networks. Open Service Access Architecture to make use of network functionality through open standardized interface
OSA (cont) Stock Stock Quote Quote Web Web Service Service Multimedia Message MMSCWeb -X Service component Parlay X I/F 4 MMSC MMS-C 1 MM7 VASP Interface 3 5 User profile 2.. content1 =get StockQuote ().. Retrieve user Profile. messageid= sendmessage( content ). status= getmessagedeliverystatus (messageid) if status=message_waiting. fi content2 =get StockQuote () messageid= sendmessage ( content2 ) Mobile network 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 Phone Ticket Purchase Application 2 1 Network Ticket Purchase Service 4 Phonebook Application Calendar Application 5 8 7 3 Authentication & Payment Service Messaging Application 6 Usability Portability Deployability Scalability High, OS theme Really bad Need installing, OTA Not so good
Model 2 Mobile Java Client Phone Network MIDP Environment Ticket Purchase Application 5 1 Ticket Purchase Service 4 MIDP Messaging 3 Authentication & Payment Service Messaging Application 6 7 2 8 Buddylist Service Calendar Service Usability Portability Deployability Scalability Quite usable, must define own UI element Better than native, depend on MIDP Simple and easy Based on server-side
Model 3 Mobile Thin Client Phone Network Mobile Browser w/ scripting Ticket Purchase UI 1 3 2 Ticket Purchase Service Authentication & Payment Service Buddylist Service 4 Calendar Service 5 Messaging Application 7 Messaging Gateway 6 Usability Portability Deployability Scalability Good, offline problem, non-compatible with native solution Strong As simple as it gets Server side, browser support
Model 4 P2P R P R B P R P R P B Usability Portability Deployability Scalability Under investigation Good if follow the same P2P model Have to know all provider nodes Complicated, Mobile as a service provider
P2P Web Services Model Local Service Repository Remote Service Repository QoS GUI GUI Adapt GUI ation Client Proxy SOAP Security Client Transport Service XML Parser Server Software Architecture enabling P2P Web Services Java method invocations Autom. proxy gen. (WSDL2Java) Proxy WSDL SOAP calls Publish service Service Proxy object generation from the WSDL service description kxml ksoap 2 Deployment Interface 0 4 Service methods Request Handler 3 Response Handler 1 5 HTTP Interface SOAP Server Core Structure Client Request HTTP POST/GET Client Response
Comparison Usability Portability Deployability Scalability + - - - 1* 2* 3* 4* - + + + +/- +/- +/- +/- +/- +/- +/- +/- 1*: Native Client 2*: Java Client 3*: Thin Client 4*: P2P
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