GetSeqNumber Method

We can use the HTML form that this provides to pass values to the GetSeqNumber method. Enter a number into the parameter textbox and press the Invoke button to view the results:

GetSeqNumber Method

What's shown here is the XML returned from the GetSeqNumber method call. The element is named <int/>, and the return value is 8. Note that the value of fibIndex=6 is passed as an argument in the query string. We could change this argument's value directly, and the Web Service would return the appropriate result.

This isn't a SOAP return, it's another protocol type that ASP.NET Web Services support: HTTP-GET. The Web Service help page generates a simple HTML form that makes a GET request to the Fibonacci_cs.asmx file. When we build proxies to use our Web Service, the default protocol will be SOAP.

Let's take a closer look at the changes we just made to our code in order to implement it as a Web Service.

Coding ASP.NET Web Services
The .asmx file format is very straightforward. We have two options for exposing application logic as an ASP.NET Web Service. Both options involve creating a file with the extension .asmx:

• Inline - the application logic exists within the .asmx file
• Code-behind - the application logic exists outside the .asmx file

Inline
The first option (and the one we'll use for our examples) is to code the application logic within the .asmx file. This is similar to inline ASP.NET pages - we take the Fibonacci VB.NET or C# code and create the corresponding Fibonacci_vb.asmx and Fibonacci_cs.asmx - exactly as we did earlier.

Code-Behind
Just as we have a code-behind option for ASP.NET pages, we have a code-behind option for ASP.NET Web Services. Code-behind is the default behavior for ASP.NET Web Services created with Visual Studio .NET. Rather than the application logic existing within the .asmx file, the application logic is stored in an external assembly.

To be able to reference an external assembly, the assembly must reside in the ASP.NET application's bin directory. The bin directory is a special directory used by the ASP.NET application, to which assemblies can be deployed and 'automatically' registered.

To use the code-behind option we simply create a small ASP.NET Web Service .asmx file (which we'll call Fibonacci_Codebehind.asmx) that contains a single line:

<%@ WebService Codebehind="Fibonacci.vb" Class="Fibonacci" %>

We need an implementation of our Fibonacci class in a separate assembly, either compiled and deployed in our ASP.NET application's bin directory, or as part of an assembly named directly in our configuration file. Here's what the source would look like for the VB.NET version of our Fibonacci example (Fibonacci.vb):

Imports System
Imports System.Web
Imports System.Web.Services

Public Class Fibonacci

	<WebMethod()>
	Public Function GetSeqNumber(fibIndex As Integer) As Integer
		If (fibIndex < 2) Then
			Return fibIndex
		End If
		
		Dim FibArray(2) As Integer
		Dim i As Integer
		
		FibArray(0) = 0 FibArray(1) = 1
		
		For i = 2 To  fibIndex
			FibArray(1) = FibArray(1) + FibArray(0)
			FibArray(0) = FibArray(1) - FibArray(0)
		Next
		
		Return FibArray(1)
	End Function

End Class

We can simply use the following command line to compile the source into a .NET assembly:

vbc /t:library /r:System.Web.dll /r:System.Web.Services.dll Fibonacci.vb

The result of this is a single file, Fibonacci.dll, which we need to place in a directory, named bin, that is located below the root directory of the application. We can easily deploy the assembly (Fibonacci.dll) so that both ASP.NET pages and Web Services may use it - it's simply a component with a WebMethod attribute. For example, if decide that the functionality encapsulated within a class would make a great Web Service we can simply make some minor changes to the assembly's application logic, and create a one line ASP.NET Web Service .asmx file (as above), to enable the application logic as a SOAP based end-point.

As code-behind is the default behavior, the use of the Codebehind statement in Fibonacci.asmx is optional. Visual Studio .NET will use the Codebehind attribute, but we can just as easily remove it and still achieve the same functionality, so long as the assembly contains the class our ASP.NET Web Service references. Also, there is no difference in performance between using inline or code-behind.

Further discussion of Web Services will use the inline style, unless otherwise noted. The only tangible benefit for using code-behind over the inline style is:

• Code is compiled and the source cannot be viewed once deployed
• Since the code-behind option is an assembly, the assembly can also be used in ASP.NET pages

Both the inline and code-behind options share a common set of directives that are used to give ASP.NET special instructions when handling ASP.NET Web Service requests.

The WebService Directive
Like ASP.NET pages, ASP.NET Web Services support directives that instruct ASP.NET how to process the request. For example, when we converted our Fibonacci examples to ASP.NET Web Services, the first thing we added was a directive at the top of the .asmx file. Using VB .NET we wrote:

<%@ WebService Class="Fibonacci" %>

And using C# we wrote:

<%@ WebService Language="C#" Class="Fibonacci" %>

The WebService directive is a required addition for all ASP.NET Web Services. We'll look at the directive syntax, and then at the attributes we'll use most often.

Syntax The directive syntax is identical to that of ASP.NET pages. The declaration is contained within <%@ %> tags, contains a single directive, and may contain multiple attributes that apply to that directive:

<%@ DirectiveName Attribute="Value" %>

or:

<%@ WebService Attribute="Value" Attribute="Value"%>

An ASP.NET Web Service may contain multiple classes. However, only one of the classes can contain methods marked with WebMethod attributes. This relationship is enforced with a WebService directive attribute named Class.

The Class Attribute
The Class attribute is special, since it is required and forces us to always declare the WebService directive within a .asmx file. Fortunately, it's not complicated. The Class attribute simply names the .NET class, whether inline or code-behind, that contains exposed methods or properties:

<%@ WebService Class="[Namespace.Class | Class]" %>

Using the Class Attribute Our Fibonacci class must be named in the Class attribute as the Fibonacci class contains the logic to be exposed:

<%@ WebService Class="Fibonacci" %>

If the Fibonacci class existed within a namespace, we would need to further qualify it:

<%@ WebService Language="C#" Class="MyMath.Fibonacci" %>

namespace MyMath {
	public class Fibonacci{
		// implementation
	}
}