Web Services. Part I: The Basics

申请免费试用、咨询电话：400-8352-114

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.

List of items the Web Service can Pass to its clients:

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.