Web Services and Mobile Applications XML

The same Web service can be accessed from any application that includes both a desktop application and a mobile application. In addition, these applications can run on various devices, including a mobile phone, a Pocket PC, a regular PC, and so on. This implies that regardless of the devices that the end users use, your applications can connect to the same Web service and access the Web methods and other features of the service.

Web services provide a standard SOAP-based communication protocol for devices of different kinds and applications built on different platforms. Because the Web services are also language independent, you can build the clients by using languages that are most suited to a particular device or platform. This flexibility of creating applications in any language allows you to leverage your services to any mobile device. In addition, it extends tremendous benefit to the end user.

Consider an example of how you can use a variety of Web services in a single application for a mobile traveler. This imaginary application is a travel manager that provides basic information about an upcoming trip. It keeps track of hotel reservations, car rental, and flight reservations, and it also provides the user with the status of reservations data.

The users could simply store this static information in a data file on their PDAs. However, if you want to offer updated data or allow users to access the same information from their mobile phone, you need to take advantage of Web services. The application that uses Web services in this scenario should work as explained in the following paragraph.

When a user executes the application, it uses a Web service to display the itinerary that the travel agent provides. Then the user downloads the required information to a device. Next, to see the flight details, the user selects the flight, and a Web service contacts the airline. The user can also use a Web service to access the weather conditions at the destination location and accordingly pack the luggage for the trip. Finally, using a separate Web service, the user can arrange for car rental and update the itinerary back to the travel agent.

Although this scenario seems complicated, the end user only needs to access a single application. However, at the back end, the application uses six Web services from five Web service providers. The significant aspect of using Web services is that the back-end Web services are unaffected by the type of device they are interacting with. You could have easily accessed the same functionality from a mobile phone application that is based on Wireless Application Protocol (WAP), a Java client, or a C# application. Various platform vendors have created new toolkits to ease the development process of consuming Web services on their particular platform. You will learn about the toolkits used to create mobile applications that consume a Web service in the section "Devices and the .NET Framework."

Issues with Web Services

The whole scenario of accessing Web services looks great, but it has certain limitations, especially when a Web service is used in a wireless environment:

  • Web services might be verbose when required to transfer large documents to a device. The typical bandwidth of current and emerging Wireless LAN services, including the latest 2.5-generation networks, is measured in tens of kilobits per second (Kbps). At times, this bandwidth can be above 100Kbps, which can be compared to a fast desktop dial-up connection but not a LAN connection.
  • Web services can be slow because SOAP transfers XML over HTTP, which is a rather slow protocol. The system of transferring a message over HTTP can take time to make its way over the wire, process it, and send a response. The situation can be worse if a wireless device is accessing the Web service.
  • Another important issue while you're using Web services is obtaining up-todate information about Web services and their availability. Consider a situation in which a Web service published by an organization is registered in the UDDI directory. Perhaps the organization changes the URL to access a Web service or stops publishing the Web service, but it does not update the directory. As a result, the directory has an incorrect entry. This is a common scenario that results in several inaccurate or inaccessible Web services registered with the UDDI.

Note?/td>A recent survey shows that more than 48 percent of UDDI entries are invalid. This means that almost one out of every two Web services published in the UDDI directory is no longer available.

Mobile applications must be designed to compensate for devices' limited size and power. Web services can then be a perfect fit for mobile users who allow them to identify and use highly specific services as and when required. However, Web services have a number of 445 limitations that limit its potential for mobile users. These limitations are discussed in the following list:

  • When you access an application from a mobile device, the negotiation and discovery of the application requires multiple network round trips. In such a case, if the wireless networks on which mobile users rely have high latency, the overall performance of the application is affected.
  • Large documents might be unsuitable for processing on a mobile device. They might require greater working memory to store than is available in a mobile device. Large documents might also require more processing power to parse than is currently available. If a service is accessed from a mobile device with limited memory and processing power, the application will send inappropriate responses that a mobile application might use.
  • Web services depend on the availability of the network. Although they are a wonderful mechanism for separating a specific functionality from the software, they are located across a network. Users want to use their software while on the road or in low bandwidth conditions. Software designers should ensure that their applications that use Web services function accurately even if the network is unavailable. Because mobile devices are typically on the edge of the network and are constantly losing network connections, providing a good user experience will be extremely difficult. Therefore, software designers should make special efforts to provide an offline experience that is equally seamless to the online connection.
  • Device limitations are a major challenge. The highest-end PDAs in today's world run at hundreds of megahertz (MHz) and offer 64 megabytes (MB) of memory. However, it is hopeful that according to Moore's Law, the next generation of devices will be able to cope with large and complex documents. As a result, Web services will be a mainstream of mobile communications.

