Home > 2010 Winter BTI420 > Web Services introduction for ASP.NET Web Forms apps

Web Services introduction for ASP.NET Web Forms apps

In this post, you will be introduced to ASP.NET XML Web Services.


You are now very familiar with a web form in an ASP.NET web app.

A web service is a class with methods that can be called by remote processes. In the context of doing ASP.NET web form development using Visual Studio, you can think of a web service as a web form without the user interface. Also, you can think of it as a "server", because it serves functionality to callers/clients.

Our coverage of web services will focus on XML Web Services. This type of web service uses the HTTP protocol for communication, and the XML "SOAP message" data format for its requests and replies. There are a number of other remote method invocation technologies, but we will cover XML Web Services as the introductory technology.


Web Service "server"

A web service "server" is implemented as a (C#) program code file. When created in Visual Studio, it automatically generates the interfaces (code and UI) needed for remote clients to discover its functionality.

When you create a web service "server", Visual Studio creates an asmx file. This document is the endpoint that a web service "client" connects to.

Therefore, it is located in the folder that you (the designer) intends it to be located.

Visual Studio then stores its C# code-behind class file in your App_Code folder.

One of the tasks you will have to do is to declare a "namespace" for your "server" web services. Visual Studio uses "http://tempuri.org" as a temporary, or placeholder, namespace name, and tells you that you need to change it. (A namespace is used as a way to organize program code – a structured way of presenting program components that are exposed to other programs and applications.) The following is a suggested namespace pattern that you can use for your "server" web services:

  • Use a dot-separated composite name
  • Include your organization or company name as the first part
  • Use additional parts to provide additional hierarchy (organization) or clarification

Namespace name examples:

  • Seneca.Peter.WebServices
  • Seneca.PeterWebServices
  • MyCompany.Public.WebServices
  • MyCompany.CorporateWebServices
  • (etc.)


Web Service "client"

A web service "client" can be created in any client and device environment, on any platform. According to the web service standards, the client creates a local "proxy" class which has definitions for the web service’s methods. If you are using Visual Studio, the "Add Web Reference" operation creates this proxy class (otherwise, you will have to use a tool to create/generate the class). Then, the client creates an instance of the local proxy class, and can call its methods.

Note: If you are calling a warp-based "server" from a warp-based "client", you must be aware of the following:

Warp-to-warp client/server calls must use the "web1" hostname (and not warp.senecac.on.ca).

If you do NOT fix this, then you will get this rather useless error message:


Therefore, if you have a warp-based web service "client", and you want to call a warp-based web service "server", then you must change the Web.config appSettings key that holds the URL of the web service server. For example, you may want to change your key/value to something like this:

<add key="SenecaA01WarpWebService.WarpServerInfo" value="http://web1/bti420_101a01/examples/WarpServerInfo.asmx"/>

Alternatively, you may consider doing that at runtime, because that will give you the most flexibility as you modify your servers and clients. The following code block would be placed in the client method just before it creates and instance of the web service and calls its method(s):

    ["SenecaA01WarpWebService.WarpServerInfo"] =

However, if you are creating a web service client in any of the following categories, you do not have to do this appSettings key/value change:

  • ASP.NET web form that is located on a host other than the warp cluster
  • Windows Forms application that executes anywhere other than on the warp cluster
  • Console application or service that executes anywhere other than on the warp cluster
  • Application on another platform (e.g. Mac OS X, iPhone OS, UNIX/Linux, etc.)


Coding a web service "server"

A web service "server" class looks like any other class. However, the class is decorated with web service attributes, which instruct the compiler to enable the class for access by remote users (i.e. consumers which are outside of this current web application domain).

The following example shows the attributes that are automatically placed by the code editor, where you provide the namespace and description strings.

[WebService(Namespace = "Seneca.A01WebServices", Description = "Example web service that returns warp server information")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

Each method that you want to expose to remote callers must also be decorated with an attribute. The following example shows the template to use (replace the description string):

[WebMethod(Description = "This method returns a greeting and the server's time of day")]


Coding a web service "client"

If you want to create software that calls a web service "server" and consumes its methods, the standard procedure is to create a "web reference", which is code that refers to, and describes (in code) the web service. MSDN describes a web reference this way:

A Web reference enables a project to consume one or more XML Web services. Use the Add Web Reference Dialog Box to search for Web services locally, on a local area network, or on the Internet.

After adding a Web reference to your current project, you can call any methods exposed by the Web service.

When you want to use web service "server" methods in your "client", you create an instance of the remote web service class. Then, you can call its methods directly. As explained above, a "local" version of the remote web service class is created by the Add Web Reference procedure.


Data payloads – DataSet (data access layer) and its components

The DataSet has a unique characteristic – it can be passed as data in XML Web Services:

  • We can get a DataSet from a web service "server" method, and/or
  • We can send a DataSet to a web service "server" method as an argument

Also, note that a DataTable can also be passed as data in XML Web Services.

Here is some introductory information from the MSDN article "Consuming a DataSet from an XML Web Service":

The DataSet was architected with a disconnected design, in part to facilitate the convenient transport of data over the Internet.

The DataSet is "serializable" in that it can be specified as an input to or output from XML Web services without any additional coding required to stream the contents of the DataSet from an XML Web service to a client and back.

The DataSet is implicitly converted to an XML stream using the DiffGram format, sent over the network, and then reconstructed from the XML stream as a DataSet on the receiving end.

This gives you a very simple and flexible method for transmitting and returning relational data using XML Web services.


Categories: 2010 Winter BTI420
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: