Web Services. Part I:
The Basics
Saurabh Nandu
Feb 15, 2001
Level: Beginner/Intermediate
Introduction
Today the business have crossed the boundaries of the Corporate
Intranets and Virtual Private Networks. The business models have changed from 2
tier to n-tier models, with the business's linking up with other partners,
suppliers, distributors and Consumers.
This has led to the need for programmers to develop huge
applications managed across platforms and geographical boundaries. This has
become a headache for you, hasn't it? Trying to maintain and deploy your
application across different Platforms and making applications written in
different Languages work together. The interoperability between such platforms
and programming languages is one of the major problem which leads to large
expenditure on developing, maintaining and deploying such
applications.
On the lines of the Windows DNA 2000 architecture Microsoft is
promoting a solution for programmers like us to solve interoperability issues
which is called as "Web Services."
"Web Service is just like a application delivered as a service
on the Web"
I guess you just overlooked the above line as a theoretical
definition, didn't you? The above definition explains a lot about Web
Services.
"Web Service is just like a application"
This makes it clear that Web Services are nothing but
applications. Hence they do provide the functionality that usual applications
provide. It also means that like applications Web Services contain business
logic (Programmable logic) which separates the clients from the persistent
database. One notable point would also be that Web Services can be distributed
as applications i.e The web server can provide the Web Service, the database
server can provide the data, etc.
"delivered as a service"
You could compare Web Services to Windows NT services. Hence Web
Services also contains the functionality of services. It runs in the background
and waits for clients to connect to it. Since it is a service it frees you, the
programmer, of writing code for the Web Service to listen for multiple clients -
it automatically does that for you.
"on the Web"
These words mean a lot, if you think deep enough. A common
thought would be that it can be called through the Browser. i.e.. It is URL
addressable and can be invoked by any browser by just typing the Path to the Web
Service. But it also means the following.
Protocol
For those of you who are well versed with Internet Protocol
would know that since Web Services are delivered over the Internet they have to
use either of the two widely used protocols for communication "FTP or HTTP". FTP
is for transferring files so it get ruled out leaving us with one choice "HTTP".
You guessed it right "HTTP" is the protocol used by Web Services to communicate.
So what?
Well this has a widespread effect. Firstly unlike other Remote
Object Models like Distributed Component Object Model (DCOM), Remote Method
Invocation (RMI), or Internet Inter-ORB Protocol (IIOP) which use Object - Model
- Specific Protocols, Web Services use the HTTP protocol to communicate with the
clients. This decreases the burden on you to learn, understand
and master one more new protocol. Also since your company already might be
having a good infrastructure to support HTTP huge expenses on new Infrastructure
is reduced. HTTP as we all know is royalty free, highly tested, proven and used
technology so you don't have to worry about its bugs at all.
Communication via messages
The Web Service Interface can be strictly defined in the terms
of messages a Web Services Accepts and Generates. This means that communication
with Web Services takes place in the form of Messages. Since as you all would
agree XML has become the standard of representation of Data on the Internet, it
is very obvious MS has chosen XML to be the format of the messages.
Another standard coming up is SOAP (Simple Object Access
Protocol), this is basically a set of rules defining how to use XML for
representation of Data and conventions for representing remote procedure
calls (RPCs). To sum it up, Web Services use SOAP encoded XML messages to
communicate.
The obvious question coming up your mind would be, "Do I have to
learn SOAP and XML?" No. The Web Service takes care of all the coding and
decoding, you just have to concentrate on you programming. Using SOAP and XML
formatted messages over HTTP allows the consumers of the Web Service to be on
any platform, object model and programming language as long as the client can
interpret and generate SOAP encoded XML messages. This is the key to Web
Service's clients being interoperable.
The next question that would pop-up in your minds is what kind
of Data can I transfer over Web Services ? Just about anything that is
"serializable". For a partial listing see below.
| Type |
Description |
| Primitive Types |
Standard primitive types.
The complete list of supported primitives are String, Int32, Byte,
Boolean, Int16, Int64, Single, Double, Decimal, DateTime (as XML's
timeInstant), DateTime (as XML's date), DateTime (as XML's time), and
XmlQualifiedName (as XML's QName). |
| Enum Types |
Enumeration types, e.g.
"public enum color { red=1, blue=2 }" |
| Arrays of Primitives,
Enums |
Arrays of the above
primitives, such as string[] and int[] |
| Classes and
Structs |
Class and struct types
with public fields or properties. The public properties and fields are
serialized. |
| Arrays of Classes
(Structs) |
Arrays of the
above. |
| DataSet |
ADO.NET DataSet Types .
DataSets can also appear as fields in structs or classes. |
| Arrays of
DataSet |
Arrays of the
above. |
| XmlNode |
XmlNode is an in-memory
representation of an XML fragment (like a lightweight XML document object
model). For example, "<comment>This is<b>pretty</b>
neat</comment>" could be stored in an XmlNode. This allows you to
pass or return XML whose structure changes from call to call, or where you
may not know all the types being passed. XmlNode can also appear as fields
in structs or classes. |
| Arrays of
XmlNode |
Arrays of
above. |
Parameters that can be passed to a Web
Service
Both by-value and by-reference (in/out) parameters are supported
when using the SOAP protocol. By-reference parameters have the effect of sending
the value both ways: up to the server, and back to the client. When passing
input parameters to a Web Service via HTTP GET/POST, only a limited set of data
types are supported, and they must be by-value parameters. The supported types
for HTTP GET/POST parameters are listed below:
| Type |
Description |
| Primitive Types
(limited) |
Most standard primitive
types. The complete list of supported primitives are Int32, String, Int16,
Int64, Boolean, Single, Double, Decimal, DateTime, TimeSpan, UInt16,
UInt32, UInt64, and Currency. From the client's perspective, all these
types turn into string. |
| Enum Types |
Enumeration types, e.g.
"public enum color { red=1, blue=2 }". From the client's perspective,
enums become classes with a static const string for each
value. |
| Arrays of Primitives,
Enums |
Arrays of the above
primitives, such as string[] and int[] |
Service Description
How does a client know what Methods, Parameters etc. are
supported by the Web Service ? To solve this issue all Web Services
automatically generate a XML file formatted in SDL (Service Description
Language). This resource is also URL addressable and you can get it from your
browser by just appending "?SDL" after the path to the Web Service. e.g.
"http://myhost.com/services/myservice.asmx?SDL"
will Generate a SDL formatted for the Web Service "myservice". SDL is nothing
else but just a grammar for documenting Web Service Contracts. So you can use
the SDL file of a Web Service and know exactly what methods, parameters are
supported by the Web Service.
Service Discovery
Once Web Services get widely used there might arise the problem
of discovering the right Web Service for your need. To address to this problem
Web Services also provide Service Discovery (DISCO) files. Also one more
specification provided with the Web services is the Service Discovery (DISCO).
Service Discovery is the standard way to be used by Web Service providers to
provide service contracts. This helps the developers to easily discover the
Service Contracts for the Web Services.
I guess by now you should have got a good idea about Web
Services and its functioning. So let us jump to its architecture for knowledge
of its internal design.
Web Service Architecture
Web Services are programmable web applications containing
business logic accessible via Standard Internet protocols. Web Service
architecture is based on the Windows DNA 2000 architecture. It is a
multi-layered architecture. At the very base is the persistent database. The
database does not come in direct contact with the Client at anytime keeping the
database safe for malicious attract . The data access layer acts as the link
between the persistent database and the Web Service.
Also the data access layer can use data from other Web Services.
Above the Data Access Layer lies the all important Business Logic Layer. You can
divide this layer into multiple parts according to your need. E.g. One layer
could look after validating your database and other layer could format you data
according to your needs. This layer contains all the logic that should be
executed to process the Raw Data from the client or from the Data Access Layer.
The above layers do not contain any UI components. They are just
programmable parts which should be optimized to bear load of bulk requests also
they should be fault tolerant and should be able to recover from faults quickly.
Since most work is done by the Business Logic layer it should be also scalable
and fast.
Above the these layers is the Listener layer. This layer listens
for client requests for Data and for Contract. It the listener layer that is
responsible for decoding data submitted by clients and packaging the Data from
the Business Logic layer and transmitting it to the client. Listener is the only
layer in the Web Service that know its a part of the Web Service. When a Web
Service is called the Listener layer is the only layer that comes in direct
contact with the Client. Also requests for service contracts are fulfilled by
the listener layer. The Listener layer is in-built in Web Services so you don't
have to worry of implementing it.
Future
As business on the Web will evolve the dependence and need for
Global applications which work across platforms and programming languages will
increase significantly. Thus need for some standard technologies which solve
interoperability issues will arise. With .NET Microsoft has visualized this had
placed a significant step in the process of interoperable programming. Web
Services will form a important part of such business architecture. Also by
embracing the standard and globally used protocols like HTTP, SOAP and XML
Web Service decrease the cost of acquiring special platforms to use
it.
Integration of Web Services with ASP.NET makes development Very
fast and scalable. Some of the areas where Web Service could have a major impact
would be content providers, peer to peer computing, large business structures,
customer support etc.
2002-09-12 14:27