Devices and the .NET Framework

In the new programming world of .NET, devices are becoming first-rate players in total solutions that involve Web access, wireless connectivity, mobility, and access to server and the Internet information through Web services. As a result, several toolkits are available for creating applications that are targeted at various devices. The following list discusses some of the commonly used toolkits available to create applications for various devices.

  • .NET Compact Framework (CF)
  • Smart Device Extensions (SDE) for Visual Studio .NET
  • Microsoft Mobile Internet Toolkit

We will now discuss these toolkits in detail.

.NET CF

The .NET CF is the most important announcement for developers who are focusing on devices. The .NET CF brings to device developers the ability to program in C# and VB.NET using the same toolset, Visual Studio .NET, as their desktop counterparts and establishes managed code as an important and viable device platform.

The .NET CF is used to deliver the information at any time, at any place, and on any device. The .NET CF is similar to the Windows CE operating system because .NET CF supports only a subset of the .NET Framework functionality.

Note?/td>The Windows CE operating system includes a subset of features of desktop Windows.

The .NET CF does not include portions of the .NET Framework that do not involve devices or are too resource intensive. Instead, it introduces new classes that are exclusive to 446 devices. The .NET CF is positioned as a hardware-independent program execution environment for devices, such as PDAs, set-top boxes, Web pads, and other embedded devices.

Note?/td>The .NET CF is currently available in its Beta phase.

Comparing the design of Windows CE to desktop Windows and .NET CF to the .NET Framework reveals similar constraints. The main difference in Windows CE and desktop Windows lies in the area of COM support. Windows CE supports only a small subset of COM with no real support for DCOM. .NET CF follows this same tradition by supporting neither COM interoperability nor remoting / serialization. The decision was based on the thought that most device-to-server communication would be done through XML and Web services. As a result, direct COM interop with managed code needs to be done explicitly on the .NET CF.

SDE for Visual Studio .NET

The SDE for Visual Studio .NET extends the unified programming environment of .NET to devices powered by the .NET CF. The SDE provides the ability to create additional project types for Pocket PC and Windows CE-based devices and allows you to program and debug these projects by using a single development environment. In addition to the same IDE features, SDE enables device developers to use the same visual forms designers as on the desktop, build applications that operate with XML-based Web services, and leverage the same ADO.NET data access components.

The SDE is an open environment, which means that manufacturers of custom CE devices that support .NET CF can integrate the capabilities of their devices into the Visual Studio IDE seamlessly. A stronger emulation environment allows device developers to program and test their code completely on the desktop prior to deploying it on real devices.

Note?/td>The SDE for Visual Studio .NET is a Technology Preview that will be released around the same time as .NET CF.

Visual Studio .NET will use the SDE to develop managed code applications for devices. However, native applications for Pocket PC and Windows CE will still be developed using eMbedded Visual C++ (eVC) support. However, support for eMbedded Visual Basic (eVB) will not be required because the SDE supports both C# and VB.NET.

It is interesting to note how the development environments for Windows CE evolved over time. Originally, the Windows CE tools were add-ons to the Visual Studio IDE. However, as Visual Studio evolved and expanded in subsequent versions, the compatibility of the CE add-on broke, forcing CE developers to use an older version of Visual Studio. In response to this, Microsoft released the eMbedded Visual Tools (eVT) suite, which consisted of both eVC and eVB environments. These environments replicate their VC++ and Visual Basic desktop counterparts.

Microsoft Mobile Internet Toolkit

Microsoft has two distinct views of how devices will play in the .NET arena. The first view centers around the .NET CF. This view primarily sees devices as rich and capable clients that can both interact with Web services and operate in a disconnected mode. The other view has a large set of disparate wireless devices, each with its own distinct set of capabilities and protocol support that are required to get access to corporate and the Internet information. This second view of devices is addressed by the Microsoft Mobile Internet Toolkit (MMIT).

The MMIT is a set of server side .NET components that is able to handle and hide the complexities of developing applications for a variety of wireless devices. Primarily aimed at digital cell phones, MMIT allows Web developers to concentrate on the content information to be delivered to these devices. This is done by handling all differences of various wireless device protocols, such as WAP, iMode, cHTML, and RIM Blackberry. MMIT provides a suite of smart mobile forms and device detection and abstraction classes, which automatically refactors a display suitable for different device characteristics.

Key to MMIT is its expandability. As more wireless devices come to market, resulting in changing protocols, MMIT adapts by supporting a pluggable architecture in which new device components can be integrated without changing the content information. MMIT truly supports encapsulation of the logic of a wireless application from its device-specific presentation.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

XML Topics