.NET Web Services Concepts

Introduction

On surfing the various web service related internet articles, my personal feeling is that the conceptual view is missing. Concept knowledge is more important to become an expert. That triggers me to initiate this concept article about .NET webservices.

Technical Overview

A Web Service is a programmable application logic accessible using standard Internet protocols. Web Services combine the best aspects of component-based development and the Web. Like components, Web Services represent black-box functionality that can be reused without worrying about how the service is implemented. Unlike current component technologies, Web Services are not accessed via object-model-specific protocols, such as DCOM, RMI, or IIOP. Instead, Web Services are accessed via ubiquitous Web protocols (e.g., HTTP) and data formats (e.g., XML).

Background - Programming History

Machine

In late 60s, machine language was used to do programming. It consists of 0 and 1's in their program. It is a fact of electronics that the easiest way to store and manipulate information is by using ON-OFF states. The first thing to learn about ML is that it reflects the construction of computers. It most often uses a number system (hexadecimal) which is not based on ten. To represent decimal number '3', the binary format would be 00000011. Electronically, it has been stored as,

Assembly

Assembly language is the oldest non-machine language, allowing for a more human readable method of writing programs than writing in binary bit patterns (or even hexadecimal patterns). Assembly languages are close to a one to one correspondence between symbolic instructions and executable machine codes. Assembly languages also include directives to the assembler, directives to the linker, directives for organizing data space, and macros. Macros can be used to combine several assembly language instructions into a high level language-like construct (as well as other purposes). There are cases where a symbolic instruction is translated into more than one machine instruction. But in general, symbolic assembly language instructions correspond to individual executable machine instructions.

High Level

In early 70s, high level languages became popular. The best examples are BASIC, COBOL, FORTRAN, etc. High level languages are abstract. Typically, a single high level instruction is translated into several (sometimes dozens, or in rare cases, even hundreds) executable machine language instructions. Some early high level languages had a close correspondence between high level instructions and machine language instructions. For example, most of the early COBOL instructions translated into a very obvious and small set of machine instructions. The trend over time has been for high level languages to increase in abstraction. High level programming languages are much easier for less skilled programmers to work in, and for semi-technical managers to supervise. And high level languages allow faster development times than work in assembly language, even with highly skilled programmers.

Procedural

Procedural programming is sometimes used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself.

Procedural programming is often a better choice than simple sequential or unstructured programming in many situations which involve moderate complexity or which require significant ease of maintainability. Possible benefits:

1. The ability to re-use the same code at different places in the program without copying it.
2. An easier way to keep track of program flow than a collection of "GOTO" or "JUMP" statements (which can turn a large, complicated program into so-called "spaghetti code").
3. The ability to be strongly modular or structured.

Object Oriented

A type of programming in which programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure. In this way, the data structure becomes an object that includes both data and functions. In addition, programmers can create relationships between one object and another. For example, objects can inherit characteristics from other objects. One of the principal advantages of object-oriented programming techniques over procedural programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify. Object oriented languages include SmallTalk and C++ during the late 80s.

Event Driven

During early 90s, this style became popular. In computing, event driven programming is a style of computer programming where the flow of the program is determined by user actions (mouse clicks, key presses) or messages from other programs. In contrast, in batch programming, the flow is determined by the programmer. Batch programming is the style taught in beginning programming classes while event driven programming is what is needed in any interactive program. Event driven programs can be written in any language although the task is easier in some languages than in others.

Service Oriented

Service Oriented Architecture (SOA) is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. The SOA concept leads to the current web service technology with more application inter-operability.

Idea of a Web Service

A web service is a service provided and invoked through the internet:

1. with a standard interface description, and
2. using standard web protocols.

Web Service Definition

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

Four Key Components

A Web service is built with four key components namely XML, SOAP, WSDL and UDDI. These are the heart of the web service system as shown below:

Industry Usage

The core four components are built with the various products in various vendors as mentioned below. As part the of web service standard adherence, the system shouldn't miss any of these key components. Though the used tools vary, the concept would be the same across the various vendors. For all sorts of successful communication, any system needs a clear definition for the message, transport, directory, process, and ultimately the transaction. Here, we use all these concepts, which leads into communication reliability, security, and error handling capabilities.

Classic Example

To explore more technical details about .NET web services, let us take the classic example of a purchase order (PO) record, with two fields namely item and amount. Let us take the item as a string and the amount as an integer. This can be represented in the classical objected oriented way as shown below:

class PurchaseOrder    {
  string item = "socks";
  int amount = 1;
}

In the following steps, we will see how the record is processed internally through the four core web service components.

The XML Component

The first step involves the serialization of the class data into an XML document. We assume the reader of this article is aware of XML basics. In an abstract level, XML (Extensible Markup Language) is originally designed to meet the challenges of large-scale electronic publishing. XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. The XML serialized document is represented in the above diagram with item and amount XML entities.

The SOAP Component

SOAP (Simple Object Access Protocol) is a simple XML based protocol to let applications exchange information over HTTP. If you ask a question 'why do we need SOAP?', the answer follows. Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic. SOAP was created to communicate between applications over HTTP in a better way. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

A SOAP message is an ordinary XML document containing three elements namely envelope, header, and body. It is structured as in the above diagram. The classic PO example can be represented in SOAP format as prescribed. It contains a null head; but the body contains the two record entities, item and amount.

<s:Body>
    <n:purcahseOrder xmlns:n="URN">
         <n:item>socks</n:item>
         <n:amount>1</n:amount>
    </n:purchaseOrder>
</s:Body>

The WSDL Component

WSDL (Web Service Definition Language) is an XML-based language for describing Web services and how to access them. It describes a web service, along with the message format and protocol details for the web service. A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following core elements in the definition of network services

• Types� a container for data type definitions using some type system (such as XSD).
• Message� an abstract, typed definition of the data being communicated.
• Operation� an abstract description of an action supported by the service.
• Encoding� a concrete protocol and data format specification with an abstract set of operations for all end points.
• Endpoint� a single endpoint defined as a combination of a binding and a network address.

The following example shows the WSDL definition of a simple service providing a Purchase Order (PO). The service is deployed using the SOAP protocol over HTTP. A detailed description of the elements used in this definition can be found in the SOAP encoding format.

The UDDI Component

UDDI (Universal Description Discovery and Integration) is an industry initiative to create a platform-independent, open framework for describing services, discovering businesses, and integrating business services.

UDDI is sponsored by OASIS, enabling businesses to publish service listings and discover each other and define how the services or software applications interact over the Internet. A UDDI business registration consists of three components:

1. White Pages for address, contact, and known identifiers;
2. Yellow Pages � industrial categorizations based on standard taxonomies; and
3. Green Pages � technical information about services exposed by the business.

UDDI is one of the core Web Services standards. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.

In the listed classic example, the related web service methods (get, set) will be registered in the UDDI server. Later it can be enquired and the server will publish the result set.

FYI, Windows Server 2003 includes Enterprise Universal Description, Discovery, and Integration (UDDI) Services, a dynamic and flexible infrastructure for Web services. This standards-based solution enables companies to run their own UDDI directory for intranet or extranet use. Enterprise UDDI Services help companies organize and catalog Web services and other programmatic resources. By applying categorization schemes such as geography, Quality of Service (QoS), or organization in UDDI Services, companies can establish a structured and standardized way to describe and discover services.

Web Services Architectural Design

An ideal .NET web server and client would be designed as figured below:

Advantages of Web Services

• Web services provide interoperability between various software applications running on disparate platforms/operating systems.
• Web services use open standards and protocols. Protocols and data formats are text-based where possible, making it easy for developers to comprehend.
• By utilizing HTTP, web services can work through many common firewall security measures without requiring changes to the firewall filtering rules. Other forms of RPC may more often be blocked.
• Web services allow software and services from different companies and locations to be combined easily to provide an integrated service.
• Web services allow the reuse of services and components within an infrastructure. Web services are loosely coupled thereby facilitating a distributed approach to application integration.

Disadvantages of Web Services

• Web services standards features such as transactions are currently nonexistent or still in their infancy compared to more mature distributed computing open standards such as CORBA. This is likely to be a temporary disadvantage as most vendors have committed to the OASIS standards to implement the Quality of Service aspects of their products.
• Web services may suffer from poor performance compared to other distributed computing approaches such as RMI, CORBA, or DCOM. This is a common trade-off when choosing text-based formats.

Points of Interest

Hope, it will be interesting to also know the programming concepts and web service core ideas, instead of just the traditional code level implementation.

History

• Version 1.0 - Initial version.