Web Service Attribute
Almost all the time when you're developing for the "real" world, you'll want to provide a description for your web services. You might also want to change the default namespace and give your web service a different name. All of these can be changed using WebService attributes. You can add an attribute and its appropriate properties just before the class declaration, like this:

[WebService(Name="Hello World", Description="Hello World Application developed by James Yang", Namespace="devArticles")]

public class HelloWorld : WebService

When you view the web service page now, it will look like this:



Notice how the name has changed from HelloWorld to Hello World? The description attribute that we specified is also shown. The instructions on how to change the namespace attribute are gone as well, and the namespace is also changed.

The biggest change however, is on the deletion of all of the instructions and template descriptions for the web service. IIS and the compiler assume that by specifying a namespace, our web service is no longer in the development stages and therefore removes unnecessary developer information for us.

Web Method Attribute
Attributes can also be added to each method individually. The available properties are:

• Description
• EnableSession
• MessageName
• TransactionOption
• CacheDuration
• BufferResponse

If you change the line

[WebMethod]

to

[WebMethod(Description ="Hello World Method")]

... then you will see the following change on our web service page:



Back to the web method attributes, MessageName is simply an alias for the method. This is particularly useful for parameter-overloaded methods, as requests through a browser cannot display two methods with the same name. The CacheDuration property sets the amount of time that the data will be cached for. This property is an integer and therefore it must contain a whole numeric value. The BufferResponse property is a Boolean property. If set to true, output is buffered and only transmitted once.

The TransactionOption property allows us to specify how transactions will be supported in this method. The available options are:

• Disabled
• Notsupported
• Supported
• Required
• RequiredNew

The EnableSession property is a Boolean property and allows us to enable sessions (this requires the use of the proxy object, which will be discussed in another article). Without the proxy object, this web property cannot be implemented as the property is discarded as soon as the value is assigned to it. Without a proxy object, only one request is allowed per session, and assigning a value to the property itself is a request and therefore the session is ended just after.

Web Properties
A web property can be created like this:

string _property;

public string HelloWorldProperty
{
[WebMethod(EnableSession=true)]
get
{
return _property;
}
[WebMethod(EnableSession=true)]
set
{
_property = value;
}
}

Notice how the EnableSession property of our WebMethod attribute is set to true? If you open up your web service page again, then you will see that get and set have been implemented as two separate methods:



Protocols
ASP.NET supports three different protocol types:

• HTTP-GET
• HTTP-POST
• SOAP

When we pass a parameter on the web services page that we looked at earlier, we're actually passing the value using the HTTP-GET protocol. You can see this from the URL of the returned page, for example:

http://ws1/helloworld/helloworld.asmx/HelloWorldMethod?

"?" is used to pass values with the HTTP_GET protocol. We can pass parameters on the web service web page if we modify the showPost flag of defaultwsdlhelppagegenerator.aspx to true, which located in the c:\winnt\system32\Microsoft.NET\Framework\[Version] directory.

One important thing to notice here is that the two methods shown above return the result in XML format and not SOAP. Results returned as XML can be used in an application by treating the data as an XML document, but there is a better way to use web services.. it's called SOAP.

SOAP is a 3 ^rd generation protocol that can be used to communicate with web services. It's actually composed of lightweight XML that's dedicated to the transportation of a data structures information and the actual data itself. SOAP is sent using the HTTP-POST protocol:

POST /helloworld/helloworld.asmx HTTP/1.1
Host: ws1
Content-Type: text/xml; charset=utf-8
Content-Length: length goes here
SOAPAction: "devArticles/HelloWorldMethod"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<HelloWorldMethod xmlns="devArticles" />
</soap:Body>
</soap:Envelope>

.NET understands SOAP and behind the scenes it organizes the resultant data into the right type of application defined data for us. For example, if we use a proxy object to invoke our web service then SOAP is automatically used. If the web service returns a string, then .NET extracts this value and assigns it to a new string object. This string object can then be used in our applications, without even knowing that SOAP was handling the web service request for us!

SOAP and the web service session actually allow us to create an instance of our web service and it automatically calls the appropriate methods for us behind the scenes. This process is called XML Serialization.

For example, if we setup a proxy object for the HelloWorld web service that we created earlier, we could use the following code to invoke it:

HelloWorld hw = new HelloWorld
hw.HelloWorldProperty = "Property Value";
Console.WriteLine (hw.HelloWorldProperty);
hw.HelloWorldMethod();

For the example above to work we would need to use a proxy object, which I will cover in another article.