ASP.Net Application - ASP.NET Mobile Web Applications
(Page 2 of 8 )
The ASP.NET Mobile Web Application is a subtype of Web Application specific to developing for mobile devices such as cell phones and PDAs. The primary thing that distinguishes a mobile webapplication from a standard web application in ASP.NET is the use of the ASP.NET mobile controls, which are built into the .NET Framework as of Version 1.1. These include the mobile Form control and standard controls such as labels, textboxes, and panels, as well as mobile-specific controls such as the TextView, PhoneCall, and SelectionList controls. Note that both mobile Web Forms pages (those that use the mobile controls) and standard Web Forms pages can coexist within the same application, if desired.
To simplify development of ASP.NET applications for mobile devices, Visual Studio .NET 2003 provides an ASP.NET Mobile Web Application project template. This template includes a default mobile Web Form, as well as a special section added to the Web.config file called <deviceFilters>, which contains settings for device-specific rendering.
ASP.NET Web Services The other type of application available to ASP.NET developers is the ASP.NET WebService. Like ASP.NET Web Applications, there are a number of terms floating around for this type of application. (Microsoft refers to web services as “XML Web Services,” perhaps in hopes of a positive association between web services and the XML standard.) A web service is an application that exposes programmatic functionality to clients over the Internet or an intranet using the underlying plumbing of a developing W3C standard called SOAP. In simple terms, it can be seen as a simple function call across the Internet.
What Is SOAP? The proposed SOAP standard, which at the time of this writing was a W3C Candidate Recommendation (see http://www.w3.org/Consortium
/Process-20010719/tr.html#RecsCR for information on where this fits in the standardization process) and versioned at 1.2, describes a protocol that may be used within the framework of HTTP (other transport protocols are possible, but the SOAP specification does not define how to use them) to send and receive requests and responses consisting of either specific data or remote procedure calls and responses, or both. The SOAP specification defines the format for messages sent via SOAP, methods for communicating how a message should be processed, and encoding rules for communicating data types across heterogeneous platforms. Assuming that the proposed SOAP standard is adopted as a W3C Recommendation ( recommendation is the term used by the W3C to describe stable standards such as HTML 4.01; see http://www.w3.org for more information on current recommendations), application developers on a given platform can expose their functionality to others on different platforms in a fashion that makes the differences in platform transparent. As long as both the server and the client follow the SOAP specification, the applications can communicate, regardless of the platform differences. Since SOAP has not yet been adopted as a recommendation and is still under development, current implementations from Microsoft and other vendors have not yet achieved the level of cross-platform interoperability that is promised once SOAP is adopted as a recommendation. As such, you should take the time to test and evaluate the interoperability of your chosen platform(s) before committing substantial resources to web services, if you are planning to use web services to facilitate cross-platform interoperability. |
The simplest form of an ASP.NET Web Service consists of a directory made available via HTTP using the IIS administration tool or through the Web Sharing tab of a folder’s Properties dialog (or by creating a Web Application project in Visual Studio .NET) and at least one web service file, designated by the .asmx file extension. Unlike an ASP.NET page, this file (or files), whose structure we’ll discuss in detail in Chapter 4, typically does not contain HTML, but consists solely of server-side code. The methods to be exposed by the web service carry the WebMethod attribute (note that the syntax of the WebMethod attribute varies depending on the language used). A simple web service is shown in Example 2-2.
Example 2-2 . A simple web service
<%@ WebService Language="VB" Class="Hello" %>
Imports System
Imports System.Web.Services
Public Class Hello : Inherits WebService
<WebMethod()> Public Function SayHello() As String
Return("Hello, World!")
End Function
End Class
If the .asmx file that makes up this webservice is called from a browser, ASP.NET will output a page that documents how the webservice should be called, and also provides the ability to test the invocation of the web service. This page is shown in Figure 2-2.
When invoked, the web service shown in Example 2-2 will return “Hello, World!” as an XML-formatted response, according to the SOAP 1.1 specification, as shown here:
<?xml version="1.0" encoding="utf-8" ?>
<string xmlns="http://tempuri.org/">Hello, World!</string>
The documentation page provided by ASP.NET also allows you to review the Web Service Description Language (WSDL) description of your web service. WSDL, which we’ll discuss further in Chapter 4, is an XML-based format for describing the functionality exposed by a web service, including the format and data type of input and output parameters, and can be considered a contract for how clients interact with the web service. In this way, WSDL plays a role similar to that of Interface Description Language (IDL) in Microsoft’s COM component specification.
Besides providing a detailed discussion of how to create a webservice, Chapter 4 shows you how to consume a web service.
Figure 2-2. Output of a simple web service
 This chapter is from ASP.NET in a Nutshell, by G. Andrew Duthie. (O'Reilly, 2003, ISBN: 0596005202). Check it out at your favorite bookstore today. Buy this book now.
|
/ 36 
