Next Generation Mobile Systems 3G and Beyond phần 8 pdf

264 WIRELESS WEB SERVICES Year 1996 2004 Small Footprint Wireless Web Services 2000 2008 Web Services XML SOAP WSDL WSCI BPEL4WSUDDI KXML KUDDI KHTTP KSOAP Binary XML Ubiquitous Wireless Web Services - Quality of Service - Server Capability Specification - P2P Support - Disconnection Support - Energy Efficiency Figure 9.4 Current activities and future directions for wireless web services desktop PCs or picture-hosting websites, soon pictures taken by cell phone users will be directly accessible via web service invocations to cell phones. Figure 9.4 shows current activities and future directions in wireless web services area, along with activities in the general web services field. It divides activities in wireless web services into two generation: the Small Footprint Era, and the Ubiquitous Era. While current activities in this field have mainly focused on achieving small-footprint implementations, we project that future work in this area will target supporting ubiquitous access of wireless web services. Some of the research directions include • energy efficiency, as smaller footprint does not necessarily translate to less energy consumption; • specifications for wireless web service server capability on mobile devices, so that mobile device manufacturers and system software developers can meet the minimal requirements for running web services on wireless devices; • peer-to-peer support, so that a mobile device can provide service to, and get service from, peer devices in an ad hoc network; • disconnection support, so that mobile devices can cache web services to deal with disconnection and weak connection; • quality of service support, so that predictable level of service quality can be guaranteed in a less predictable mobile environment. The rest of this section describes in detail each of the web service technologies and their small-footprint implementations on mobile devices wherever applicable. While kXML, kUDDI, kHTTP and kSOAP are important web service technology implementations for mobile devices, there are also parallel works in each respective areas. We will cover some of them to give the reader a broader view of the field. WIRELESS WEB SERVICES 265 9.3.1 Communication Technologies We b Service Communication Technologies Web services are communicated via the network layer. This layer encompasses a wide variety of network protocols, such as HTTP, SMTP, FTP, Remote Method Invocation (RMI), and so on. The network protocol used in web services depends upon the web services’ application requirements. For those web services that are accessible on the Internet, the network protocol choice may favor the ubiquity of the network protocols, such as HTTP. Alternatively, other net- work protocols can be used for message exchange over the Internet, provided that service requesters and service providers agree upon the use of these network protocols. On the basis of the application requirements, such as security, performance, and reliability, other protocols (such as SSL) can be used. The web services stack does not specify which network protocol to use; the message layer developers are responsible for the specifications using message-to-network binding. This network protocol specification is hidden from the application and service developers. HTTP for Small Wireless Devices kHTTP is a small HTTP server for resource-constrained mobile devices. It contains a small memory footprint runtime module and a set of programming APIs. Although the target platform of kHTTP is J2ME platform, its interfaces can be ported to any mobile platform. kHTTP can operate in two modes: the normal mode and the proxy mode. In the normal mode, a kHTTP server, like any normal HTTP server, is accessible by a direct HTTP request via the network. In the proxy mode, a kHTTP server is communicated via a HTTP proxy server, which sits between the kHTTP server and the client. Figure 9.5 shows the kHTTP server in the normal mode. The normal mode makes use of a class called StreamingConnectionNotifier in the CLDC connection framework that may not be available to many MIDP 1.0 implementations, because MIDP 1.0 specification only specifies HTTPConnection as the mandatory network connection. The MIDP 2.0 specifica- tion (JSR 118) (JCP n.d.a) has responded to these needs by adding support for socket and datagram; thus, providing mobile applications with more-capable networking interfaces that are available with the CLDC connection framework. However, such an addition is optional, Figure 9.5 kHTTP server in normal mode 266 WIRELESS WEB SERVICES Figure 9.6 kHTTP server in proxy mode which means a J2ME 2.0 implementer can select the support for such interfaces on the basis of the target market segments and devices. Also, if a mobile device is on a private network (such as one using NAT) or behind a firewall, the mobile device cannot be accessed by direct HTTP requests. To support a HTTP server in those devices, kHTTP can operate in the proxy mode, in which a HTTP proxy sits between the mobile device and its clients. The HTTP proxy server defines and implements an [HTTP Server Proxy] protocol that replays HTTP requests and responses between a client and the kHTTP server. Figure 9.6 shows kHTTP server in the proxy mode. To conserve memory consumption on mobile devices, kHTTP implements a subset of the HTTP server, including receiving requests and sending responses. It does not support any memory-intensive functions, such as load balancing or name-based virtual hosting. PocketHTTP is another HTTP client implementation targeting small devices (Fell 2004). It is an HTTP/1.1 client COM component running on Microsoft Windows plat- forms, including PocketPC. It is part of the PocketSOAP project (see Section 9.3.2). PocketHTTP supports features, such as chunked encoding and persistent connections, SSL support including SSL via proxy servers, compression support including the abil- ity to compress the request body, server authentication, proxy server, session cookies, and redirects. More information on PocketHTTP can be found at its project homepage (http://www.pocketsoap.com/pocketHTTP/). 9.3.2 The Base Technology – XML XML and Web Services XML is a simple approach for marking up content with tags to convey information. The tags delimit the content and they are expressed in a natural language to provide a human- readable XML syntax. An XML document is in an ordinary text document, making it a widely accepted solution for exchanging information between different platforms. Unlike markup languages that have tags with fixed semantics such as HTML, XML allows users to assign arbitrary names and semantics to tags. These features make XML easy to program and extend. XML is the backbone of the web service architecture. It provides the extensibility, platform independence, and language neutrality that are keys to the loosely coupled and standards-based application interoperability. This interoperability is the essence of the web services value proposition. WIRELESS WEB SERVICES 267 XML for Small Wireless Devices The kXML project provides an XML pull parser that is suitable for all Java platforms, including J2ME. Because of kXML’s small footprint size, it is especially suitable for Java applications, such as Java MIDP applications on mobile devices. KXML features include: • XML namespace support • A relaxed mode for parsing HTML or other SGML formats • A small memory footprint • A pull-based parser for parsing XML structure • XML writing support including namespace handling • An optional kDOM • Optional WAP support (WBXML/WML). The parser generates different events for different elements: • It generates a START DOCUMENT event when it first encounters the start of an XML document. • For each XML element, it generates a START TAG event when it encounters a starting tag of an XML document. • It generates a TEXT event when it reads the textual content of an XML element. • For each XML element, it generates an END TAG event when it reaches the end of an XML element. • When it reaches the end of the document, it generates an END DOCUMENT event. Because the parser does not keep track of the XML document elements and their content (it passes these information to applications), the memory consumption of the pull-based parser is minimal and is suitable for memory-constrained mobile devices. There have been considerable interests in using binary XML on mobile devices. As early as 1999, Ericsson, IBM, Motorola, and Phone.com submitted the WBXML note to the World Wide Web Consortium (W3C) on WAP binary XML content format (Martin and Jano n.d.). In 2003, W3C organized a workshop specifically targeting the binary interchange of XML information, whose participants included major industry players within and out of the mobile communication business (W3C 2003b). One of the interesting systems presented in this workshop is esXML and its canonical API: esDOM (Williams 2004). esXML (or Efficiency Structured XML) and esDOM target XML and network applica- tion efficiency problems in data parsing, serialization, binding, allocation, and programming verbosity. It is a new portable structure that retains all XML features. Its representation is preparsed; its design reduces overheads in reading, traversing, transforming, and generates documents or data. It introduces new semantics including efficient pointers, copy-on-write layering of changes to a base document, and direct representation of binary content, such as images. 268 WIRELESS WEB SERVICES 9.3.3 Messages – SOAP and its Extensions SOAP and Web Services SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between server requesters and service providers in a decentralized and dis- tributed environment. SOAP message syntax is based on XML. In fact, a SOAP message itself is an XML document. SOAP consists of three parts: the SOAP envelope, the SOAP encoding rules, and the SOAP RPC. • The SOAP envelope defines an overall framework for expressing what is in a message, who should handle it, and whether it is optional or mandatory. • The SOAP encoding rules define a serialization mechanism that is used to exchange instances of application-defined data types. • The SOAP RPC defines a convention that is used to represent RPC and responses. A SOAP message can be used in combination with or be re-enveloped by a variety of network protocols, such as HTTP, FTP, and RMI. The basic requirement for a node in the network to participate in SOAP message exchange is the ability to build and parse a SOAP message and the ability to commu- nicate over the network. Applications that communicate with web services using SOAP can be executed in four basic steps as shown in Figure 9.7: • An application acting as a service requester constructs a SOAP message. The SOAP message is the request to the service provider to invoke a web service. The XML document in the SOAP message body can be a SOAP RPC request or a document message describing the operation of the web service according to WSDL. The appli- cation passes the SOAP message and the network address of the service provider to the SOAP runtime. The SOAP runtime then interacts with the underlying network protocol to send the SOAP message to the service provider. Figure 9.7 XML/SOAP message WIRELESS WEB SERVICES 269 • After the service provider’s SOAP runtime receives the SOAP message, the SOAP runtime converts the XML message in the SOAP body to programming language- specific objects that can be understood by the service provider and passes it to the service provider. • The service provider then processes the request message and creates a response. The response is encapsulated in a SOAP message. The service provider passes the SOAP message response to the SOAP runtime with the service requester’s network address. The SOAP runtime coordinates with the network protocol to send the SOAP message response back to the service requester. • After the SOAP message response is received by the service requester’s SOAP runtime in the service requester, the SOAP runtime converts the XML message in the SOAP body to objects that are understood by the service requester application and passes them up to the application. SOAP message exchanges between the service requester and service provider can be synchronous or asynchronous. They can also be performed in different modes: one-way messaging, notification, or publish/subscribe. SOAP provides mechanisms that can be used to extend SOAP’s capabilities. Examples of SOAP extensions include WS-Reliability (Sun n.d.b) and WS-security (IBM n.d.). The SOAP extensibility model provides two mechanisms to add extensions: the SOAP process- ing model and the SOAP protocol binding framework. The former describes the behavior of a single SOAP node with respect to the processing of a SOAP message. The latter mediates the interaction of sending and receiving SOAP messages between SOAP layer and network protocol. The SOAP processing model enables SOAP nodes to extend their capabilities by includ- ing such features in the SOAP header blocks of the SOAP envelope. Such header blocks are intended for any SOAP nodes that can recognize such features when processing SOAP messages. SOAP protocol binding operates between two adjacent SOAP nodes along a SOAP path. There is no requirement that the same network protocol to be used for all hops along a SOAP message path. This allows a SOAP node to specify the network protocol to be used between hops flexibly. There are also cases that a single network protocol is used along the entire SOAP message path. SOAP for Small Wireless Devices kSOAP is an SOAP API for J2ME based on kXML. The feature set of kSOAP is a subset of the SOAP 1.1 features. kSOAP supports basic functions for handling SOAP envelopes, such as reading/writing the content of SOAP headers and reading/writing the content of SOAP body. kSOAP also supports serialization/deserialization of SOAP messages and supports for transports of SOAP messages via HTTP network. PocketSOAP is a SOAP client COM component for the Pocket PC platform (it also has a Win32 version that supports other Microsoft Windows family platforms) 1 . PocketSOAP is open source. It uses PocketHTTP as default transport although other transports can be 1 For more information on PocketSOAP, see http://www.pocketsoap.com 270 WIRELESS WEB SERVICES easily added as well. It uses Expat XML Parser to parse SOAP response messages. The main features of PocketSOAP include support for Section 5 encoding, support for attachments (both DIME and SOAP with attachment), support for both 1999 and 2001Schema versions, and support for integration with the Win32 development environment (such as serialization of persistent VB objects). 9.3.4 Web Services Discovery (UDDI) UDDI and Web Services The discovery of a web service can take place at different times in the overall web service lifecycle. At one extreme, web service discovery can be purely static. The service requester already knows, or has an agreement with, a specific service provider. The service requester can search for that service provider from a registry and integrate with the provided service at the application development time. At another extreme, web service discovery can be purely dynamic. The service requester has only a list of service requirements. The service requester dynamically searches for a service provider that can fulfill its requirements and compose with the service just prior to the actual service execution. The Universal Description, Dis- covery and Integration (UDDI) (UDDI n.d.) of web services specification accommodates both types of web service discovery. UDDI defines the XML-based interfaces such that service requesters can find a desired service from service registries. UDDI is a group of web-based registries that expose information about a web service interface published by service providers. UDDI registries are distributed over the Internet and administrated by different organizations. By accessing the public UDDI registries, one can search for information about web services. The information can help a service requester determine “who, what, where, and how” to interact with a particular web service. The contact information in UDDI specifies who. The web service classification based on industrial codes and products specifies what. The registered web service’s address, such as a URL, where a service can be accessed, specifies where. Finally, registered web service’s service interface reference specifies how. This reference is called a tModel in the UDDI specification. A UDDI entry in a UDDI registry starts with a businessEntity element. A businessEntity element contains information about a business, including basic business information, such as the name of the business. A businessEntity element is a collection of businessService elements. A businessService element represents a web service. Each businessService element contains technical and descriptive information about the web service. A businessService element contains a collection of bindingTemplate elements. A bindingTemplate element describes how the businessService element uses various tModels. Figure 9.8 shows the structures of elements in a UDDI entry. Technical Model (tModel) A tModel is a data structure that represents a service type registered in a UDDI registry. Each registered web service is categorized on the basis of the service type. This categorization enables service requesters to find a web service or service provider by searching the service types. Each tModel consists of a name, a service description, and a Universal Unique Identifier (UUID). The tModel name corresponds to a service type, for example, uddi-org:http. The tModel description provides more information about the service, for example, an http or web browser-based web service. The tModel UUID, also known as the tModelKey, is a series WIRELESS WEB SERVICES 271 Figure 9.8 UDDI entry structure of alphanumeric characters for identifying the service type, for example, uuid:68DE9E80- AD09-469D-8A37-088422BFBC36. The above example is a tModel, which describes a web service that is invoked through a web browser and the HTTP protocol. Mapping WSDL and UDDI The mapping of WSDL and UDDI maps each WSDL elements to a separate UDDI entity, and therefore accurately represents the WSDL structure and semantics. portType and binding elements in WSDL map to a tModel in UDDI. WSDL service element maps to a UDDI businessService element. WSDL port element maps to bindingTemplate element. Figure 9.9 shows the mapping between WSDL elements and elements in UDDI version 2. A web service description can be published in a variety of ways and can be published to several service registries. The simplest way of publishing a service description is with a direct publish. A direct publish means that a service provider sends a service description directly to a service requester. This can be done via e-mail, FTP, or media distribution (such as a CD-ROM). A direct publish occurs after a service provider and a service requester have established a partnership over the Internet. A more dynamic publishing way is to publish service description on one or multiple service registries. Several types of service registries can be used depending on how a web service is used. Internal UDDI registry – Web services that are intended for use within an organization should be published to an internal registry. The scope of this internal registry can be departmental or enterprise level. The service registry is behind organization’s firewall and is not accessible from the outside. Figure 9.10 shows the diagram of internal registry. Portal UDDI registry – Web services can be published to a portal registry for external part- ners. A portal registry is outside a service provider’s firewall and between firewalls. The portal registry only contains service descriptions that an organization wishes to provide to its partners. Usually, a role-based controls system is installed in the portal 272 WIRELESS WEB SERVICES Figure 9.9 WSDL to UDDI v2 binding Figure 9.10 Internal UDDI Registry WIRELESS WEB SERVICES 273 Figure 9.11 Portal UDDI Registry registry to limit the visibility of services to authorized partners. Figure 9.11 shows the diagram of portal registry. Partner UDDI registry – If web services from a service provider are intended for a par- ticular partner, the web services can be published to its partner’s registry. The partner registry is behind the partner’s firewall. The partner registry contains only tested, legitimate service descriptions. Figure 9.12 shows the partner registry. Public UDDI registry – A service description can be published to one or more public registries to compete in an open market. The public registry can be hosted by organi- zations, such as standardization bodies or consortiums, or by organizations that build their business around content hosting. The public registry is accessible by any service requester who searches for services. UDDI for Small Wireless Device kUDDI is an effort to port UDDI4J (JCP n.d.b), a heavy Java API library for interactions with UDDI registries, to the J2ME platform. In contrast to UDDI4J, which allows SOAP messages to bind with different network transport protocols, kUDDI is based on a simple kSOAP implementation that only allows HTTP connections. kUDDI does not support a Figure 9.12 Partner registry [...]... encryptions of RAND with the key Ki using the encryption algorithms A3 and A8 – that is, XRES = A3Ki (RAND) and Kc = A8Ki (RAND) 290 CRYPTOGRAPHIC ALGORITHMS AND PROTOCOLS FOR XG The base station transmits the challenge RAND to the mobile station Assuming the mobile station’s SIM contains Ki , it can set is response SRES to be A3Ki (RAND) Finally, the base station completes authentication of the mobile station... services can be solely run on XG mobile devices Industrial leaders in mobile network and mobile computing areas have formed OMA on standardizing mobile service architectures and interfaces to enable new services for mobile users One working group in the alliance is working on the web services specifications to ensure the integration and interoperability of mobile network operators and various VASPs Part IV... authentication of mobile stations to base stations and to protect the confidentiality of subscribers’ data and identity information Of course, to get this functionality, the mobile station and the network must share a common secret key In GSM, secret-key distribution is handled as follows A subscriber’s mobile station consists of two items – a mobile handset (which is not, by itself, security enabled) and a smart... in the XG mobile network, namely, cryptography, AAA, and secure code We begin with Chapter 10, which discusses the fundamental issues in cryptography as they apply to network systems Chapter 10 first covers some cryptographic techniques that are currently used in 2G and 3G systems This includes secret-key cryptography, as used in GSM and 3GPP systems, public-key cryptography, as used in SSL, and proposal... algorithms’ details were leaked Mobile Station Radio Link Base Station Microwave Link Auth Center RAND RAND RAND Ki Authenticated Ki YES A8 A3 SRES SRES = XRES? XRES A3 NO Not Authenticated Kc Plaintext Plaintext A5 Ciphertext Ciphertext A5 Kc Plaintext Plaintext Figure 10.1 GSM authentication, cipher key generation and encryption A8 CRYPTOGRAPHIC ALGORITHMS AND PROTOCOLS FOR XG 291 and reverse-engineered In... KASUMI for use in third -generation mobile phones 10.2.2 GSM The Global System for Mobile Communications (GSM) standard, implemented in most mobile phones worldwide as of 2003, is an interesting case study in the use of symmetric cryptography for encryption and authentication, as well as an object lesson in standardizing cryptosystems In terms of security, GSM’s goal is to make the mobile phone system as... with energy and bandwidth constrains, defines easier procedures for service configuration and deployment, and provides better protection from malicious attacks For example, part of this specification could be a Java server platform tailored for wireless mobile devices, and another part of the specification could be on the protocol between a mobile web server and its reverse proxy (see (Wessles and Claffy... viruses, scams, and outright sabotage There is every cause to believe that these threats will spread to mobile wireless networks, and XG mobile networks will become a target as they become popular and ubiquitous In fact, wireless spam is already a significant problem in 3G mobile networks, and operators such as DoCoMo are moving aggressively to curtail it The second reason is that XG mobile networks... without having to break any of the symmetric cryptosystems Even more troubling, the symmetric cryptosystems themselves – A3, A8 and A5 – have serious flaws In 19 98, Wagner et al (Briceno et al n.d.) found an attack on Comp1 28, the algorithm used as A3 and A8 by many operators To extract a SIM’s secret key Ki , an adversary needs about 150,000 chosen RAND-SRES pairs, which an adversary can easily get... WIRELESS WEB SERVICES 281 We expect research in this area will leverage and expand related research in peer-to-peer systems, and corresponding development will mingle industry efforts in both peer-to-peer computing and web services (see (Oreilly 2001) and (Gartner n.d.) for early attempts) One of the research focuses will be on the publishing and discovering of services in ad hoc networks, and the security, . series WIRELESS WEB SERVICES 271 Figure 9 .8 UDDI entry structure of alphanumeric characters for identifying the service type, for example, uuid:68DE9E80- AD09-469D-8A37- 088 422BFBC36. The above example is. leverage and expand related research in peer-to-peer systems, and corresponding development will mingle industry efforts in both peer-to-peer computing and web services (see (Oreilly 2001) and (Gartner. Services and the Open Mobile Alliance The explosive market growth of mobile devices prompts new service enablers based on open standards, such as MMS, Java, and XHTML, to provide new services for mobile