Home arrow ASP.NET arrow Page 4 - Building XML Web Services Using C# and ASP.NET
ASP.NET

Building XML Web Services Using C# and ASP.NET


The term "web service" has been used quite frequently lately: you hear people saying how good web services are and how they will dominate the future of software development, but what exactly are web services and how can we create them? In this article James shows us how to build two web services and also unravels all of the lingo surrounding web services.

Author Info:
By: James Yang
Rating: 5 stars5 stars5 stars5 stars5 stars / 132
March 29, 2002
TABLE OF CONTENTS:
  1. · Building XML Web Services Using C# and ASP.NET
  2. · What is a web service?
  3. · A simple web service
  4. · Other web service features
  5. · Real world application
  6. · Conclusion

print this article
SEARCH DEVARTICLES

Building XML Web Services Using C# and ASP.NET - Other web service features
(Page 4 of 6 )

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:

The web service page with web service attributes set

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:

The web method description attribute

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:

Our property implementation

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 3rd 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.
blog comments powered by Disqus
ASP.NET ARTICLES

- How Caching Means More Ca-ching, Part 2
- How Caching Means More Ca-ching, Part 1
- Reading a Delimited File Using ASP.Net and V...
- What is .Net and Where is ASP.NET?
- An Object Driven Interface with .Net
- Create Your Own Guestbook In ASP.NET
- HTTP File Download Without User Interaction ...
- Dynamically Using Methods in ASP.NET
- Changing the Page Size Interactively in a Da...
- XML Serialization in ASP.NET
- Using Objects in ASP.NET: Part 1/2
- IE Web Controls in VB.NET
- Class Frameworks in VB .NET
- Cryptographic Objects in C#: Part 1
- Sample Chapter: Pure ASP.Net

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials