2. Syllabus Points
6.1 DOM Parsing
6.2 SAX Parsing
6.3 XML Web Services
6.4 SOAP
6.5 WSDL
6.6 Key XML Technologies for Mobile Computing
3. Introduction
• The Extensible Markup Language—XML—is a subset of the Standard Generalized Markup
Language (SGML) specified in ISO standard 8879.
• SGML was created to create and maintain complex and portable documents to be used in highly
scalable systems in a nonproprietary manner to any particular vendor.
• XML has become a key technology in the development of content for the World Wide Web.
• With the birth of Web services, it is used for more than its original purpose of representing
documents.
• XML is easy to read and understand.
5. XML and Mobile Applications
Mobile applications relate to XML in the following two ways:
1. Mobile applications should understand and be able to manipulate XML content.
• As content on the Internet, and other networks, moves into an XML format, it is very
desirable that a given mobile application can handle XML.
• How the XML is handled is of particular interest. Although the task of parsing and interpreting
the XML can be done on the mobile device itself, or some proxy such as an application server that
processes all content for the device, issues such as performance become of paramount
concern.
6. 2. Mobile applications use XML to facilitate their implementations.
• For example, XML documents can be used by mobile applications to exchange data;
configuration of a device or a server may be encapsulated in an XML file; some protocols
such as WAP use XML as the means for presentation.
• There are countless places where mobile applications and related frameworks can use
XML internally.
7. • Whether the mobile application is handling XML content or using XML
internally, it must be able to construct XML documents, to parse
them, and to take actions based on the contents of the XML
documents.
• When it comes to parsing XML, there are two widespread methods:
DOM and SAX.
8. DOM Parsing
• The Document Object Model (DOM) is the tree representation of all of the XML elements.
• Every element becomes a node and nodes. Nodes can have children to support nesting of nodes in
the same way as an XML element can have other elements.
• The mapping of DOM to UML is very simple. Every node is an object, an instance of a class. The
XML attributes are the object attributes and the children nodes are encapsulated data members.
• A DOM parser written in an object-oriented language such as Java, C++, or C# goes through the
entire XML document and creates a tree of nodes, with the nodes being objects.
• DOM parsers are also required to preserve the order of elements. There may be meaning in the
order of elements. The same is not required of attributes. Figure 3.1 shows how a UML Object
Diagram can be used to represent a DOM.
10. • DOM parsers allow a convenient method for accessing any piece of data in the document. For
the DOM parser to make the data available, it has to parse the entire document; therefore, once
the parsing is done, all of the data are available.
• Because of the nature of what DOM is, it is very easy and intuitive to implement DOM parsers in
object-oriented languages or to use object-oriented languages for an application that, in turn,
uses a DOM parser.
• Although DOM parsers are a good solution for parsing of most XML, they run into performance
problems when dealing with numerous documents or unusually large documents.
11. SAX Parsing
• SAX Parser parses the XML file line by line and triggers events when it encounters
opening tag, closing tag or character data in XML file.
• This is why SAX parser is called an event-based parser
12. SAX (Simple API for XML) creates a series of events as it parses through the XML document instead of
creating an object model of the entire document in memory.
There are two key advantages that SAX offers over DOM:
1. Most of the time, we do not need all of the information in the document. So, the object model
desired does not have to have every element and attribute of the document. A custom object model in
this case is more efficient. We can write a custom object model and a driver that catches the SAX events
as the SAX parser reads through the document and emits them and fills up the custom object model.
2. We do not have to wait for the entire document to be processed before using the contents of the
document. For very large documents, DOM becomes problematic as it has to load the entire document
into memory before it makes its contents available. In contrast, as a SAX parser progresses through
processing a document, it emits events; therefore, by nature, it allows immediate processing of the
information
13. WEB SERVICES
What is Web Service?
• Web service is a standardized medium to propagate communication between the client and server
applications on the WWW (World Wide Web). A web service is a software module that is designed
to perform a certain set of tasks.
• Web services are a set of protocols and standards that enable different applications or systems to
communicate with each other over a network (usually the internet).
• These services allow for the exchange of data and functionality between different software
applications, often across different platforms and programming languages.
14. WEB SERVICES
• In the present world, applications are developed on a variety of programming languages such as
Java, Python, PHP, etc.
• These heterogeneous applications need communication to happen between them. Since they are
developed in different programming languages it becomes difficult to ensure efficient
communication between them.
• Here is where web services come into the picture, web services provide a language-independent
way of communication that means the applications working on Java can communicate with
other applications working on Python.
• Therefore, web service helps us to invoke the functionality of other programs in the existing
program.
16. WEB SERVICES
Why application needs to communicate
• While working, some applications might need to use the service or functionality offered by other
applications.
• To use that service or functionality applications need to communicate with each other.
• Let us consider an example of a restaurant, when you visit the restaurant and ask for the food(a
service) then the waiter will be taking the order to the kitchen and serve you prepared food from the
kitchen. Here the waiter is like the web service which allows you(.i.e. client) to communicate with the
kitchen(.i.e. application).
• The figure below shows another example of how the ICICI bank ATM used the service provided by SBI
bank to access the database of the customer which cannot be accessed by the ICICI bank ATM directly.
18. WEB SERVICES
How do web services work?
• Web services use the request-response method to communicate among applications.
• For any communication, we need a medium and a common format that can be understood by
everyone, in the case of web services medium is the internet and the common format is the XML
(Extensible Markup Language) format as every programming language can understand the XML
markup language.
• A client is the one that requests some service from the server that is known as the service provider.
• The request is sent through a message which is in common XML format and in response to that
request, the service provider will respond with a message in a common format (.i.e. XML).
19. WEB SERVICES
Web Service Components
1. SOAP: SOAP stands for Simple Object Access Protocol. It is the protocol stating how the communication
between the application is going to happen.
2. WSDL: It stands for Web Services Description Language which is the XML document containing the rules for
communication among different software. It defines that:
• How that service can be accessed by the system requesting for it from other systems
• What is the name of the service
• What are the specific parameter needed for accessing that service, what would be the return type
• What are the error messages that would be displayed in case of any issue while accessing the data.
3. UDDI: Universal Description, Discovery, and Integration is the full form for the UDDI. It is a directory that
provides us the detail that which software needs to be contacted for the particular type of data.
20. XML WEB SERVICES
• XML Web Services are a way to enable communication between different applications or systems
over the internet using XML as the message format.
• They allow applications built on different platforms to interact with each other, facilitating
interoperability in a distributed environment. Let's break it down:
21. XML WEB SERVICES
Key Concepts:
• Web Service: A web service is a method of communication between two devices or applications
over the internet. It exposes a set of functions or operations that other applications can invoke,
typically through HTTP.
• XML (Extensible Markup Language): XML is used as the data format for communication in XML
Web Services. It provides a structured and human-readable format for exchanging information.
• SOAP (Simple Object Access Protocol): This is the protocol often used for XML Web Services. SOAP
is an XML-based messaging protocol that defines how the information (request and response) is
structured and transferred over a network.
22. XML WEB SERVICES
Key Concepts:
• WSDL (Web Services Description Language): WSDL is an XML-based language used to describe the
web service. It defines the service methods, input/output parameters, and communication
protocols, serving as a contract between the service provider and the consumer.
• UDDI (Universal Description, Discovery, and Integration): UDDI is a directory service where
businesses and developers can publish and discover available web services. It's essentially a
registry for web services, though it's not as widely used today.
23. How XML Web Services Work:
Client Requests: A client application sends a request to the web service, often using the HTTP
protocol. This request is usually structured as an XML message formatted according to the WSDL.
SOAP Request: The request message is typically a SOAP request, which is an XML document that
specifies the operation to be performed along with any necessary parameters.
Web Service Processes: The web service receives the SOAP request, processes it, and generates a
response.
SOAP Response: The response from the web service is also typically an XML document, following the
structure defined by the WSDL. This response is sent back to the client.
Client Receives Data: The client parses the XML response and uses the information as needed.
24. SOAP – Simple Object Access Protocol
• SOAP is an acronym for Simple Object Access Protocol.
• It is an XML-based messaging protocol for exchanging information among computers. SOAP is an
application of the XML specification.
• It uses XML format to transfer messages. It works on top of application layer protocols like HTTP and
SMTP for notations and transmission.
• SOAP is a communication protocol designed to communicate via Internet.
• SOAP can extend HTTP for XML messaging.
• SOAP provides data transport for Web services.
• SOAP can exchange complete documents or call a remote procedure.
• SOAP is platform- and language-independent.
• SOAP is the XML way of defining what information is sent and how.
• SOAP enables client applications to easily connect to remote services and invoke remote methods.
25. The structure of a SOAP message
• A SOAP message is encoded as an XML document, consisting of an <Envelope>
element, which contains an optional <Header> element, and a mandatory
<Body> element. The <Fault> element, contained in <Body>, is used for
reporting errors.
• The SOAP envelope
• <Envelope> is the root element in every SOAP message, and contains two child
elements, an optional <Header> element, and a mandatory <Body> element.
26. The structure of a SOAP message
• The SOAP body
• <Body> is a mandatory subelement of the SOAP envelope, which
contains information intended for the ultimate recipient of the
message;
• The SOAP fault
• <Fault> is a subelement of the SOAP body, which is used for reporting
errors;
27. The structure of a SOAP message
https://www.ibm.com/docs/en/integration-bus/10.0?topic=soap-structure-message
28. The structure of a SOAP message
https://www.ibm.com/docs/en/integration-bus/10.0?topic=soap-structure-message
Content-Type: application/soap+xml
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope">
<env:Header>
<m:GetLastTradePrice xmlns:m="Some-URI" />
</env:Header>
<env:Body>
<symbol xmlns:p="Some-URI" >DIS</symbol>
</env:Body>
</env:Envelope>
29. WSDL
• WSDL is a powerful tool for describing web services, particularly for SOAP-based services. It
provides all the necessary details about how to interact with the service, such as available
operations, data types, and communication protocols.
• WSDL (Web Services Description Language) is an XML-based format used to describe the
functionality of web services.
• It provides a standard way for service providers to describe the available operations and for
service consumers (clients) to understand how to interact with those operations.
• WSDL is used to describe both SOAP-based web services and RESTful services (though RESTful
services are typically described using other specifications like OpenAPI)
30. A WSDL document defines the following:
Type: A Web service may define its own data types in this section of the WSDL
document. WSDL types must be based on XSD (XML Schema, the W3C standard)
data types.
Message: This section of a WSDL document defines the format of the messages
being passed around among the different nodes. For example, in the case of SOAP,
this would be the definition of the SOAP Envelope.
Operation: This section of the document defines the various services offered by the
Web service. Think of this as the metadata for the remote procedure calls that each
Web service exposes.
31. Binding: WSDL does not force binding to a particular transport protocol. Moreover, most (well-
designed) Web services do not force binding to a particular protocol. In the binding section of the
WSDL document, we can define what protocol bindings are possible for a given Web service and
how those bindings are supported. It is also important to note that binding does not have to be to a
particular type of protocol.
For example, WSDL could be used to describe a Web service that is built on top of SOAP, which
in turn could be using HTTP for its transport protocol. Or, alternatively, it could be used to
describe a Web service built on top of HTTP itself (with messages that are in the XML format to
preserve the definition of a Web service).
32. Port: Specifies the address or endpoint where the web service is accessible. Each <port>
element corresponds to a specific binding, and thus a specific communication protocol.
Port Type: Defines the abstract interface for the web service. This element groups a set of
operations that the web service can perform. Each operation specifies an input and an
output message.This is similar to an interface in programming
Service: Service is the high-level abstraction that allows grouping of end points and
operations to create a Web service.
33. Web Services and Mobile Applications
Web services and mobile applications can be related in two ways:
1. Web Service Proxy:
• The infrastructure of mobile applications can use Web services for messaging.
• For example, a given system may allow mobile users to find someone’s phone number through a directory
service and subsequently get the driving directions to that person’s place of residence. These two functions,
finding the phone number and the driving directions, may be fulfilled by two different systems, each
implemented in a different environment. So, the back end for our mobile system may use Web services to
connect to each one of these systems and retrieve the information we need to return it to us.
• The interface between the back-end system and the device remains consistent and can be implemented
through whatever communication protocol may be necessary. This is the more likely scenario for most
systems. Figure 3.3 shows a mobile device using services offered by several Web Services through a gateway.
35. 2. Direct Connection to Web Services:
• Mobile devices with more resources can directly access the network through the use of Web services
(see Figure 3.4).
• Of course, this requires a considerably advanced mobile device as we have to have very efficient
XML parsing as well as the ability to write substantial applications that implement the application
of XML that supports the particular Web service to which the mobile device must connect to.
• The clear advantage of such an implementation is the elimination of the proxy and the direct usage of
the service by the device.
36. 2. Direct Connection to Web Services:
• Mobile devices with more resources can directly access the network through the use of Web services
(see Figure 3.4).
• Of course, this requires a considerably advanced mobile device as we have to have very efficient
XML parsing as well as the ability to write substantial applications that implement the application
of XML that supports the particular Web service to which the mobile device must connect to.
• The clear advantage of such an implementation is the elimination of the proxy and the direct usage of
the service by the device.
37. 2. Direct Connection to Web Services:
• An example of a technology that allows us to do this is XForms.
• It provides a generic user interface markup language that can be specialized for a particular user
interface.
• Specialization may be done at the receiving node (in our case the mobile device) or at a sending node
(server, peer, etc.).
• The beauty of XForms is that it allows for binding to any transport protocol.
• Therefore, we can bind XForms to use a Web service, thereby allowing the mobile device to
communicate directly with various available Web services.
39. KEY XML TECHNOLOGIES FOR MOBILE COMPUTING
• Some standard applications of XML have been specifically designed with mobile applications in mind.
Standardization of such applications of XML is required to provide interoperability between disparate
systems.
• As we mentioned previously, mobile applications should be able to handle XML content. This may
mean parsing the content to take some actions based on the content, transforming the content for
various user interfaces, or using XML as the metadata for handling various types of content.
• There are a set of standards by W3C and proprietary recommendations by various vendors that apply for
these cases. We will focus on standards recommended by W3C as they are typically more encompassing
than proprietary recommendations. These standards apply across various vendors that either base their
interface to their products on W3C standards or provide interoperability with them.
• Before we begin a survey of these technologies, we must look at one key XML standard that is used by
most other applications of XML, XML Schema.
40. XML Schema
• XMLSchema is an application of XML to define the type of elements and attributes, the structure of the
elements, and any constraints on the elements and attributes of a given XML document.
• The XML Schema namespaces begin with xs;
• XML Schema allows us to build new data types and to reuse those data types across multiple documents
with xs.
• Many XML applications use XML Schema to define new data types that can be reused within the namespace
of the given XML application, to define the structure of the various elements within an instance document of
the particular XML application, and for allowing the developers to place constraints on the data defined
within the XML application.
• XForms is such a sample application that uses XML Schema. The XForms definition is written in XML Schema:
Its data types and structure are defined by the XML Schema–based document that defines XForms.
41. XML-Based User Interface Technologies for Mobile Applications
• XHTML is an attempt at cleaning up the HTML syntax and providing a version of HTML that is an
application of XML. XHTML allows for development of GUIs using a thin-client model where the XHTML
browser renders a GUI.
• Voice Extensible Markup Language (VXML) is another application of XML specifically designed for voice
user interfaces. VXML allows specification of a command-based voice dialog through a markup language.
• XForms is an application of XML . XForms allows us to build user interfaces with a focus on the
interactions and data exchanges between the user and the user interface as opposed to specific types of
user interface. XForms allows us to separate concerns among presentation logic specific to the
application, the presentation logic specific to the device, the data exchanged between the user and the
system, and the interaction flow.
42. CCXML
Call Control Extensible Markup Language (CCXML) is an application of XML for managing voice calls. Whereas VXML
defines user interfaces for the interactions between a user and a voice-recognition system or a text-to-speech
engine, CCXML focuses on routing the calls and connecting calls. CCXML is specific to the telephony part of voice
user interfaces.
XML Pipeline
XML Pipeline is a W3C recommendation that specifies how to process various XML resources.
WBXML
The WAP Binary Extensible Markup Language (WBXML) format defines a way to represent XML in 0’s and 1’s instead
of text. The primary purpose of WBXML is to reduce bandwidth requirements on transporting XML documents.
SSML
The Synthetic Speech Markup Language (SSML) is an example of an application of XML that addresses a specific
functionality API. SSML and other markup languages that address syntax serve mostly to get rid of proprietary APIs.