Introduction
Microsoft .NET marketing has created a huge hype about its Web Services. This is the first of two articles on Web Services. Here we will create a .NET Web Service using C#. We will look closely at the Discovery protocol, UDDI, and the future of the Web Services. In the next article, we will concentrate on consuming existing Web Services on multiple platforms (i.e., Web, WAP-enabled mobile phones, and windows applications). Why do we need Web Services?
After
buying something over the Internet, you may have wondered about the
delivery status. Calling the delivery company consumes your time, and
it's also not a value-added activity for the delivery company. To
eliminate this scenario the delivery company needs to expose the
delivery information without compromising its security. Enterprise
security architecture can be very sophisticated. What if we can just
use port 80 (the Web server port) and expose the information through
the Web server? Still, we have to build a whole new Web application to
extract data from the core business applications. This will cost the
delivery company money. All the company wants is to expose the delivery
status and concentrate on its core business. This is where Web Services
come in.
What is a Web Service?
Web Services are a very general model for building applications and can
be implemented for any operation system that supports communication
over the Internet. Web Services use the best of component-based
development and the Web. Component-base object models like Distributed
Component Object Model (DCOM), Remote Method Invocation (RMI), and
Internet Inter-Orb Protocol (IIOP) have been around for some time.
Unfortunately all these models depend on an object-model-specific
protocol. Web Services extend these models a bit further to communicate
with the Simple Object Access Protocol (SOAP) and Extensible Markup
Language (XML) to eradicate the object-model-specific protocol barrier
(see Figure 1).
Web Services basically uses Hypertext Transfer Protocol (HTTP)
and SOAP to make business data available on the Web. It exposes the
business objects (COM objects, Java Beans, etc.) to SOAP calls over
HTTP and executes remote function calls. The Web Service consumers are
able to invoke method calls on remote objects by using SOAP and HTTP
over the Web.
How is the user at Location A aware of the semantics of the Web Service
at Location B? This question is answered by conforming to a common
standard. Service Description Language (SDL), SOAP Contract Language
(SCL) and Network Accessible Specification Language (NASSL) are some
XML-like languages built for this purpose. However, IBM and Microsoft
recently agreed on the Web Service Description Language (WSDL) as the
Web Service standard.
The structure of the Web Service components is exposed using
this Web Service Description Language. WSDL 1.1 is a XML document
describing the attributes and interfaces of the Web Service. The new
specification is available at msdn.microsoft.com/xml/general/wsdl.asp.
The task ahead
The
best way to learn about Web Services is to create one. We all are
familiar with stock quote services. The NASDAQ, Dow Jones, and
Australian Stock Exchange are famous examples. All of them provide an
interface to enter a company code and receive the latest stock price.
We will try to replicate the same functionality.
The input parameters for our securities Web service will be a company
code. The Web service will extract the price feed by executing
middle-tier business logic functions. The business logic functions are
kept to a bare minimum to concentrate on the Web service features.
Tools to create a Web Service
The core software component to implement this application will be MS
.NET Framework SDK, which is currently in beta. You can download a
version from Microsoft. I used Windows 2000 Advance Server on a Pentium
III with 300 MB of RAM.
The preferred Integration Development Environment (IDE) to create Web
Services is Visual Studio .NET. However, you can easily use any text
editor (WordPad, Notepad, Visual Studio 6.0) to create a Web Service
file.
I assume you are familiar with the following concepts:
Creating a Web Service
We
are going to use C# to create a Web Service called
"SecurityWebService." A Web Service file will have an .ASMX file
extension. (as opposed to an .ASPX file extension of a ASP.NET file).
The first line of the file will look like
Dot-net Web Services are intelligent enough to cast basic data types.
Therefore, if we return "int," "float," or "string" data types, it can
convert them to standard XML output. Unfortunately, in most cases we
need get a collection of data regarding a single entity. Let's take an
example.
Our SecurityWebService stock quotes service requires the user
to enter a company code, and it will deliver the full company name and
the current stock price. Therefore, we have three pieces of information
for a single company:
We can use the business logic in this function to get the newest
stock price quote. For the purpose of this article I have added some
text to the company code to create the company name. The price value is
generated using a random number generator.
We may save this file as "SampleService.asmx" under an Internet
Information Service (IIS)-controlled directory. I have saved it under a
virtual directory called "/work/aspx." I'll bring it up on a Web
browser.
This is a Web page rendered by the .NET Framework. We did not
create this page. (The page is generated automatically by the system. I
did not write any code to render it on the browser. This graphic is a
by-product of the previous code.) This ready-to-use functionality is
quite adequate for a simple Web Service. The presentation of this page
can be changed very easily by using ASP.NET pagelets and config.web
files. A very good example can be found at http://www.ibuyspy.com/store/InstantOrder.asmx.
Notice a link to "SDL Contract." (Even if we are using WSDL, .NET Beta
still refers to SDL. Hopefully this will be rectified in the next
version). This is the description of the Web Service to create a proxy
object. (I will explain this in the next article.) This basically gives
an overview of the Web Service and it's public interface. If you look
closely, you will only see the "Web-only" methods being illustrated.
All the private functions and attributes are not described in the SDL
contract. The SDL contract for the SecurityWebService can be found in
Appendix A.
How do we use a Web Service?
Now we can use this Web Service. Let's enter some values to get a bogus price feed.
By clicking the Invoke button a new window will appear with the following XML document
This is how the Web Service releases information. We need to
write clients to extract the information from the XML document. Theses
clients could be
You can also call the Web Service directly using the HTTP GET method.
In this case we will not be going through the above Web page and
clicking the Invoke button. The syntax for directly calling the Web
Service using HTTP GET is
http://server/webServiceName.asmx/functionName?parameter=parameterValue
Therefore, the call for our Web Service will be
http://localhost/work/aspx/SampleService.asmx/GetSecurityInfo?Code=IBM
This will produce the same result as clicking the Invoke button.
Now we know how to create a Web Service and use it. But the work
is half done. How will our clients find our Web Service? Is there any
way to search for our Web Service on the Internet? Is there a Web
crawler or a Yahoo search engine for Web Services? In order to answer
these questions we need to create a "discovery" file for our Web
Service.
Creating a Discovery file
Web
Service discovery is the process of locating and interrogating Web
Service descriptions, which is a preliminary step for accessing a Web
Service. It is through the discovery process that Web Service clients
learn that a Web Service exists, what its capabilities are, and how to
properly interact with it. Discovery file is a XML document with a
.DISCO extension. It is not compulsory to create a discovery file for
each Web Service. Here is a sample discovery file for our securities
Web Service.
There have been a lot of Web Services written by developers.
www.xmethods.com is one of the sites that has an index of Web Services.
Some developers are building WSDL search engines to find Web Services
on the Web.
Deploying a Web Service
Deploying
the Web Services from development to staging or production is very
simple. Similar to ASP.NET applications, just copy the .ASMX file and
the .DISCO files to the appropriate directories, and you are in
business.
The future of the Web Services
The future looks bright for the Web Service technology. Microsoft is
not alone in the race for Web Service technology. Sun and IBM are very
interested. There are SOAP toolkits available for Apache and Java Web
servers. I believe Web Services needs a bit of work, especially the Web
Service discovery process. It is still very primitive.
On a positive note, Web Services have the potential to introduce new
concepts to the Web. One I refer to as "pay per view" architecture.
Similar to pay-TV, we can build Web sites that can generate revenue for
each request a user sends (as opposed to a flat, monthly subscription).
In order to get some data, we can sometimes pay a small fee.
Commercially this could be handy for a lot of people.
Examples
On a very optimistic note, Web Services can be described as the
"plug and play" building blocks of enterprise Business to Business
(B2B) Web solutions.
Appendix A
|